SOC 2 System Description for Software Architectures: Technical Mapping, Control Scoping, and Engineering Reme…

The technical anatomy of DC 200 system descriptions

Auditors review your architecture through the AICPA DC 200 guidelines. If your narrative is vague, the auditor broadens the audit scope to protect their own firm, creating dozens of surprise control requests. If it is accurate and narrow, you contain the audit surface area.

A defensible system description breaks your environment into five mandatory technical components:

• Infrastructure: The physical and virtual assets supporting your application. Name your primary cloud provider (such as AWS, GCP, or Azure), availability zones, network topologies (VPCs, public/private subnets), firewalls, and ingress controllers.
• Software: The application layer, container runtimes (like EKS or GKE), orchestration layers, CI/CD platforms (like GitHub Actions or GitLab), and operating systems.
• People: The organizational hierarchy, background check procedures, role assignments, and engineering access authorization workflows.
• Procedures: The operational policies enforcing your system logic: change management pipelines, peer reviews, disaster recovery drills, vulnerability scans, and incident response playbooks.
• Data: The classification lifecycle for user data, including data at rest (AES-256 via KMS), data in transit (TLS 1.3), database replication boundaries (such as Aurora PostgreSQL or DynamoDB), backup retention policies, and cryptographic deletion.

Beyond these five pillars, the document must state your Complementary User Entity Controls (CUECs) and Complementary Subservice Organization Controls (CSOCs). CUECs explain what your customer must do to remain secure, such as enforcing multi-factor authentication on their end. CSOCs explain what third-party vendors handle, such as AWS managing physical data center security.

How much does a SOC 2 system description cost to build and remediate?

Building a SOC 2 system description and remediating the engineering gaps it reveals costs between $120,000 and $300,000 across auditor fees, internal labor, tooling, and infrastructure updates. The document itself is cheap to write; the engineering required to make production reflect what you wrote is where budgets drain.

Auditors charge between $20,000 and $45,000 for a Type II examination. Automated compliance platforms consume another $10,000 to $25,000 annually. The dominant financial cost is senior engineering hours spent rewriting Terraform modules, removing wildcard IAM permissions, enforcing database encryption keys, and standing up centralized log pipelines.

If your system description claims you enforce automated canary deployments with signed commits, but three engineers push straight to main using personal access tokens, you will fail the test of operating effectiveness. Every claim in the narrative creates a recurring technical obligation.

Mapping software architecture to trust services criteria

Engineering teams stumble when translating raw cloud architecture into auditor-friendly controls. The auditor does not evaluate your microservices for elegance; they verify whether code changes can bypass controls, whether secrets sit in plaintext, and whether user data bleeds between tenants.

Our security modernization teams routinely map architecture to the Common Criteria (Security), Availability, and Confidentiality categories using specific configurations:

## Example: Codifying the boundary described in Section 3
## Enforcing envelope encryption and access isolation for in-scope datastores

resource "aws_kms_key" "soc2_storage_key" {
  description             = "Customer data volume encryption key - Production"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  tags = {
    Environment = "production"
    DataScope   = "in-scope-pii"
    Compliance  = "soc2-type2"
  }
}

resource "aws_db_instance" "production_db" {
  identifier            = "core-customer-datastore"
  engine                = "postgres"
  engine_version        = "15.4"
  instance_class        = "db.r6g.xlarge"
  allocated_storage     = 200
  storage_encrypted     = true
  kms_key_id            = aws_kms_key_soc2_storage_key.arn
  publicly_accessible   = false
  deletion_protection   = true

  vpc_security_group_ids = [aws_security_group.db_private.id]
}

In your system description narrative, this infrastructure block supports two separate controls:

1. CC6.1 (Logical Access Controls): The database is physically isolated in a private subnet, inaccessible via the public internet, accessible only by compute workloads inside the application security group.
2. CC6.7 (Data Transmission and Disposal): Data at rest is encrypted using AWS KMS with automated 365-day key rotation, satisfying encryption requirements for primary storage, transaction logs, and snapshots.

Writing the description requires linking your narrative to actual source control repositories, Terraform workspaces, and operational alerts. If you say you run weekly container vulnerability scans, name AWS ECR or Trivy in the software subsection and provide the automated alert channel in Slack or PagerDuty.

How long does drafting and technical remediation take?

Drafting the system description takes 2 to 4 weeks, but the total timeline from blank page to an issued SOC 2 Type II report takes 5 to 9 months. The bottleneck is not writing the prose; it is executing technical remediation followed by the mandatory 3-to-6-month audit observation window.

