Foundations Capstone
Pull the whole fundamentals track together on one startup: risks, obligations and recovery targets drive a SOC 2 scope, a control set two people can run, and an evidence plan.
Brief
Northwind is a 40-person B2B startup. Two enterprise deals are blocked on a SOC 2 report, the CEO has promised one "by the summer", and you are the entire compliance function. There is no budget for a GRC platform and no appetite for hiring.
This capstone runs the whole Foundations track end to end on that one company: scope the engagement, sequence the work against a real calendar, design a control set two people can actually operate, plan the evidence before it is needed, and defend the trade-offs to people who will not enjoy hearing them.
Every wrong answer in this room is something a real team has shipped, invoiced, and regretted.
Scoping: boundary first, criteria second
Scope is two decisions. What is inside the system boundary, the production application, the customer database, the deployment pipeline, the identity provider, and which Trust Services Criteria categories apply. Anything outside the boundary must be excluded deliberately and in writing, not by omission.
Security, expressed through the common criteria, is in every SOC 2 without exception. The other four categories are elective: Availability if you have committed to an SLA, Confidentiality if you hold customer data under NDA terms, Processing Integrity for transaction accuracy, Privacy only if you process personal information. Adding categories you do not need is the most expensive unforced error in readiness work.

Sequencing against the calendar
Readiness has a fixed shape. Scope, then a gap assessment against the criteria, then remediation, then the observation window opens, then fieldwork. The critical fact, the one that breaks promises made to CEOs, is that a Type II report examines a period, and the period does not start until the controls exist and are running.
A control implemented three weeks before fieldwork has three weeks of operating history, and the auditor will say so in the report. Everything you build before the window opens is invisible; everything you fail to build before it opens becomes a finding.

Designing a control set two people can run
The temptation is one control per criterion: 61 criteria, 61 controls, each with a quarterly manual review. That set cannot be operated by two people, so within a quarter it becomes 61 controls that exist on paper and a handful that actually run.
Design for operability. One well-instrumented safeguard can answer several criteria. Prefer automated and preventive controls over periodic manual reviews, because they cost nothing per period and produce their own evidence. And in a 40-person company, accept that some segregation is impossible, the founder who approves the deployment is often the founder who wrote it, and design compensating controls rather than pretending otherwise.
Planning evidence and defending the plan
For each control, decide at design time what the artifact will be, where it comes from, and how long it is retained. Retention must exceed the audit period; a seven-day log rotation against a six-month window is a finding waiting to happen.
Finally, expect pressure. Sales will want the report dated earlier. A readiness consultancy will offer to both fix your controls and audit them, which independence forbids. Leadership will ask why you cannot simply include everything in scope. Each of these has a short, calm, correct answer, and being able to give it is most of the job.
You are not being asked to be strict. You are being asked to be right about what the report will say.
Before the audit: risk, obligations and continuity
A SOC 2 scope is only defensible if it follows from the business. Start with the risk register you built in Risk Assessment in Practice: Northwind's top risks are customer data exposure through the production database, loss of the single production region, and a departing engineer keeping access. Each scored risk names an owner and a treatment, and the controls in scope should trace back to those treatments.
Then the obligations register. Two enterprise contracts require breach notification within 48 hours and annual penetration tests; one customer in the EU makes Northwind a processor under GDPR. These obligations are not SOC 2 criteria, but if the control set ignores them the report will be clean and the company will still be in breach of contract.
Finally continuity. The business impact analysis sets an RTO of 8 hours and an RPO of 1 hour for the core product. A nightly backup cannot meet a one-hour RPO, whatever the availability criteria say. Fundamentals are not separate subjects: risk drives scope, obligations add controls, and the BIA sets the numbers the controls must hit.
Trace every control to a risk or an obligation. A control that traces to neither is overhead; a risk with no control is the finding.
This room is the track's final project. Every lab below is one step of a single deliverable - clear them all and the GRC Fundamentals track is complete.
Locked: sign in and finish the track to unlock
- Risk, Control, Compliance
- Frameworks Tour: SOC 2, ISO 27001, NIST
- Control Design & Testing
- The Audit Lifecycle
- Evidence 101
- Policy, Standard, Procedure
- Cybersecurity Essentials
- The Language of Security and GRC
- Governance and Accountability
- Risk Assessment in Practice
- Laws, Regulations and Obligations
- Security Operations Basics for GRC
- Resilience and Continuity
- People and Third Parties
Next on your path · Automation & Code
What Is GRC Engineering?
The failure mode of traditional GRC, what changes when you treat compliance as a software problem, and the skills that define a GRC engineer.
Community
Discussion & writeups
Share how you approached the room or ask where you got stuck. Never paste task answers or full lab solutions: write the reasoning, not the key.
Loading discussion…