Designing and Implementing SOC 2 Controls

From Trust Services Criteria to Concrete Controls

In SOC 2, you do not get a checklist of required controls. Instead, you get the Trust Services Criteria (TSC)—high‑level requirements published by the AICPA. Your job is to translate those criteria into specific controls, policies, and procedures for your system.

By now (after earlier modules), you know:

• SOC 2 reports are about a defined system in scope.
• You choose relevant Trust Services Categories (TSC): usually Security (required), and often Availability, sometimes Confidentiality, Processing Integrity, and Privacy.

In this module, we focus on how to design and implement controls that map to those criteria, especially for Security and Availability, which are most common in practice.

We will:

1. Distinguish control design vs control operation.
2. Walk through major SOC 2 control domains.
3. See how policies, procedures, and technical controls work together.
4. Explain Complementary User Entity Controls (CUECs) and complementary subservice organization controls.
5. Practice mapping a criterion to a real control.

Keep in mind: auditors in 2025 still use the AICPA 2017 Trust Services Criteria (updated periodically). The terminology ("TSC", "control activities", "risk assessment", etc.) is current and standardized across SOC 2 engagements.

Step 1 – Control Design vs Control Operation

In SOC 2, controls are evaluated in two dimensions:

1. Control Design

Question: If this control worked as described, would it reasonably achieve the related Trust Services Criteria?

Key points:

• Focuses on structure and intent.
• Relevant for Type I and Type II reports.
• Examples of design questions:
• Is there a clear owner for the control?
• Is the control precisely defined (what, who, when, how)?
• Does it address a real risk identified in risk assessment?
• Is it feasible in the environment (tools, skills, scale)?

2. Control Operation

Question: Did the control actually operate as designed over the review period?

Key points:

• Focuses on evidence of consistent performance.
• Relevant only for Type II reports (usually 3–12 months).
• Examples of operation questions:
• Are there logs, tickets, approvals, or reports showing the control ran?
• Were there missed occurrences (e.g., reviews not done, alerts ignored)?
• Are exceptions documented and addressed?

Simple analogy

• Design: The recipe for a cake (ingredients, steps, oven temperature).
• Operation: Whether you actually followed the recipe every time you baked the cake.

For SOC 2 success, you need both: a good recipe and consistent baking.

Step 2 – Design vs Operation: Quick Classification

Classify each statement as mainly about design or operation. Think before checking the answers below.

1. "Production access requires approval from the system owner and is granted through the IAM tool."
2. "During the period, 98% of production access requests had documented approvals; 2% did not and were treated as exceptions."
3. "Quarterly user access reviews are performed by system owners using a standardized checklist."
4. "Evidence shows only two quarterly reviews were completed this year; the other two were missed."

Reflect, then check:

• 1 → Design (describes how access should work).
• 2 → Operation (describes how it actually worked over time).
• 3 → Design (describes the intended review process).
• 4 → Operation (evaluates whether the process actually ran).

If you mixed some up, reread the previous step and focus on the time dimension: "in principle" (design) vs "in practice over the period" (operation).

Step 3 – Common SOC 2 Control Domains (Security & Availability)

Auditors expect to see controls grouped into domains that align with the Trust Services Criteria. Names vary by company, but typical domains (especially for Security and Availability) include:

1. Governance & Risk Management

• Risk assessment process
• Security governance (committees, roles, reporting)
• Policies lifecycle (approval, review, communication)

1. Access Control & Identity Management

• User provisioning/deprovisioning
• Role-based access control (RBAC)
• Multi-factor authentication (MFA)
• Privileged access management

1. Change Management

• Change requests, approvals, and testing
• Segregation of duties (e.g., dev vs prod deploy rights)
• Emergency change procedures

1. System Operations & Availability

• Capacity management and monitoring
• Backup and restore processes
• High availability / redundancy (if applicable)
• Job scheduling and batch processing controls

1. Incident Detection & Response

