1. What a SOC 2 report actually is
SOC 2 is an attestation report written by a licensed CPA firm about how your controls are designed and, in a Type II, how they operated over a period of time. It is not a certificate. Nobody is “SOC 2 certified”, however often the phrase appears in sales decks: you hold a report, you share it under NDA, and the reader decides whether it satisfies them.
The criteria come from the AICPA: the 2017 Trust Services Criteria, with revised points of focus published in 2022. There are five categories, and only the first is in every report:
- Security, the common criteria. Always in scope.
- Availability, Confidentiality, Processing integrity and Privacy, scoped in only when they matter for what you sell.
One nuance that saves arguments later: the points of focus are not mandatory controls. The AICPA is explicit that they are characteristics to consider, not a checklist to implement. Your auditor evaluates whether your controls meet the criteria, not whether you copied someone's template.
2. Type I and Type II, in engineering terms
Type I asks: on this date, were the controls suitably designed? Type II asks: across this window, did they actually operate? The second question is the one that changes how you build.
| Type I | Type II | |
|---|---|---|
| Question | Are controls designed properly? | Did they operate throughout the period? |
| Covers | A single date | A window, commonly three months for the first report, then twelve |
| Evidence | Configuration as it stands | Samples pulled from across the window |
| What buyers accept | Often a stopgap | The report enterprise procurement actually wants |
The consequence people miss: in a Type II the auditor samples. If access reviews were supposed to happen quarterly and one quarter has no record, the control has an exception, and no amount of tidying up in the final week repairs a window that already passed. Evidence has to be produced by the system as it runs, or it does not exist.
3. The common criteria as an infrastructure backlog
Strip the language back and the Security category asks for nine ordinary engineering practices. Here is what each one looks like in a production setup, and what your auditor will ask you to pull.
| What the criteria ask for | What you build | What the auditor pulls |
|---|---|---|
| Logical access | SSO with MFA, named identities, roles defined in code, no shared admin accounts | User list with roles, MFA coverage, joiner and leaver records for sampled people |
| Change management | Every change through a pull request, review required, pipeline enforces tests and rollback | A sample of changes with reviewer, approval and deployment record |
| Monitoring | Alerting tied to symptoms users feel, routed to an owner, with escalation | Alert history and who acknowledged each one |
| Incident response | Documented process, timeline captured automatically, corrective actions tracked to closure | Incident tickets, post-incident reviews, the pull requests that closed them |
| Risk assessment | A register that is revisited when architecture changes, not annually out of habit | The register with dates and owners |
| Vendor management | Inventory of subprocessors and dependencies, review cadence, security terms in contracts | Vendor list with review dates and their own SOC 2 reports |
| Vulnerability management | Image and dependency scanning in the pipeline, patch cadence with owners and deadlines | Scan results over the window and remediation timestamps |
| Backup and recovery | Backups defined as code, off-site copies, restores rehearsed on a schedule | Restore drill records with dates, duration and who ran them |
| Encryption | TLS everywhere, encryption at rest, key custody and rotation defined | Configuration as code, key management policy |
Read the middle column again. There is nothing in it that a competent platform team would not want anyway. That is the useful way to think about SOC 2: it is not a security programme bolted onto engineering, it is engineering discipline with a paper trail attached.
4. What a compliance platform does and does not do
Drata, Vanta and their competitors are good products, and they solve a real problem: collecting, organising and continuously testing evidence, and giving the auditor a place to look. Buy one if the alternative is a spreadsheet.
What they do not do is build the controls. When the dashboard says “MFA not enforced on the production cluster”, somebody still has to change the identity provider, migrate the service accounts, fix the CI credentials that break, and prove nothing else broke. The gap between a red row and a green one is engineering work, and that is where most SOC 2 programmes stall for months.
The honest split: the platform is the filing cabinet, the auditor is the assessor, and someone has to be the builder. Choose all three deliberately.
5. Five things that go wrong in the first Type II
- Starting the window before the controls exist. The observation period is only as good as its worst month. Get the controls in place, run them for a few weeks, then start the clock.
- Screenshots as evidence. A dashboard image from March proves nothing repeatable. Exports, logs and system-generated records survive an auditor's follow-up question.
- Shared administrative accounts. One
adminlogin used by four people breaks access control and attribution at once, and it shows up in every sample. - Backups nobody restored. Auditors ask for restore records, not backup schedules. An untested backup is an assumption.
- Scope drift. Adding a product line or a region mid-window without extending the controls creates exceptions that surface at the worst moment.
6. A realistic timeline
For a team with ordinary production infrastructure and no formal programme yet:
- Weeks 1-3: scope and gap. Which systems and data are in scope, which trust services categories apply, what already exists. Most of the evidence is scattered across systems you already run.
- Weeks 4-9: build. The gaps that carry real risk first: MFA everywhere, named identities, secrets out of repositories, change control enforced by the pipeline, backups with a rehearsed restore, alerting with owners.
- Weeks 10-12: instrument. Evidence collection automated, retention agreed, the compliance platform wired to the real systems rather than to intentions.
- Then: run the window. Three months minimum for a first Type II, with the controls genuinely operating. The audit itself is short by comparison.
Roughly two to three months of engineering, then the observation period. Anyone promising a Type II in six weeks is either selling a Type I or planning to fail a sample.
7. How this relates to ISO 27001 and NIS2
If you sell into several markets you will meet all three, and the technical layer is largely shared. What differs is what each one accepts as proof.
- ISO 27001 certifies a management system: scope, risk treatment, a Statement of Applicability against the 93 controls of Annex A, internal audit, then a three-year cycle with annual surveillance audits. More documentation than SOC 2, and the certificate is public.
- NIS2 is EU law, so there is no certificate at all: a supervisory authority can ask for evidence, and Article 23 puts a 24 hour, 72 hour and one month clock on incident reporting. We covered the engineering side of it in NIS2 in Practice.
Build the controls once, then present the evidence in the shape each framework expects. Teams that treat them as three separate projects pay for the same work three times.
8. Where we fit
DigitalCare is the builder, not the auditor. We implement the technical controls in your infrastructure as code, keep them enforced and monitored, and make the evidence a by-product of running the system rather than a quarterly scramble. Our agents watch posture continuously and remediation ships as pull requests your engineers review and merge, so every change carries an approver and a timestamp.
We do not issue reports and we do not promise an audit outcome: that stays with your CPA firm. If the part you are missing is the engineering between a red dashboard row and a green one, see Security and Compliance Automation or send us your current setup and we will tell you where the real gaps are.
This article is engineering guidance, not legal or audit advice. Scope, criteria selection and the final opinion are your auditor’s to determine.
