Controlled Production Deployment for SOC 2

What this control should accomplish

Only authorized people or approved automation can deploy to production, with every release linked to an approved change and validated after deployment.

How to implement Controlled Production Deployment

1. 1

   Restrict deployment authority

   Limit production deployment to named roles and dedicated service identities; remove standing access that is not needed.

   You should end up with: Approved deployer list and access configuration

2. 2

   Bind artifact to approval

   Promote the reviewed build artifact without rebuilding it and retain its digest, source revision, and approved change reference.

   You should end up with: Release record linking artifact, revision, and ticket

3. 3

   Log production release

   Capture the deployment identity, environment, timestamp, status, and pipeline run for every production release.

   You should end up with: Complete production deployment log

4. 4

   Validate and monitor

   Run defined post-release checks and investigate console changes or deployments outside the approved path.

   You should end up with: Validation result and out-of-band review

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Only authorized people or approved automation can deploy to production, with every release linked to an approved change and validated after deployment.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Head of Engineering / Platform Owner), then compare dated records with the stated cadence: Per change.

• Establish the complete audit record set

  Start with platform and cloud production-deployment events, reconcile each to its artifact, pull request, and ticket, and investigate manual, emergency, or unmatched activity outside the approved pipeline.

• Prepare the as-of-date evidence for a Type 1 engagement

  Retain current production deployment permissions and one recent release traced from approved artifact through authorized deployment and post-release validation as of the selected date.

• Prepare period evidence for a Type 2 engagement

  Export every production deployment attempt during the period, including successful, failed, cancelled, rolled-back, direct-console, manual, and emergency releases, with the deploying identity, artifact, approval path, and validation result.

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect Deployment logs

    For each selected record, confirm it demonstrates Every production release is attributable to an authorized person or service identity and records the artifact, environment, time, and result.

    • Deployment ID
    • Artifact digest or commit
    • Production environment
    • Actor
    • Start and completion time
    • Outcome

  • Inspect release artifacts

    For each selected record, confirm it demonstrates The deployed package or image is the identifiable output of the reviewed and tested build.

    • Artifact name
    • Version or digest
    • Build ID
    • Source commit
    • Creation time
    • Registry location

  • Inspect deployment operator/service account

    For each selected record, confirm it demonstrates Production deployment authority is limited to approved identities whose actions can be attributed.

    • Identity
    • Role or permissions
    • Environment scope
    • Approval owner
    • Effective date
    • Last-used time

  • Inspect pipeline permissions

    For each selected record, confirm it demonstrates Release workflows and production environments enforce who may initiate, approve, alter, or execute deployments.

    • Pipeline or environment
    • Role
    • Permitted identities
    • Approval gate
    • Configuration date
    • Export source

  • Inspect validation evidence

    For each selected record, confirm it demonstrates The team checked production health and intended behavior after release and recorded the decision to continue or roll back.

    • Deployment ID
    • Validation checks
    • Reviewer or automation
    • Execution time
    • Results
    • Follow-up decision

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• Engineers retain broad direct deployment access after the pipeline is introduced.
• The deployed artifact cannot be tied to the reviewed source revision.
• A successful pipeline is treated as validation without a production health check.
• Console and hotfix activity is absent from the release population.

Before you call this control ready

• Who can deploy directly today, and why is each permission needed?
• Can a release be traced to an immutable artifact and approved change?
• Does every deployment record include an actor and post-release result?
• Would the team detect a production change made outside the pipeline?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• CC6.1
• CC8.1

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next