• Security monitoring (SIEM, alerts)
• Incident classification and triage
• Incident response runbooks and communication
• Post-incident reviews (lessons learned)

1. Vendor & Subservice Organization Management

• Vendor risk assessment and onboarding
• Contractual security requirements
• Ongoing monitoring (e.g., SOC reports, SLAs)

1. Logical & Physical Security

• Network segmentation, firewalls, WAF
• Data encryption (in transit, at rest)
• Physical access to offices / data centers (badges, logs)

1. Data Management & Confidentiality (if in scope)

• Data classification
• Data retention and disposal
• Secure transmission and storage

As you design controls, you map each one to specific criteria (e.g., CC6.1 for logical access, A1.2 for availability) and to one or more of these domains.

Step 4 – Example: Translating a Criterion into Controls

Let’s take a Security criterion from the AICPA TSC:

> CC6.1 – The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

How do we translate this into concrete controls?

1. Identify the risk

• Unauthorized users could access customer data.

2. Define policy-level control

• Policy statement (design):
• "Access to production systems and customer data must be restricted to authorized personnel based on job responsibilities and must be granted using the centralized identity and access management (IAM) system."

3. Define procedure-level controls

Examples:

• User provisioning procedure:
• New hires must have a ticket in the ITSM tool.
• Manager approval required for access to production.
• Access assigned based on documented roles.
• Deprovisioning procedure:
• HR notifies IT on termination.
• All accounts disabled within 24 hours.

4. Define technical controls

Examples:

• SSO integrated with corporate identity provider (IdP).
• MFA enforced for all production access.
• Access to production databases limited to specific security groups.

5. Evidence for operation (Type II)

• Access request tickets with approvals.
• IAM export showing only active employees have access.
• Logs from IdP showing MFA usage.
• Termination tickets linked to account disablement records.

This is the pattern you repeat: criterion → risk → policy → procedures → technical controls → evidence.

Step 5 – Mini Design Exercise: Availability Control

Imagine your company runs a SaaS application and you have Availability (A1) in scope.

Scenario:

• The app must be available 99.9% of the time.
• You already run your service on a major cloud provider.

Task: In your own words, outline one control (design only) that supports Availability. Try to cover:

• What is done?
• Who does it?
• How often?

Write your answer in a few sentences before comparing with the sample.

---

Sample answer (one possible design):

> "The SRE team monitors system availability 24/7 using a centralized monitoring platform. Alerts are configured to trigger when service availability over the last 5 minutes drops below 99%. On-call engineers respond to alerts within 15 minutes according to the documented incident response runbook. Monthly, the SRE manager reviews uptime reports and investigates any incidents that caused downtime."

Notice how this answer:

• States who (SRE team, on-call engineers, SRE manager).
• States what (monitoring, alerts, response, monthly review).
• States how often (real-time/24-7, monthly).

For a Type II, you would then need evidence (alert logs, on-call schedules, incident tickets, monthly reports).

Step 6 – Policies, Procedures, and Technical Controls

SOC 2 controls usually exist at three levels. Auditors expect them to be consistent with each other.

1. Policies (High-Level Rules)

• Approved by senior management.
• Broad, principle-based statements ("what" and "why").
• Examples:
• "All customer data must be encrypted in transit and at rest."
• "All security incidents must be reported and investigated."

2. Procedures / Standards (Detailed “How To”)

• Owned by process owners or teams.
• Describe step-by-step actions, tools, and responsibilities.
• Examples:
• Steps to configure TLS on web servers.
• Checklist for onboarding/offboarding users.
• Runbook for handling a DDoS attack.

3. Technical Controls (Implemented in Systems)

• Enforced by technology (software, configuration, scripts).
• Examples:
• Firewall rules and security groups.
• IAM policies and role definitions.
• Automated backups and restore scripts.

Good practice in 2025:

• Keep policies short and stable; update procedures and configurations more frequently.
• Ensure traceability:
• Each technical control should support a procedure.
• Each procedure should support one or more policies.
• Each policy/procedure should map to specific TSC criteria.

