Audit responsibilities

We align with SOC 2 and ISO 27001. The rule is simple: every consequential change leaves evidence as part of doing the work correctly. If the only record is someone’s memory, the control has failed.

Evidence is a by-product, not a separate task. When the pipeline, review, and audit log work correctly, the evidence already exists. This page lists each control, where its evidence lives, and how the system creates it.

Core controls

• Separation of duties: no one develops, approves, and deploys the same change alone. See /four-eyes.
• Changes are classified and tracked in Jira with their purpose, risk, and test plan. Emergency changes use the expedited path and are documented later through the same review process.
• Environments remain separate, and code is checked in pre-production before promotion.
• Access comes from Okta with MFA, so revoking an account revokes access everywhere.
• Production changes that bypass the pipeline, such as manual data edits, cron, and infrastructure changes, need a named reviewer and approver recorded before execution.
• Secrets are never committed, and third-party dependencies pass security and licence review. See /security.

Code changes, scans, and deployments are recorded in audit logs and kept for at least five years. Only the CTO or a designate can approve policy exceptions, and they must provide a written risk assessment. See /exceptions.

Where evidence lives

Each control creates its own evidence stream. “Audit logged” has a clear meaning when you can identify the store and what creates the record.

Connect the chain from start to finish: every deploy must trace to an approved Jira ticket and a specific commit SHA. The Jira issue links to the PR; the PR merges a reviewed SHA; the deploy record names that SHA. You must be able to rebuild the change-management chain from any link. See /ci-cd.

SOC 2 Trust Services Criteria

Map each control to its Trust Services Criteria so engineers and auditors use the same terms.

Immutable retention

Keeping records is not enough. The records must show if someone changed them. Export GCP Cloud Audit Logs to a log bucket with retention and bucket-lock (WORM) for five years. After the bucket is locked, no one can shorten retention or delete entries.

resource "google_logging_project_bucket_config" "audit" {
  project        = var.project
  location       = "us"
  bucket_id      = "audit-logs"
  retention_days = 1825  # 5 years
  locked         = true  # WORM: cannot shorten or delete
}

See GCP Cloud Audit Logs and log bucket retention and bucket lock.

Pipeline-bypass changes

A named reviewer and approver “before execution” is not a real control if only memory records it. Send pipeline-bypass actions through a break-glass mechanism that logs them automatically. GCP service-account impersonation records who did what and when in Cloud Audit Logs.

# Impersonation is captured in Cloud Audit Logs (who / when / what).
# Record reviewer, approver, and ticket before this runs.
gcloud sql connect main8 \
  --impersonate-service-account=breakglass@proj.iam.gserviceaccount.com

Machine-enforced gates

“Secrets are never committed” is a control only when CI enforces it. Enable secret scanning with push protection in the repository settings. Enforce dependency review through a ruleset that requires the dependency-review check. The gate then blocks the change instead of relying on the author.

# org/repo security settings, as code intent
security_and_analysis:
  secret_scanning: { status: enabled }
  secret_scanning_push_protection: { status: enabled }
# dependency review: required via a ruleset that runs the
# dependency-review workflow; it blocks the merge on violations

See the OWASP Logging Cheat Sheet for what to log without exposing sensitive data.

Access lifecycle

Okta access is provisioned through groups, not individual grants. Verify offboarding revocation instead of assuming it happened. Confirm that the account loses access everywhere. On a set schedule, review who has each type of access. This is called periodic access recertification. The review finds and removes old grants.

Artifact provenance

Provenance shows that a deployed artifact came from reviewed source through the pipeline. Adopt build provenance (SLSA), signed images, and an SBOM for each release. This makes the deployed artifact traceable to its source and build.