Lion Cipher Lab

Design a SOC 2 Type II control environment: system description, TSC mapping, CUECs, and a control/evidence matrix

• GRC / Compliance
• Advanced
• ~80 min
• Free · no account required

Why it matters

Reading a SOC 2 report is a skill; being the organization the report is ABOUT is a different one, and it is the one that decides whether an audit goes smoothly or turns into a six-month bonfire of money and engineering time. The most expensive mistakes in a SOC 2 are made before the auditor ever shows up — in scoping. Over-scope (throw all five Trust Services categories in because 'more looks better') and you have just signed up to prove operating effectiveness, across an entire period, for Privacy and Processing Integrity controls you may not even have — every one of which is now a potential…

What you'll learn

• writing a SOC 2 SYSTEM DESCRIPTION against the AICPA description criteria (DC section 200): services, system boundary, infrastructure/software/people/data, and principal service commitments & system requirements
• scoping the Trust Services Criteria honestly: Security (Common Criteria) always in, plus a justified include/exclude for Availability, Confidentiality, Processing Integrity, and Privacy — with written rationale
• reading the Common Criteria (CC1-CC9) and their 'points of focus' as design inputs, not a checklist to pass
• building a control / criteria / owner / frequency / EVIDENCE matrix that maps each criterion to designed controls
• distinguishing Type I (suitability of DESIGN at a point in time) from Type II (OPERATING EFFECTIVENESS across a period) and designing evidence that survives period sampling
• separating a CONTROL (the recurring activity) from its EVIDENCE (the artifact that proves it ran) — the distinction auditors test on
• authoring Complementary User-Entity Controls (CUECs) as a defensible shared-responsibility boundary
• recognizing over-scoping vs under-scoping and the cost of each to the audit and to sales
• mapping controls to a common control framework ONCE so a single control set can satisfy SOC 2, ISO 27001, and customer security questionnaires
• explaining to a buyer why a clean SOC 2 opinion is assurance about controls, not a guarantee of security

Steps in this lab

1. The vocabulary, defined once (so the rest of the lab is unambiguous)
2. Deliverable 1 — the SYSTEM DESCRIPTION (the thing the opinion is ON)
3. Deliverable 2 — choosing the TSC scope, and DEFENDING it
4. Deliverable 3 — the control / criteria / owner / frequency / EVIDENCE matrix
5. Deliverable 4 — Complementary User-Entity Controls (CUECs)
6. When NOT to over-scope — and the honest failure modes of scoping
7. The way a pro does it differently — map to a common framework once

Open the full interactive lab →