SOC 2 Control Points: Why Auditors Expect Granularity

When companies prepare for SOC 2, one of the biggest questions is: How detailed do our controls need to be?

Is it enough to state a broad requirement like “We enforce a Code of Conduct”, or do you need to split that into multiple sub-points?

The reality is clear: auditors expect controls to be broken down into granular sub-controls whenever multiple activities or pieces of evidence are involved. It helps them understand how deeply you evaluate your company.

Why Granularity Matters for SOC 2

SOC 2 is about evidence. Auditors want to test controls directly, which requires each one to be:

• Specific and testable – the control must map to a real activity or policy.
• Tied to distinct evidence – like logs, signed forms, and background check reports.
• Assignable – responsibility should be clear (HR, IT, management, etc.).

If a control is too broad, the auditor cannot test it. In those cases, they will require you to split it into smaller parts.

Example: CC6.1 Breakdown in Practice

Control objective: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.

Here’s how CC6.1 can be broken down into meaningful, auditable sub-controls:

| Sub-control | What auditors test | Evidence reviewed | |---|---|---| | CC6.1.1 MFA Enforcement | Multi-factor authentication required for all remote access | IAM settings, login logs | | CC6.1.2 Unique User Accounts | Each employee has a unique account (no shared logins) | User directory, system account listings | | CC6.1.3 Access Reviews | Quarterly reviews of active accounts vs. HR roster | Access review reports, HR system exports | | CC6.1.4 Termination Access Removal | User accounts disabled immediately upon termination | HR offboarding logs, deprovisioning tickets | | CC6.1.5 Network Segmentation | Production systems separated from internal networks | Network architecture diagrams, firewall configs | | CC6.1.6 Administrative Access Restrictions | Only authorized admins can access production systems | IAM roles, system audit logs |

When to Split Controls

• Split when:

  • Different activities or stakeholders are involved
  • Multiple artifacts/evidence are required
  • Risk areas are distinct

• Keep whole when:

  • The control is simple, clearly defined, and maps to one activity.
  • Example: CC2.2 Security Awareness Training → “All employees complete annual training.”

Company Size and Context

It’s also important to remember: granularity scales with context.

• A small business with two employees might combine certain controls if the same people perform all activities.
• An enterprise with hundreds of employees will almost always need multiple sub-controls because auditors expect to see formal evidence across different departments, vendors, and processes.

The guiding principle is: if a control can naturally be split into testable pieces, the auditor will expect it.

Best Practices for Preparing SOC 2 Controls

1. Start broad, refine later: Draft high-level controls first, then add sub-controls where necessary.
2. Think like an auditor: Ask, “Could this control be tested with clear evidence?”
3. Avoid over-engineering: Don’t invent sub-points if there’s no meaningful difference in activity or evidence.
4. Document cross-references: Show how one sub-control may support multiple CCs.

If a control involves multiple activities, systems, or evidence sources, auditors will expect you to break it down. If it’s straightforward and fully testable as one control, you can keep it whole.

👉 In short: granularity depends on context but when in doubt, expect auditors to push for more detail, not less.