Environment Separation for SOC 2

What this control should accomplish

Development, test, staging, production, and recovery environments have enforceable boundaries, and lower environments do not receive production customer data without explicit safeguards and approval.

How to implement Environment Separation

1. 1

   Inventory environments

   List each environment, its purpose, account or project, network boundary, credentials, data classification, and responsible owner.

   You should end up with: Environment boundary inventory

2. 2

   Separate access and secrets

   Use distinct roles, service identities, credentials, and secret paths for production and lower environments.

   You should end up with: Environment-specific access and secret configuration

3. 3

   Control data movement

   Default to synthetic or sanitized data and require documented purpose, approval, protection, and deletion for exceptional production-data use.

   You should end up with: Approved data-movement workflow and exception record

4. 4

   Verify boundaries

   Test that lower-environment identities cannot reach production resources and review cross-environment connections for necessity.

   You should end up with: Boundary test and connection review results

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: Development, test, staging, production, and recovery environments have enforceable boundaries, and lower environments do not receive production customer data without explicit safeguards and approval.

• 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 infrastructure deployments and cloud configuration events, reconcile them to pull requests and tickets, then reconcile data-copy and emergency paths to approvals, exceptions, and verified deletion or closure.

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

  Retain the current environment inventory and boundary configuration plus one recent access or data-flow test showing production separation on the selected date.

• Prepare period evidence for a Type 2 engagement

  List every production or lower-environment infrastructure deployment affecting accounts, networks, identities, secrets, or data paths, plus every production-data movement, boundary exception, and scheduled separation review during the period, including emergency changes.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect Environment inventory

    For each selected record, confirm it demonstrates The team knows each environment's purpose, owner, account, network boundary, data classification, and relationship to production.

    • Environment name
    • Purpose
    • Account or project
    • Owner
    • Network boundary
    • Data classification

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect data movement approvals

    For each selected record, confirm it demonstrates Any production data moved to a lower environment had a defined purpose, authorized decision, safeguards, and deletion plan.

    • Request ID
    • Source and destination
    • Data scope
    • Approver
    • Protection method
    • Deletion date

  • Inspect non-production data exceptions

    For each selected record, confirm it demonstrates Departures from synthetic or sanitized test data are bounded, risk-assessed, protected, and closed or reapproved.

    • Exception ID
    • Data and environment
    • Business reason
    • Risk owner
    • Safeguards
    • Expiry or closure

• Inspect the operating / technical evidence

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

  • Inspect access controls

    For each selected record, confirm it demonstrates Production and lower-environment identities, roles, and network paths are separated according to approved responsibilities.

    • Environment
    • Identity or group
    • Role
    • Resource scope
    • Effective date
    • Configuration source

• 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

• The environments have different names but share accounts, credentials, or unrestricted networks.
• Production database copies are used for debugging without masking or approval.
• Recovery resources are accessible through ordinary development credentials.
• Temporary cross-environment access remains after troubleshooting ends.

Before you call this control ready

• Can a development identity access any production data or control plane?
• Is every lower-environment production-data copy approved, protected, and deleted on schedule?
• Are secrets unique to their environment and rotated independently?
• Do diagrams and infrastructure configuration agree on the environment boundaries?

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
• C1.1
• P4.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