SOC 2 Control Design, Implementation, and Evidence
Domain 3 - Control design, implementation, and evidence. The exam tests whether you can write a testable control, distinguish design from operating effectiveness, and judge whether evidence will survive an auditor's inspection.
Design that can be tested
A well-designed control names the performer, the action, the frequency or trigger, the population it covers, and the evidence it leaves. 'Security reviews access regularly' fails; 'The IT manager reviews a system-generated active-user list against HR termination reports within five business days of quarter end and logs exceptions in ticket queue SEC-1' passes.
- Preventive controls stop errors; detective controls find them. Automated controls require testing the underlying configuration and the report logic.
Evidence standards
Evidence must be sufficient and appropriate: a complete population, a reliable source, dates inside the period, and a clear tie to each control attribute. Inquiry alone never supports operating effectiveness. Sampling scales with frequency - a daily control needs a larger sample than an annual one - and every exception must be evaluated, not omitted.
Control families and typical evidence
- Access: provisioning and termination tickets, quarterly access reviews, privileged access listings.
- Change: change tickets with approval, testing evidence, segregation between developer and deployer.
- Operations: backup logs, restore tests, incident postmortems, vulnerability scans and remediation SLAs.
- People: onboarding acknowledgements, annual training completion reports.
Worked example
For a quarterly access review: obtain the full population of reviews for the period from the ticketing system, not a hand-picked list; confirm each in-scope system appears; select a sample; inspect reviewer independence, timeliness, completeness of the user listing, and evidence that flagged users were removed. Reasoning: population completeness comes first, because a perfect sample from an incomplete population proves nothing.
Traps
Treating a policy as a control; accepting screenshots with no date or system identifier; matching sample size to the calendar rather than control frequency; testing a control outside the report period; ignoring exceptions.