SOC 2 System Description & Management Assertion

Example Conversation

Below is an example of how a typical SOC 2 Type II system description session unfolds. The agent asks targeted questions to determine scope and system context, then iteratively builds and validates the description.

You: We need to prepare the system description for our SOC 2 Type II audit. Our SaaS platform is called CloudSync — it’s a document management and collaboration tool for enterprise customers.

Agent: I’ll help you draft the SOC 2 system description and management assertion letter. Let me gather some initial information:

1. Which trust services categories are in scope? Security (CC) is always required. Do you also need Availability, Confidentiality, Processing Integrity, or Privacy?
2. What is the proposed audit period? (Type II requires a minimum of six months for an initial engagement.)
3. Who are your primary subservice organizations? (e.g., cloud hosting, email provider, monitoring services)

You: Security and Availability are in scope — we have 99.9% uptime SLAs with enterprise customers. Audit period is July 1 2025 through June 30 2026. Our infrastructure runs on AWS (us-east-1 and eu-west-1), we use Datadog for monitoring, and Twilio for SMS notifications.

Agent: I’ve validated your scope — Security (CC) and Availability (A) are confirmed. Let me run through the system components now. I need to understand:

1. Infrastructure — Beyond AWS, what databases, load balancers, CDN, or networking components does CloudSync use?
2. Software — Core application stack, third-party libraries, CI/CD pipeline
3. People — Key roles involved in operating and securing the system (e.g., SRE team, Security team, DevOps)
4. Procedures — Change management, incident response, access review processes
5. Data — What types of customer data does the platform store and process?

Also — for each subservice org (AWS, Datadog, Twilio), should we use the carved-out or inclusive method? Most organizations use carved-out for major cloud providers and reference their SOC 2 reports.

You: All three are carved-out. AWS hosts everything — RDS PostgreSQL, ElastiCache Redis, ALB, CloudFront CDN. Our app is Node.js/React, deployed via GitHub Actions. We have a 6-person engineering team, 2 SREs, and a dedicated security lead. We handle change management through PR reviews and automated CI, incident response through PagerDuty, and quarterly access reviews. Customer data includes documents, user profiles, and collaboration metadata.

Agent: I’ve built the system description JSON and run the completeness checker. There are 2 errors and 1 warning:

• [ERROR] Missing CUECs — your enterprise customers have shared responsibilities (e.g., MFA enforcement, access deprovisioning). I need at least 3–5 specific, actionable CUECs.
• [ERROR] Missing CSOCs — since all three subservice orgs are carved-out, we need to document the controls assumed to be in place at each and reference their SOC 2 reports.
• [WARNING] No out-of-scope items defined in system boundaries. Explicitly stating exclusions helps auditors.

Let’s address the CUECs first. What responsibilities do your customers have for securing their use of CloudSync?

You: Customers must enforce MFA for admin accounts, conduct their own access reviews for their users, decommission accounts when employees leave, and configure IP allowlisting if they want to restrict access. They’re also responsible for the security of documents before upload.

Agent: Perfect — I’ve added 5 CUECs. I also added CSOCs for all three carved-out subservice orgs referencing their most recent SOC 2 Type II reports. The completeness check now passes with 0 errors. I’ve started drafting the narrative at output/cloudsync-soc2-system-description.md. The first sections — Company Overview, Description of Services, and SCSR — are ready for your review. Want me to continue with the Components and Control Environment sections?

Sample Output Excerpt

Below is a representative excerpt from a generated system description, showing the Principal Service Commitments and System Requirements (SCSR) section and the Subservice Organizations section — two areas where auditors frequently find deficiencies.

Principal Service Commitments and System Requirements

CloudSync makes the following principal service commitments to its customers, as documented in its Master Subscription Agreement and Service Level Agreement:

Service Commitments:

System Requirements:

To fulfil the commitments above, CloudSync has established the following system requirements:

• All data in transit must use TLS 1.2 or higher. Connections using deprecated protocols are rejected at the load balancer.
• All data at rest is encrypted using AES-256. Encryption keys are managed through AWS KMS with annual rotation.
• Customer administrative accounts must have multi-factor authentication (MFA) enabled. MFA enrollment is enforced at first login.
• Production deployments require at least two peer-reviewed approvals and must pass all automated security scans (SAST, dependency audit) before merge.
• Infrastructure changes follow a documented change management process with rollback procedures tested monthly.
• System availability is monitored continuously via Datadog with automated alerting. The on-call SRE team responds to availability incidents within 15 minutes.

Subservice Organizations

CloudSync utilizes the following subservice organizations. All are presented using the carved-out method — their controls are excluded from the scope of this system description, and CloudSync relies on each organization’s own SOC 2 report for assurance over the controls they perform.

Complementary Subservice Organization Controls (CSOCs):

The following controls are assumed to be in place at each carved-out subservice organization:

• AWS: Physical security of data centers, network isolation of customer environments, encryption key management (KMS), infrastructure availability and redundancy, vulnerability management of underlying hypervisor and hardware.
• Datadog: Secure transmission and storage of log data, access controls over monitoring dashboards, availability of the monitoring platform per Datadog’s published SLA.
• Twilio: Secure delivery of SMS messages, protection of phone numbers and message content in transit, availability of the messaging API.

Built-in Validation

The skill includes two validation tools that automatically check your system description against AICPA structural requirements. After each editing pass, the agent runs the validators and reports findings so you can address gaps iteratively.

What the validators check

System Description Completeness Checker:

Trust Services Scope Validator:

Severity levels

• ERROR — A required AICPA element is missing. Must be resolved before the system description is audit-ready.
• WARNING — A recommended element is absent or needs attention. May not block the audit but could draw auditor comments.

Example validation output

========================================================================
SOC 2 System Description — Completeness Check
========================================================================

--- Errors (must fix) ---
  [ERROR] cuecs: No complementary user entity controls (CUECs) defined.
    CUECs are a required disclosure per AICPA SOC 2 Guide ¶ 3.55. If
    no CUECs apply, document this explicitly.
  [ERROR] csocs: Carved-out subservice organizations are listed but no
    CSOCs are defined. For carved-out orgs, describe the controls
    assumed to be in place at the subservice organization and reference
    their SOC report (per AICPA SOC 2 Guide ¶ 3.50).

--- Warnings (recommended) ---
  [WARNING] system_boundaries.out_of_scope: No out-of-scope items
    defined. Explicitly stating what is excluded helps auditors and
    reduces scope creep.

========================================================================

========================================================================
SOC 2 Trust Services Scope Validation
========================================================================

Categories in scope:
  [CC] security
  [A] availability

  [WARNING] Category "availability" (A) is in scope but the
    control_environment narrative contains no keywords associated with
    A criteria (e.g., availability, uptime, redundancy). Ensure CC
    controls are supplemented with A-specific control descriptions.

========================================================================

The agent runs both validators automatically after each major editing pass and surfaces findings inline, so you always know exactly what remains before your system description is structurally complete.