The Contractor-to-Cloud Self-Audit

Is your cloud project's billing account in your company's name (not a contractor's personal credit card or a 'DevWorks LLC' sole-prop entity)?

If noLosing the billing account loses everything attached to it.

Is your company the GitHub organization owner — not just a member — of the repository containing your application?

If noThe contractor can delete the repo, transfer it, or revoke access.

Do at least two people inside your company have owner-level access to your cloud project, registrar, and DNS provider?

If noBus factor of one on any of these is an existential risk.

Have all former contractors been removed from cloud IAM, GitHub, and the secrets store within 7 days of project handoff?

If noStanding access by ex-collaborators is the most common breach vector.

Is MFA enforced on the cloud console, GitHub, registrar, DNS, and secrets store — without exception?

If noWithout MFA enforcement, a single phished account is a full breach.

Does your production domain resolve to a managed cloud load balancer (or your provider's equivalent), not a VPS owned by a contractor?

If noThe contractor owns your front door — they can repoint it anywhere.

Is your TLS certificate cloud-provider-managed (Google-managed cert, ACM, etc.), not a Let's Encrypt cert renewed by a contractor's cron job?

If noWhen the cron job fails, your customers see a browser warning and you have no way to fix it.

Are your application services configured so the cloud-provider's public service URL (e.g., *.run.app, *.elb.amazonaws.com) cannot be reached directly from the internet — ingress restricted to the load balancer only?

If noYour WAF and your rate limits are decorations. Anyone can bypass them.

Is there a WAF (Cloud Armor, AWS WAF, Cloudflare in proxy mode) in front of your application with at least: an OWASP rule preset enabled, and per-IP rate limiting on your /login endpoint?

If noCredential stuffing against the login endpoint is the cheapest attack on the internet.

Is your production database on a private IP — with no path to it from the public internet?

If noCombined with leaked credentials, this is a direct dump.

Have you run `git log --all -- .env` and `git log --all -- '**/*service-account*.json'` against your repository, and confirmed neither file ever existed in history?

If noRotate everything and purge history before you do anything else.

Are all production secrets stored in a managed secrets store (Secret Manager, AWS Secrets Manager, Vault) — not pasted into Cloud Run / ECS / Lambda environment variables in plaintext, where anyone with project-viewer IAM can read them?

If noEnv-var secrets widen the blast radius of any IAM mistake.

Is your application's database user least-privilege — a non-root user scoped to one schema, not the root or admin account?

If noWhen (not if) the credential leaks, you want it to leak the smallest possible privilege.

Are webhook signatures validated on every inbound webhook (payments, SMS, mail, GitHub, etc.) — not disabled because validation failed during local development?

If noAnyone can POST forged events into your system. Includes refunds, lead injections, password resets.

Are your application-layer encryption keys (the ones that encrypt PII like email and phone in your database) rotatable without a code deploy — and do you have a documented rotation runbook?

If noYour key rotation plan is 'I will figure it out when I have to.' That goes badly.

Does every production deploy go through a pull request, with required CI checks (lint + test + build + secrets scan) green before merge?

If noDirect-to-main development is how the contractor's secrets ended up in history.

Do your database migrations run as a discrete deploy step before traffic shifts to a new revision — not on the first HTTP request after a cold start?

If noMigration-on-first-request means every cold start carries deadlock risk and every bad migration produces a five-minute outage instead of a failed deploy.

Are your migration files idempotent (IF NOT EXISTS, INFORMATION_SCHEMA gates, equivalent) — so re-running them, accidentally or otherwise, is safe?

If noFine until the day you import a database with a partial history. Then it is not fine.

Does your CI block secrets from landing in commits (gitleaks, trufflehog, or equivalent) as a required check?

If noWithout this, the next contractor will redo #1 of the blog within 60 days.

Is the same container image promoted from staging to production — not rebuilt per environment with different build-args (e.g., baking the API URL into the frontend at build time)?

If noYou can't actually test what you ship, because you ship a different artifact.

Do you have a separate staging database (and staging environment) — not local dev pointing at the production DB?

If noEvery 'small fix on local' is a production incident waiting for an off-by-one.

Are automated backups on for your production database, with point-in-time recovery enabled?

If noThere is no recovery from 'yes we have backups, but I never tested them.'

Have you tested a restore from backup in the last 90 days, end-to-end, against a fresh database?

If noAn untested backup is rumor.

Do you have a documented RPO (how much data loss is acceptable) and RTO (how much downtime is acceptable), agreed with the founder?

If noFine for early-stage, but expect this question on the first enterprise security questionnaire.

If your application encrypts PII at the application layer, is that data decryptable today on a fresh deploy — because the encryption key is managed independently of any specific running instance?

If noLosing the key means losing the data. Permanently.

Are application logs written to a centralized logging system (Cloud Logging, Datadog, ELK, equivalent) — not to local disk inside the container?

If noYour logs are wiped on every redeploy, cold start, and scale-in. You cannot debug what you cannot see.

Are sensitive fields redacted before being logged — passwords, tokens, encryption keys, and full request bodies on authentication routes?

If noYour log retention window is your password breach window. Anyone with log access has every user's password.

Do you have alerts — not dashboards, alerts — on at least: 5xx rate, p95 latency, and database connection saturation, that page someone awake?

If noYou learn about outages from customers. That is a five-figure conversion problem.

Can your application scale beyond one instance — no in-process cron jobs, no in-process inbound-mail watchers, no local-disk uploads — or is max_instances=1 a hard architectural constraint?

If noFine at current traffic. The day you hit the ceiling, you cannot ship your way out in a week.

If your only production server died right now, do you have a documented runbook that an engineer who is not you could follow to bring the application back?

If noYour bus factor is one. That is a category of risk your insurance does not cover.