When auditors review your SOC 2, they often start with policies, then look at procedures, and finally sample evidence from systems to confirm operation.

Step 7 – Quick Check: Control Design and Evidence

Choose the best answer based on what you’ve learned.

Step 8 – Complementary User Entity Controls (CUECs)

CUECs are controls that your customers (user entities) must perform for your system to meet the Trust Services Criteria.

Why they exist:

• Some risks cannot be fully controlled by the service organization alone.
• The SOC 2 report must explain assumptions about what customers do.

Examples of CUECs

1. Access management on the customer side

• "User entities are responsible for managing their own user accounts and permissions within the application, including promptly revoking access for terminated employees."

1. Endpoint security

• "User entities are responsible for maintaining up-to-date antivirus and operating system patches on devices used to access the service."

1. Data input quality

• "User entities are responsible for ensuring the accuracy and completeness of data they upload to the service."

In the SOC 2 report, these appear in a section often titled something like "Complementary User Entity Controls" or "User Control Considerations".

Why they matter:

• If customers do not perform these controls, the overall control environment may not be effective, even if the service organization’s controls work perfectly.
• As a reader of a SOC 2 report, you should check the CUECs and confirm your organization is actually doing them.

Step 9 – Complementary Subservice Organization Controls

Modern services often rely heavily on subservice organizations (e.g., cloud providers, payment processors, ID verification services).

In SOC 2, there are two approaches:

• Carve-out method (most common): Subservice org controls are not fully included in the scope of your SOC 2; instead, you describe how you rely on them.
• Inclusive method: Subservice org controls are included as if they were your own (less common and more complex).

Complementary Subservice Organization Controls

These are controls that the subservice organization must perform for your controls to be effective. They are often described in your SOC 2 as assumed controls at the subservice org.

Examples (for a SaaS company using a major cloud provider):

• The cloud provider:
• Maintains physical security of data centers (guards, CCTV, access logs).
• Performs environmental controls (fire suppression, HVAC, power redundancy).
• Manages hypervisor security and host patching.

Your controls then focus on:

• How you configure and monitor resources in the cloud.
• How you review and rely on the cloud provider’s own SOC reports.

In practice, in 2025:

• Many SaaS providers obtain the cloud provider’s SOC 1 / SOC 2 reports.
• They map the cloud provider’s controls to their own risk assessments.
• They note in their description which controls are complementary subservice organization controls.

As a reader of a SOC 2 report, you should:

• Identify key subservice orgs (e.g., AWS, Azure, GCP, Stripe).
• Check how the service org monitors and relies on those providers.
• Understand which controls are not under the direct control of the service org.

Step 10 – Key Term Review

Flip through these flashcards to reinforce core concepts.

Step 11 – Putting It All Together: Mini Control Set

Imagine you are designing SOC 2 controls for a small SaaS platform with Security and Availability in scope.

Task: For each domain below, propose one control (just a sentence or two). Focus on design, not evidence.

1. Access Control – How will you restrict access to production systems?
2. Change Management – How will you ensure changes are reviewed before deployment?
3. Incident Response – How will you handle security incidents?
4. Vendor Management – How will you manage risks from your cloud provider?

Write your answers, then compare with this sample set:

• Access Control: "All access to production systems is granted through the centralized IAM system based on documented roles, requires manager approval, and enforces MFA for all privileged accounts."
• Change Management: "All production changes must be tracked in the ticketing system, include testing evidence, and be approved by a tech lead before deployment."
• Incident Response: "Security incidents are logged in the incident tracking system, triaged by the on-call engineer within 30 minutes, and escalated according to a documented incident response playbook."
• Vendor Management: "The security team reviews the cloud provider’s SOC 2 report annually, tracks any relevant exceptions, and documents compensating controls where needed."

Notice how each control:

• Names a system or process (IAM, ticketing, incident tracking).
• Identifies who is involved (manager, tech lead, on-call engineer, security team).
• Implies evidence you could show an auditor (tickets, logs, reports).