Every SOC 2 program eventually asks the same question: which controls actually cover which criteria? The Trust Service Criteria describe outcomes — access is restricted to authorized users, changes are managed, incidents are detected — but they don’t hand you a list of controls to implement. That gap is closed by the control matrix: the document that ties each control an organization actually runs to the criterion, or criteria, it addresses, along with the evidence that proves it operated. Building that matrix well is less about memorizing a checklist and more about understanding how criteria, points of focus, and controls relate to one another — and it’s the artifact an auditor spends the engagement testing against.
Criteria vs Controls, and What “Points of Focus” Actually Are
SOC 2 is not a certification. It’s an attestation report, issued under the AICPA’s SSAE 18 standard, in which an independent CPA firm renders an opinion on whether a company’s controls meet the Trust Service Criteria (TSC) it selected. That distinction matters because there’s no official master list of “SOC 2 controls” to implement — the TSC describe what an organization needs to achieve, not how to achieve it. Security is the one mandatory category, covered by the nine Common Criteria, CC1 through CC9; Availability, Confidentiality, Processing Integrity, and Privacy are added only when the company has actually made a promise in that area worth testing.
Underneath each criterion, the AICPA’s TSC document lists “points of focus” — characteristics that illustrate what suitably designed and operating controls might look like. They’re guidance, not a checklist: points of focus may not be relevant to every entity, and management is free to identify others that fit its own environment. Nowhere does the framework say “use this identity provider” or “review access on this exact cadence.” The entity — not the auditor, not the framework — selects and designs the controls that satisfy each criterion.
A control is simply an activity or mechanism the organization actually performs — a policy that’s enforced, a system that’s configured, a review that happens on a cadence — that reduces the risk the criterion is asking about. The relationship is deliberately not one-to-one: a single control can satisfy several criteria at once, and most criteria need more than one control working together. That many-to-many relationship is exactly what a control matrix exists to document.
Why You Build a Control Matrix
The control matrix — sometimes called a controls-to-criteria matrix, or simply the control mapping — is the document that lists every control the organization runs, the criterion or criteria each one addresses, and the evidence that demonstrates it operated. It sounds like paperwork, but it’s the single artifact that turns an abstract framework into something auditable.
- Coverage: shows which criteria have real, mapped controls and which are thin or unaddressed, before an auditor finds the gap first
- Efficiency: reveals where one control, like SSO with enforced MFA, already satisfies several criteria at once, so the team isn’t duplicating effort
- Audit navigation: auditors test controls, not criteria — they request evidence and trace it back to coverage, exactly how the matrix is structured
- Change management: when a system or process changes, the matrix shows precisely which criteria are affected
Without a matrix, a company can genuinely believe it’s ready for a SOC 2 audit and be wrong — the gaps only surface when an auditor asks a question nobody has evidence to answer.
How to Build It: Top-Down From Criteria, or Bottom-Up From Existing Controls
Top-down: start from the criteria
Working top-down means starting with the TSC document itself and, for each criterion, asking what controls would need to exist to meet it, using the points of focus as prompts. This suits a company building its security program largely from scratch: it guarantees every criterion gets deliberate attention, because nothing gets mapped until someone has asked the question directly.
Bottom-up: start from what already exists
Working bottom-up means inventorying the controls, tools, and processes already running — the identity provider, the code review policy, the incident response process, the backup schedule — and mapping each against whichever criteria it happens to satisfy. This is usually faster for a team with real security practices already in place, and it often reveals the company is closer to audit-ready than it assumed.
The strongest matrices are built both ways: bottom-up first, to capture what’s real and already running, then a top-down pass as a gap check against the full criteria list. Bottom-up only tends to leave quiet gaps around criteria nobody happened to already be solving for, like a formal risk assessment. Top-down only risks describing controls on paper that nobody has actually implemented.
A control mapped but not actually operating is worse than an honest gap. An honest gap is a known risk to remediate; a paper control is a finding waiting to happen, because the auditor asks for evidence the control operated, not evidence it was written down.
Worked Example Mappings
The clearest way to see mapping in action is a few Common Criteria, plus category-specific criteria, walked through plausible controls and the evidence each generates.
| Criterion | Example controls | Evidence |
|---|---|---|
| CC1–CC2 (Control Environment / Communication) | Org structure, security policies, security awareness training | Org chart, policy acknowledgments, training records |
| CC3–CC5 (Risk Assessment / Monitoring / Control Activities) | Risk assessment process, control design review | Risk register, assessment notes, review sign-offs |
| CC6 (Logical & Physical Access) | SSO with MFA, RBAC, access reviews, encryption at rest and in transit | MFA config, access review logs, encryption configs |
| CC7 (System Operations) | Monitoring and alerting, incident response, vulnerability management | Alert configs, incident tickets, scan reports |
| CC8 (Change Management) | Code review, CI/CD approvals, change tickets | PR approval logs, pipeline records, change history |
| A1 (Availability — if in scope) | Capacity monitoring, backups, DR testing | Capacity dashboards, backup logs, DR reports |
| C1 (Confidentiality — if in scope) | Data classification, encryption, secure disposal | Classification policy, key records, disposal certificates |
| PI1 (Processing Integrity — if in scope) | Input and processing validation | Validation results, error logs |
Notice the overlap. A single SSO deployment with enforced MFA can satisfy several CC6 points of focus at once — restricting access, managing credentials, authorizing users — while also feeding CC1’s access-provisioning story. CC7 rarely comes down to one control either: monitoring without incident response just generates alerts nobody acts on. That’s the many-to-many reality the matrix has to hold — map every control to every criterion it genuinely touches.
Availability, Confidentiality, and Processing Integrity aren’t automatic additions — they belong in the matrix only if the system description actually commits to them. Mapping controls to a category nobody promised just adds audit scope with no buyer benefit.
Avoiding Over-Scoping and Orphan Controls
The most common mapping mistake runs in the expensive direction: adding criteria categories, and the controls and evidence that come with them, that the company never actually committed to. More categories can look thorough on the cover page, but each one means more evidence to collect and a longer, costlier audit for promises the buyers never asked about. Scope should match the promises actually made — Security is mandatory, everything else is opt-in, based on what the business genuinely offers.
The opposite mistake is the orphan control, in two shapes: a control that runs but isn’t mapped to anything, so nobody tracks it for the audit; or a criterion mapped only to a control that exists on paper, with nothing operational behind it. Both surface the same way — by walking the finished matrix end to end and confirming every control maps to a criterion, and every criterion has a control that’s demonstrably running, not just documented.
- Every control maps somewhere: if it doesn’t tie to any in-scope criterion, ask why it’s being maintained for the audit at all
- Every criterion has a real control: an operating control with an evidence trail, not a policy statement alone
- No unpromised categories: Availability, Confidentiality, Processing Integrity, or Privacy shouldn’t appear without a matching commitment in the system description
- Multi-criteria controls mapped fully: list a control against every criterion it touches, not just the one it was built for
Keeping the Matrix a Living Document, Tied to the Risk Assessment
A control matrix built once for the first audit and never revisited ages badly. New systems get added, vendors change, teams grow, and the risks the company faces shift — a mapping calibrated for a ten-person startup rarely fits at a hundred people with a second product line. Treating it as a one-time deliverable is how companies end up scrambling mid-audit to explain why a control the matrix claims is running was quietly retired months earlier.
The fix is tying the matrix explicitly to the risk assessment rather than treating them as separate documents. Every risk in the register should trace forward to the controls that mitigate it; every control should trace back to the risk and criterion it addresses. When the risk assessment is updated — a new system, a new vendor, an incident that reveals a gap — the matrix should be reviewed in the same sitting, not on a separate schedule months later. Reviewing both together, at minimum annually and always before a new Type II observation period begins, keeps the matrix describing the company that exists today.
The cleanest programs cross-reference the risk register and control matrix by ID — each risk points to the controls that treat it, each control points back to the risk and criteria it addresses. Pull on any thread and land on the same consistent story.
Final Thought
A control matrix isn’t a compliance formality — it’s the honest answer to “how do we know our controls actually cover what we said we’d protect.” Built well, it does three things at once: it proves coverage to an auditor, it stops the company from quietly over-scoping into categories nobody asked for, and it gives the team a single place to see exactly which risk each control stands between the business and.
The test: pick any Trust Service Criterion in scope and ask which control satisfies it, and what evidence proves that control ran last month. If the answer takes more than a minute to find, the matrix isn’t finished — it’s aspirational.
Frequently Asked Questions
A control matrix is the document that lists every control an organization runs, maps each one to the Trust Service Criteria it addresses, and links it to the evidence that proves it operated. It’s the artifact that turns the abstract criteria into something an auditor can actually test against.
Points of focus are characteristics listed under each Trust Service Criterion that illustrate what suitably designed and operating controls might look like. They’re guidance for management, not a mandatory checklist — the entity still selects and designs the specific controls that meet the criterion.
Yes, and it usually does. A single control like single sign-on with enforced multi-factor authentication can satisfy several points of focus across CC6 while also supporting access-related evidence elsewhere. The relationship between controls and criteria is many-to-many, not one-to-one, which is exactly why a matrix is needed to track it.
Top-down starts from the Trust Service Criteria and designs controls to meet each one — useful when building a security program from scratch. Bottom-up starts from the controls an organization already runs and maps them to whichever criteria they satisfy — faster for teams with existing security practices. The most effective matrices combine both: bottom-up to capture what’s real, top-down as a gap check against the full criteria list.
Because each additional category — Availability, Confidentiality, Processing Integrity, Privacy — adds controls and evidence the audit will test, with a real cost in time and scope. Categories should match what the company’s system description actually promises. Adding categories nobody asked for increases audit burden without giving buyers anything they were looking for.