Resources · Checklist

Startup cloud platform: the 25 points we check

This is the list we start any review with. We publish it so you can run it yourself in an afternoon. It is meant for B2B product teams in their first years in production: a startup whose team grows faster than its cloud platform. It is not a security audit and does not cover everything; it covers what fails most often at that stage.

The 25 points each say why they matter, the warning sign and where to look in AWS, Azure and Google Cloud.

Take the self-assessment (no data needed)

A

Access and accounts

  1. Who owns the account and how it is protected.

    Why it matters
    If you lose the root account or the global admin, you lose the technical company.
    Warning sign
    The root account has access keys or is used daily; there is a single administrator; the account email belongs to one person.
    Where to look
    AWS: root user with MFA, no access keys and a role-based email. Azure/Entra: at least two Global Admins with MFA and an emergency (break-glass) account. GCP: Organization Admin and Billing Admin assigned to groups, not to one person.

  2. Human access through SSO and offboarding.

    Why it matters
    Every former employee who keeps access is a risk and a cost.
    Warning sign
    Local users with passwords; nobody knows who has what; offboarding a person does not include the cloud.
    Where to look
    AWS IAM Identity Center; Entra ID with conditional access; Cloud Identity or Google Workspace groups in GCP. Check the last sign-in of every user.

  3. Long-lived credentials and secrets.

    Why it matters
    A key leaked in a repository is one of the most common incidents.
    Warning sign
    IAM access keys older than 90 days, GCP service account JSON keys, secrets in environment variables or in the repository.
    Where to look
    AWS credential report and Secrets Manager / Parameter Store; Azure Key Vault and Managed Identity; GCP Secret Manager and Workload Identity instead of JSON keys. Scan the repository history for secrets with a scanning tool.

  4. Least privilege.

    Why it matters
    Permissions for “everything” turn any mistake into a disaster.
    Warning sign
    Policies with Action: * and Resource: *, subscription Owner/Contributor for developers, GCP basic Owner/Editor roles in use.
    Where to look
    AWS IAM Access Analyzer; Azure RBAC and Defender for Cloud/Advisor; GCP IAM Recommender.

  5. Production and test kept apart.

    Why it matters
    It stops a badly launched script from touching the wrong environment.
    Warning sign
    Production and staging in the same account, subscription or project and with the same permissions.
    Where to look
    AWS: separate accounts under Organizations. Azure: separate subscriptions under management groups. GCP: separate projects under folders.

B

Delivery and deployment

  1. Deployments run from a pipeline, not from a laptop.

    Why it matters
    It prevents “only I know how to deploy”.
    Warning sign
    Manual deployments; steps only one person knows; nobody knows which version runs in production.
    Where to look
    Repository and CI/CD tool (GitHub Actions, GitLab CI, Azure DevOps, Cloud Build, CodePipeline). Ask: can someone who is not the author deploy, in under 30 minutes and following a document?

  2. The pipeline reaches the cloud without stored keys.

    Why it matters
    CI keys are a common target.
    Warning sign
    AWS_SECRET_ACCESS_KEY or a service account JSON stored as a CI secret.
    Where to look
    OIDC federation from GitHub/GitLab to AWS IAM roles, Azure federated credentials or GCP Workload Identity Federation.

  3. The main branch is protected.

    Why it matters
    It keeps an unreviewed change from reaching production.
    Warning sign
    Direct pushes to main are allowed; no mandatory tests; optional review.
    Where to look
    Branch protection rules, mandatory review and required status checks.

  4. There is a way back and data migrations allow it.

    Why it matters
    Deploying without knowing how to go back is the source of the fear of deploying.
    Warning sign
    There is no written rollback procedure; database migrations drop columns in the same release as the code that stops using them.
    Where to look
    Deployment strategy (rolling, blue/green, canary) and backwards-compatible migrations in two steps.

  5. Infrastructure is in code and its state is protected.

    Why it matters
    Without IaC there is no reproducibility or review.
    Warning sign
    Resources created by hand in the console; code and reality have drifted apart; the Terraform state sits on a laptop.
    Where to look
    Terraform/OpenTofu, CloudFormation/CDK, Bicep, Pulumi. State in a remote backend (S3 with locking, Azure Storage, GCS), encrypted and versioned. Run a plan and see how many unexpected changes appear.

C

Data and recovery

  1. Automatic, encrypted backups kept outside the failure domain.

    Why it matters
    Accidental deletion and ransomware are not fixed by high availability.
    Warning sign
    Backups only in the same project and with the same credentials as production; no defined retention.
    Where to look
    AWS Backup or RDS snapshots copied to another account or region; Azure Backup with a separate vault; Cloud SQL backups and bucket copies in another project on GCP.

  2. A restore has actually been done.

    Why it matters
    An untested backup is a hypothesis.
    Warning sign
    Nobody remembers the last restore; no written RPO or RTO (how much data you accept losing and how long you can be down).
    Where to look
    A quarterly restore test in a separate environment, with the time measured and documented.

  3. Protection against deletion.

    Why it matters
    A terraform destroy or a console click should not be able to delete the database.
    Warning sign
    Databases and buckets without protection.
    Where to look
    AWS: deletion protection on RDS, versioning and Object Lock on S3. Azure: resource locks and soft delete. GCP: deletion protection and retention policy on buckets.

  4. Availability proportionate to the business.

    Why it matters
    Most do not need multi-region; almost everyone needs a zone failure not to take them down.
    Warning sign
    Production database in a single zone with no plan; or, the opposite, expensive multi-region nobody asked for.
    Where to look
    Multi-AZ on RDS, zone redundancy on Azure, regional/HA on Cloud SQL, and at least two application instances in different zones.

  5. Supported versions.

    Why it matters
    What leaves support costs extra or breaks without warning.
    Warning sign
    Kubernetes, database engine or runtime out of support; base images not updated; latest in production.
    Where to look
    EKS/AKS/GKE version and end-of-support dates; RDS/Azure Database/Cloud SQL engine version; container images pinned by version or digest.

