← ISO and SOC Certifications

SOC 2

A service organization controls report on the Trust Services Criteria. Updated: September 29, 2026.

SOC 2 is what North American buyers mean when they ask for your security documentation. It is an attestation examination and report, not a certification — so there is no such thing as being “SOC 2 certified”, and no SOC 2 certificate exists to be issued. An independent practitioner examines the controls you have described, tests them, and reports an opinion together with the results of the testing — including any exceptions.

That last part is the thing to internalise, in both directions. When you receive a SOC 2 report you are being handed a list of the vendor's control failures, which is more information than any certificate gives you. When you produce one, your failures are printed in it.

What It Covers Is Your Choice

There are five Trust Services categories, and Security — the common criteria — forms the core of every SOC 2 examination. The other four are included only where they are applicable to the system and the organisation chooses to bring them into scope:

• Security. The system is protected against unauthorised access, use and modification. Always present.
• Availability. The system is available for operation and use as committed.
• Processing integrity. Processing is complete, valid, accurate, timely and authorised.
• Confidentiality. Information designated as confidential is protected as committed.
• Privacy. Personal information is collected, used, retained, disclosed and disposed of in line with the organisation's stated notice.

So no SOC 2 report necessarily covers all five, and “we have SOC 2” is an incomplete statement. If you depend on a vendor's uptime and the report omits Availability, nothing about uptime was examined. Ask which categories are in scope before you accept a report as an answer.

Type 1 and Type 2 Are Very Different Documents

These are not a smaller and a larger version of the same thing. They examine different subject matter, and the opinion covers different ground.

• Type 1 examines the description of the system and whether the relevant controls are suitably designed as of a specified date. The opinion addresses design, at a point in time.
• Type 2 examines the same description and design and additionally the operating effectiveness of those controls throughout a specified period — commonly three to twelve months — with the practitioner testing evidence sampled across that whole window.

The practical consequence follows from the subject matter rather than from effort: a Type 1 opinion says nothing at all about whether the controls were used after that date, because operation over time was not within its scope. Buyers who are assessing reliance normally want a Type 2 for exactly that reason. A common path is a Type 1 while a first observation period accrues, followed by a Type 2 covering that period.

What Is Inside the Report

1. Management's assertion. Your own statement about your system and controls. You are the one making the claim; the auditor is testing it.
2. The independent auditor's opinion. The page that matters. Unqualified means clean. A qualified opinion means something material was wrong. Adverse and disclaimer are worse and are rare.
3. The system description. What the service is, its boundaries, and what is and is not included. This is the scope, and it is written by you.
4. The controls, the tests, and the results. The longest section and the one worth reading. Every control, how the auditor tested it, and whether any exceptions were found.
5. Other information, which is unaudited — typically management's response to the exceptions.

The part nobody reads: complementary user entity controls

Buried in most reports is a list of complementary user entity controls — things the report assumes you do for the vendor's controls to be effective. Configuring access properly, enabling multi-factor authentication, reviewing your own user lists. If you do not do them, the vendor's clean opinion does not protect you, and the report says so in a section most readers skip. It is the single most useful page in the document when you are assessing a supplier.

How You Get One

1. Choose the criteria and the scope — which systems, which services, which of the five criteria. Narrow is legitimate and cheaper; too narrow and customers will reject it.
2. Readiness assessment. Usually with an advisory firm, identifying what is missing before the auditor sees it.
3. Implement and, crucially, start generating evidence. Access reviews with records, change tickets, onboarding and offboarding trails, vulnerability scans, incident records. Type 2 tests evidence across the whole period, so evidence that begins in month five of a six-month window is a finding.
4. Engage a licensed audit firm. In the United States, a CPA firm — only they may issue the report. Confirm they are licensed and that they do this regularly.
5. The observation period runs, with the auditor sampling from it.
6. The report is issued, and you repeat it annually. A report older than about a year stops being accepted.

Realistically: three to six months to a Type 1 from a reasonable starting position, and a Type II a further three to twelve depending on the window you choose.

What Does a SOC 2 Auditor Actually Look At?

The criteria are written abstractly, so for an engineering team the useful translation is the list of control domains a practitioner typically walks through. What follows is representative, not prescriptive — the exact controls tested depend on your system, your risks and the scope you agreed, and two SOC 2 reports for similar companies routinely differ.

• Identity and access management — how accounts are created, authorised and removed across systems.
• Privileged access — who holds administrative rights, how it is granted, and whether it is time-bound or standing.
• Joiner / mover / leaver — access following people as roles change, and revoked on departure. See user management and permissions.
• Multi-factor authentication — where it is enforced, and where it is not — see security settings.
• Change management — how a change is proposed, reviewed, approved and released.
• Source-code changes and approvals — peer review, and whether the author can merge their own work.
• CI/CD controls — what the pipeline enforces, who can alter it, and who holds its credentials. See CI/CD setup.
• Production deployments — who can deploy, and whether a deployment can bypass the pipeline.
• Vulnerability management — how issues are found, triaged and tracked to closure.
• Patch management — and whether your own stated timescales are met — see patch management.
• Security monitoring and logging — what is collected, retained and watched. See log aggregation and resource monitoring.
• Incident management — detection, response, and follow-up — incident handling.
• Backup and recovery — and whether restores are actually tested — backup and recovery.
• Disaster recovery and business continuity — the plan, and evidence it has been exercised — disaster recovery planning.
• Infrastructure configuration — hardened baselines and how drift is detected — OS installation and hardening.
• Cloud security controls — network boundaries, storage exposure, encryption, and the security of the cloud accounts themselves.
• Vendor and third-party management — who you depend on, and what you did about their assurance reports.

Example Evidence

The practitioner does not accept that a control exists; they ask for records showing it operated, sampled across the period. Typical artefacts:

The pattern across all of them: the control existing is not the evidence. The evidence is the dated record that it ran, across the full observation period. Assembling it retrospectively is where SOC 2 work most often goes wrong.

The Gap Between Reports

A SOC 2 report describes a period that has already ended. Today's date may be six months past the end of the window. The instrument for covering that interval is a bridge letter (sometimes a gap letter) — but note that it is written by the vendor's management, not by the auditor, and it is unaudited. It is a statement of good faith, not evidence. Treat it as such, in both directions.

SOC 2 or ISO 27001?

Where both are on the table, the market usually decides: SOC 2 for US buyers, ISO 27001 for European and Asian ones and for public tenders. The underlying control work overlaps heavily, so doing both is far less than twice the effort — and doing ISO 27001 first tends to be easier, because its management system produces the evidence discipline that SOC 2 testing depends on. See also SOC 1 for services affecting financial reporting, and SOC 3 for the publishable summary.

References

• AICPA & CIMA — SOC 2 resources and the Trust Services Criteria.
• AICPA & CIMA — The SOC suite of services, for how SOC 1, 2 and 3 differ.

This page explains the report from an infrastructure perspective. We are not an audit firm and this is not legal or assurance advice.