Free download · MIT licensed
Cloud Controls Evidence Kit
A drop-in scaffold for organizing the engineering controls and evidence that customer security reviews, SOC 2 readiness work, and compliance platforms (Vanta, Drata, Secureframe) ask for. Browse online, download the bundle, or open the source on GitHub.
Top level
- Master mapping of cloud controls to required evidence, owners, and refresh cadence.
Controls Map
- A single index of every control, the artifact that proves it, where it lives, who owns it, and when it was last refreshed — the one file an auditor or buyer asks for first.
Evidence register
- Template answers for the questions that show up on most customer security questionnaires.
Questionnaire Answer Examples
- A one-page intake to run before a security review or audit — scope, deadline, platforms, buyer asks, and which evidence exports you already have. Fill it out first; it sizes the work.
Security review intake
- Vanta, Drata, and Secureframe show you the failing checks. This guide turns that red list into a prioritized engineering implementation queue you can actually work through.
Turning compliance-platform gaps into a fix queue
Evidence folder template
Access controls
- Evidence for MFA enforcement, IAM hygiene, service-account key inventory, and offboarding.
Access controls
- Periodic review of who has privileged access — to the IdP, cloud consoles, code repositories, and production data. Catches drift: former contractors still in groups, engineers who got temporary…
IAM quarterly review
- The single most-requested control on customer security questionnaires. Buyers want to see that every human with admin access uses MFA, and that the enforcement is policy-level (not opt-in).
MFA enforcement
- Auditors and customer security reviews ask for evidence that access is revoked promptly when someone leaves. The standard evidence is: (a) a documented checklist, (b) completed instances of recent…
Offboarding checklist
Logging & monitoring
- Evidence that cloud audit logs, application logs, and security alerts are configured, retained, and routed.
Logging and monitoring
- Evidence that security-relevant events route to a human (or documented runbook) within minutes. "We have alerts configured" is not enough — the questionnaire wants proof of routing and…
Alert routing
- Evidence that audit logging is enabled across every production account / project / subscription — not just one. The most common auditor finding in this category is "logs missing from one of N…
Audit log configuration
- Buyers and auditors want logs that cover the full review period (typically 12 months) AND are tamper-resistant. The evidence is the storage-lifecycle config + a query showing the oldest available…
Audit log retention policy
CI/CD & change management
- Evidence that production code changes are reviewed, approved, and traceable.
CI/CD and change management
- The rule that prevents direct pushes to the production branch and requires reviewed PRs. Evidence is the actual rule definition plus the CODEOWNERS file that determines who reviews what.
Branch protection
- Branch protection gates the merge; deploy approvals gate the actual production push. SOC 2 wants both: code review (3.1) AND deployment approval (3.2). On GitHub, that means a protected Environment…
Deploy approvals
- The audit trail of "who shipped what to production, when, and who approved it." This is the most-requested piece of change-management evidence on questionnaires.
Release evidence
Vulnerability & secrets
- Evidence that dependencies, container images, and committed credentials are scanned, blocked, and remediated.
Vulnerability and secrets hygiene
- Evidence that dependencies are scanned for known CVEs continuously, not once-and-forgotten — and that there's a written SLA for remediation.
Dependency scanning
- Evidence that container images destined for production are scanned for CVEs before they ship, and that the deploy blocks on critical findings.
Container / image scanning
- Evidence that credentials accidentally committed to repos are detected — ideally blocked at push time — and triaged within a documented SLA.
Secret scanning
Backups & recovery
- Evidence that backups exist, are tested, and that there's a documented recovery plan.
Backups, recovery, and availability
- The configured backup schedule and retention for production data stores. Evidence is the actual managed-service configuration plus a recent record of successful backups.
Backup configuration
- The "what to do when something is on fire in production" document. Auditors and customer security reviews ask for it; the bigger value is that writing it forces the team to think through worst cases…
Incident runbook
- The single piece of evidence that most teams don't have but most buyers ask for: a documented restore from backup, recently, with measured outcomes. "We back up nightly" is not enough; an auditor…
Restore test
AI workload controls
- Evidence specific to teams shipping LLMs, RAG, agents, and tool-calling features.
AI workload controls
- Evidence that retrieval indices, embeddings, prompt logs, and other AI-derived data are partitioned per-tenant and retained per customer-DPA terms.
AI data retention and tenant isolation
- Evidence that every inference endpoint requires authentication, that unauthenticated requests are denied, and that the auth mechanism ties requests back to a tenant for downstream controls (logging…
Model endpoint authentication
- Evidence that prompts, tool calls, and outputs are logged with a policy that bounds retention and access — so investigations are possible without becoming a long-term data risk.
Prompt / tool-call logging
- Evidence that AI features have per-tenant rate-limits and spend caps so a single tenant (or a misbehaving feature) can't burn through monthly model budget, and that there's a documented runbook for…
Spend caps and abuse handling
Filled example
- A worked example of five populated control files for a fictional Series B SaaS — what the blank templates look like once they're actually filled in with real exports and numbers.
Filled example
- All human access to Acme's identity provider (Google Workspace) requires 2-Step Verification, enforced at the org level. Enforcement is policy-level, not opt-in.
MFA enforcement (filled example)
- Production deploys to Acme's services require a reviewed, merged pull request. Protection is applied via an org-level GitHub ruleset, so a newly created repo inherits it automatically rather than…
Branch protection (filled example)
- Secret scanning and push protection are enabled org-wide on GitHub. Push protection blocks a secret from reaching the repository in the first place; scanning catches anything historical.
Secret scanning (filled example)
- Acme runs a quarterly restore from the production Cloud SQL backups into an isolated environment, measures the outcome, and files the report. This is the artifact most teams lack and most buyers ask…
Restore test (filled example)
- Acme's AI features call Bedrock (production) and Vertex AI (a batch enrichment job). Both have per-environment quotas and budget alerts so a runaway loop or abuse can't produce an unbounded bill, and…
AI workload spend caps (filled example)
Platforms
- Where to find each piece of controls evidence on AWS — console paths, CLI commands, exports that satisfy auditors.
AWS evidence guide
- Where to find each piece of controls evidence on Azure — console paths, az CLI commands, exports that satisfy auditors.
Azure evidence guide
- Where to find each piece of controls evidence on GCP — console paths, gcloud commands, exports that satisfy auditors.
GCP evidence guide
- Where to find each piece of controls evidence in GitHub — UI paths, gh CLI commands, exports that satisfy auditors.
GitHub evidence guide
- Where to find each piece of controls evidence in GitLab — UI paths, glab CLI / API commands, exports that satisfy auditors.
GitLab evidence guide
Preview
controls-map.md
The most-used file in the kit, rendered here so you can see the depth before downloading. Browse the rest via the tree above.
The 30 controls that come up on the vast majority of customer security questionnaires, SOC 2 readiness assessments, and compliance-platform checks. Use this as the index of your evidence folder.
For each control: the evidence required, where it lives, who owns it, and how often to refresh.
Tip: delete rows for controls that don't apply (e.g. AI workload rows if you ship no AI features), and add rows for systems unique to your stack. The structure matters more than the exact list.
1. Access controls
| # | Control | Evidence | Where to find | Owner | Cadence |
|---|---|---|---|---|---|
| 1.1 | MFA enforced for all admin users | IdP MFA policy export + per-user enforcement screenshot | Okta / Google Workspace / Microsoft Entra → Policies | IT / Security | Quarterly |
| 1.2 | Least-privilege IAM roles | IAM role definitions + per-role member list | AWS IAM / GCP IAM / Azure AAD | Platform | Quarterly |
| 1.3 | Service-account / long-lived key inventory | Inventory + rotation policy + last-rotated timestamps | AWS IAM access keys / GCP IAM service-account keys / GitHub PATs | Platform | Quarterly |
| 1.4 | Offboarding revokes all access | Offboarding checklist + 3–5 completed runs | Internal runbook + IdP audit log + Cloud audit logs | HR / IT | Per offboarding |
| 1.5 | Privileged access review | Quarterly review minutes + sign-off | Internal doc + IdP membership export | Security | Quarterly |
2. Logging and monitoring
| # | Control | Evidence | Where to find | Owner | Cadence |
|---|---|---|---|---|---|
| 2.1 | Cloud audit logging enabled across all production accounts | Trail / log-sink config export covering every prod account or project | AWS CloudTrail Org Trail / GCP Cloud Audit Logs sink / Azure Activity Log | Platform | Quarterly |
| 2.2 | Audit log retention ≥ 365 days for the review period | Storage lifecycle policy + sample query showing oldest available log | S3 / GCS / Storage Account lifecycle rules | Platform | Annually |
| 2.3 | Application logs collected centrally | Logging config + sample query | Datadog / Honeycomb / Grafana Loki / native | Platform | Annually |
| 2.4 | Security alerts route to on-call | Alert configuration + sample firing | PagerDuty / Opsgenie / native cloud alerts | Security | Annually |
| 2.5 | Tamper-resistant log storage | Object-lock / WORM / immutability config | S3 Object Lock / GCS Bucket Lock | Platform | Annually |
3. CI/CD and change management
| # | Control | Evidence | Where to find | Owner | Cadence |
|---|---|---|---|---|---|
| 3.1 | Required reviews on production deploy | Branch-protection config + CODEOWNERS | GitHub / GitLab branch rules | Engineering leads | Quarterly |
| 3.2 | Environment-protected production deploys | GitHub Environments / GitLab protected environments config | Repo → Settings → Environments | Engineering leads | Quarterly |
| 3.3 | Signed / verified deploy artifacts | Sigstore / SLSA attestation samples (when adopted) | CI build logs | Platform | Quarterly |
| 3.4 | Release evidence: who shipped what, when | Last 30 production deploys with author + approval trail | CI/CD history + PR merges | Engineering leads | Per deploy / quarterly |
| 3.5 | Rollback capability documented | Runbook + last rollback exercise | Internal docs | Platform | Annually |
4. Vulnerability and secrets hygiene
| # | Control | Evidence | Where to find | Owner | Cadence |
|---|---|---|---|---|---|
| 4.1 | Dependency scanning enabled with SLA on critical | Scanner config (Dependabot / Renovate / Snyk) + remediation log | Repo settings + security advisories | Platform | Quarterly |
| 4.2 | Container / image scanning | Scanner config + last 30 deploys' scan results | Trivy / Artifact Registry / ECR scanning | Platform | Quarterly |
| 4.3 | Secret scanning enabled, blocking on detection | GitHub Advanced Security / GitLab secret detection config + remediation log | Repo security tab | Security | Quarterly |
| 4.4 | Static analysis / code scanning (SAST) | SAST config + findings triage log | GitHub CodeQL / GitLab SAST / Semgrep | Platform | Quarterly |
| 4.5 | Pen-test or red-team within 12 months | Engagement report or summary | Internal doc / vendor portal | Security | Annually |
5. Backups, recovery, and availability
| # | Control | Evidence | Where to find | Owner | Cadence |
|---|---|---|---|---|---|
| 5.1 | Production databases backed up | Backup configuration + last 7 backup success timestamps | RDS / Cloud SQL / native | Platform / SRE | Quarterly |
| 5.2 | Backup restore tested | Restore-test runbook + last test report (row counts, runtime) | Internal doc | Platform / SRE | Quarterly |
| 5.3 | Incident runbook exists | Runbook + last incident's postmortem | Internal docs / Notion | Engineering leads | Annually |
| 5.4 | Status page or customer-facing availability signal | Public status page URL + incident history | StatusPage / Atlassian / native | Platform | Annually |
6. AI workload controls
| # | Control | Evidence | Where to find | Owner | Cadence |
|---|---|---|---|---|---|
| 6.1 | Model endpoints behind auth | Auth config (API gateway / VPC / IAM) + sample request denied without token | Vertex AI / OpenAI org settings / Azure OpenAI | AI / Platform | Quarterly |
| 6.2 | Prompt / tool-call logging policy | Policy doc covering what's logged, retention, and access | Internal doc | AI / Security | Annually |
| 6.3 | Per-tenant or per-org spend caps | Quota / rate-limit config + spend alert routing | Vertex AI quotas / OpenAI org limits / custom rate-limiter | AI / Platform | Quarterly |
| 6.4 | RAG document access boundaries | Tenant-isolation policy + index/namespace mapping | Internal doc + vector DB config | AI | Quarterly |
| 6.5 | AI data retention reviewed | Retention policy aligned to customer contracts + DPA terms | Internal doc | AI / Legal | Annually |
| 6.6 | Abuse / misuse handling | Runbook for prompt-injection reports, content abuse, leaked-prompt incidents | Internal doc | AI / Security | Annually |
How to use this table
- For each row that applies to your stack, create a corresponding evidence file in your
evidence-folder-template/<category>/folder. Use the templates in this kit as starting points. - For each customer security questionnaire, scan the questions and pull from this table to find
the right evidence to attach. The
questionnaire-answer-examples.mdfile has template answers that reference the standard evidence categories. - At the quarterly review cadence, walk the table and refresh anything overdue. Many controls drift quietly (key rotation, deploy approver lists, MFA exceptions); a quarterly walk catches them.
Mapping to common frameworks
| This kit | SOC 2 Trust Service Criterion | NIST CSF |
|---|---|---|
| 1.x Access controls | CC6.1, CC6.2, CC6.3 | PR.AC |
| 2.x Logging and monitoring | CC7.2, CC7.3 | DE.CM, DE.AE |
| 3.x CI/CD and change management | CC8.1 | PR.IP-3 |
| 4.x Vulnerability and secrets hygiene | CC7.1 | PR.IP-12, DE.CM-8 |
| 5.x Backups, recovery, availability | CC9.1, A1.2 | RC.RP, PR.IP-4 |
| 6.x AI workload controls | (emerging — currently scoped under CC6 / CC7) | (emerging — see NIST AI RMF) |
These mappings are approximate; your auditor or compliance platform will have the authoritative cross-walk.