D

Operations

  1. Alerts someone answers.

    Why it matters
    An alert nobody reads is noise.
    Warning sign
    Hundreds of unread alerts; nobody knows who receives them; alerts based on CPU instead of symptoms.
    Where to look
    CloudWatch, Azure Monitor, Cloud Monitoring or another tool: alert on error rate, latency and saturation of what the user notices, with an owner and a channel. Define the real hours of attention; if there is no on-call, say so.

  2. Centralised logs and audit trail.

    Why it matters
    Without logs there is no way to explain an incident.
    Warning sign
    Logs lost on restart; audit disabled; infinite retention that costs a fortune.
    Where to look
    CloudTrail enabled in all regions and sent to a separate account; Azure Activity Log and diagnostics; GCP Cloud Audit Logs (data access logs must be enabled). Set retention per log type.

  3. Runbooks and incident response.

    Why it matters
    At 3 a.m. (or Monday at 9) nobody should be improvising.
    Warning sign
    There is no document for “what do I do if the database is down”; incidents are not reviewed afterwards.
    Where to look
    A one-page runbook per likely incident and a blameless review after every incident.

  4. Exposed surface.

    Why it matters
    What is exposed by accident gets found on its own.
    Warning sign
    SSH/RDP ports or databases open to 0.0.0.0/0; public buckets or blobs; public database endpoints; certificates that expire without notice.
    Where to look
    AWS security groups and S3 Block Public Access; Azure NSGs and public access to Storage; GCP firewall rules and public access prevention. Use a bastion or SSM/Bastion/IAP access instead of opening ports.

  5. Quotas and limits.

    Why it matters
    The peak arrives and the cloud says no.
    Warning sign
    Close to the limit of instances, IPs, vCPUs or API quota; autoscaling limits made up without measuring.
    Where to look
    AWS Service Quotas; Azure usage + quotas; GCP IAM & Admin > Quotas. Request increases before the launch, not during it.

E

Costs and handover

  1. Every euro has an owner.

    Why it matters
    What is not tagged cannot be discussed.
    Warning sign
    A relevant part of the spend with no tag or not assigned to a team, environment or product.
    Where to look
    AWS: cost allocation tags enabled. Azure: tags and Cost Management. GCP: labels and billing export to BigQuery.

  2. Budgets and anomaly alerts.

    Why it matters
    Most bill surprises could have been seen on day two.
    Warning sign
    Nobody looks at the bill until it arrives.
    Where to look
    AWS Budgets and Cost Anomaly Detection; Azure Cost Management budgets and alerts; GCP Billing budgets and alerts.

  3. Obvious waste.

    Why it matters
    It is the first improvement, and carries no risk for the product.
    Warning sign
    Unattached volumes, orphaned snapshots, unused public IPs, load balancers with no traffic, test environments running around the clock, oversized instances, cross-zone traffic or NAT left unreviewed.
    Where to look
    AWS Cost Explorer, Compute Optimizer and Trusted Advisor; Azure Advisor; GCP Recommender. Typical action: switch off outside working hours, resize, delete. These are not savings figures: it depends on your account.

  4. Usage commitments, only after cleaning up.

    Why it matters
    Buying reservations on an inflated spend locks in the waste for years.
    Warning sign
    Commitments bought without a stable-usage analysis; or, the opposite, stable usage for months with no commitment.
    Where to look
    AWS Savings Plans/Reserved Instances; Azure Reservations/Savings Plan; GCP Committed Use Discounts. Order: tag, clean up, resize and only then commit the stable part.

  5. If your CTO leaves tomorrow, can the team carry on?

    Why it matters
    It is the risk that sums up all the others.
    Warning sign
    Only one person knows how to deploy, restore and read the bill; there is no service inventory with owners; the documentation lives in someone’s head.
    Where to look
    Service inventory with owners, runbooks for the five critical procedures (deploy, roll back, restore, rotate secrets and offboard a person) and a backup person for each. This is the point we care about most.

How to use it

Score each point by hand (yes, partial or no) or take the self-assessment, which does it for you with 15 questions. Start with the “no” answers in blocks A and C: access and recovery first. If your team can answer 20 of 25 without looking, you do not need us. If not, write to us; and if your team can fix it alone, even better.

Go to the self-assessment

Book 30 minutesOr write to us

Guidance only: it does not replace an audit and does not guarantee security or savings.