The observation period requires zero control failures. If you draft the system description in Month 1, discover your production clusters lack audit logging in Month 2, and fix it in Month 3, your observation period cannot legally start until Month 3 has closed.

Month 1: Gap Assessment & System Boundary Scoping
Month 2: Infrastructure Remediation & IaC Deployment
Month 3 to 5: Observation Period (Minimum 90 days for Type II)
Month 6: Evidence Retrieval, Auditor Review & Report Issuance

Compressing this timeline means completing engineering remediations before the clock starts on the observation period. If an enterprise customer demands an attestation immediately, issue a SOC 2 Type I report first, which evaluates design efficacy at a single point in time, then transition into the Type II observation period.

Over-scoping vs under-scoping: which architectural boundary fits?

Over-scoping your SOC 2 system description causes longer audits and expensive evidence collection, while under-scoping risks audit failure or enterprise procurement rejection. A tight boundary encloses only the components that process, store, or transmit sensitive customer data, intentionally excluding non-production, internal tooling, and separate business units.

Many growth-stage engineering teams make the error of declaring their entire AWS organization in scope. If you do that, your internal analytics pipeline, sandbox development accounts, and internal Slack bots fall under identical change-management rules. A junior engineer testing an integration in a scratch VPC suddenly creates an audit exception because their branch did not require a formal pull request approval.

Keep your boundary defensible using these rules:

1. Account-level isolation: Enforce a hard separation between your AWS root account, production workloads, and non-production accounts via AWS Organizations. The system description explicitly scopes out dev, sandbox, and staging unless staging holds sanitized production snapshots.
2. Database sanitization: If engineers pull production databases into local or staging environments to debug bugs, staging is now in-scope. You must either sanitize that data with deterministic masking pipelines or keep local environments populated strictly with synthetic seed data.
3. Data lake boundaries: If Snowflake, Databricks, or BigQuery ingests production tables, your data lake is in scope. If you strip all customer identifiers at the ingestion worker via HMAC tokenization, you can defend excluding down-stream business intelligence platforms from the Trust Services Criteria.

Managing these architecture boundaries is standard work when preparing a company for enterprise procurement reviews, where security teams dissect your Section 3 narrative to ensure their tenant data does not leak into internal testing pipelines.

The engineering debt auditors actually fail

Auditors do not read your source code to evaluate algorithm efficiency. They search for specific discrepancies between your architectural narrative and reality. The engineering failures that trigger Section 4 exceptions rarely involve sophisticated zero-day exploits; they involve baseline operational discipline:

• GitHub branch protection bypasses: Your system description claims all pull requests require two peer reviews and passed CI checks prior to deployment. If the audit logs show an engineering manager bypassing protections using admin permissions during a Friday night hotfix, that is a reportable exception.
• Orphaned IAM users and missing MFA: If an offboarded contractor still has an active read-only console login 72 hours after termination, you fail the access revocation control. Move all engineers to an external identity provider (such as Okta or Google Workspace) with enforced SSO and SCIM provisioning.
• Unencrypted backups and ephemeral disks: Engineering teams frequently encrypt the primary RDS Postgres instance via KMS, but write database dumps to an unencrypted transient S3 bucket for nightly ETL scripts. If that bucket lacks explicit SSE-KMS bucket policies, it invalidates your encryption claims.
• Log retention and tampering gaps: Centralize your system, API, and network logs. CloudTrail logs, VPC flow logs, and Kubernetes audit logs must stream to a dedicated log archive account with S3 Object Lock (WORM storage) enabled. If developers have write or delete permissions on CloudWatch or Datadog log groups, your integrity controls fail.

What this means for your team

Writing a compliant SOC 2 system description is an infrastructure engineering project disguised as administrative paperwork. If your senior engineers write the document as an aspirational description of what they hope the platform looks like, your audit will disintegrate during evidence collection.

Treat the system description as a contract between your engineering architecture and an external evaluator:

1. Map your boundaries around production only, isolating it with dedicated VPCs and accounts.
2. Inspect your change management, log retention, and IAM permissions directly against Terraform states before handing the narrative to an auditor.
3. Eliminate all manual operational steps. Codify your access reviews, encryption setups, and CI/CD policies so compliance artifacts generate automatically.

If your team is facing an upcoming SOC 2 Type II audit, dealing with significant architectural remediation, or needs help isolating production environments to survive enterprise security reviews, we can help. Talk to our engineering team about assessing your cloud architecture and closing control gaps before the auditor begins their testing.