SOC 2 control matrix: how to map controls to criteria

What a SOC 2 control matrix is and how to build one

A SOC 2 control matrix is the single set of controls an organization runs, each mapped to the applicable criteria in the AICPA's 2017 Trust Services Criteria, with a named owner and the evidence that proves the control operated. The organization owns and operates these controls. An independent CPA firm tests them and issues the report, and no implementation partner or consultant can issue that opinion. If a customer or contract has asked for a SOC 2 and no matrix exists yet, the first job is not writing controls. It is deciding which systems, categories and third parties the matrix must cover, because every later choice depends on that boundary.

Four factors change the matrix from one organization to the next. The first is the systems in scope: the production application, its cloud accounts, the identity provider, and the build pipeline each need controls that the auditor can trace. The second is the categories included. Security is always in scope through the common criteria CC1 to CC9, while availability, confidentiality, processing integrity and privacy add their own criteria only when the organization chooses them. The third is the third parties involved, such as cloud hosts, code hosting and support tools, which determine what is carved out and what must be covered by vendor oversight under CC9.2. The fourth is how mature the existing controls already are. A team with documented access reviews and ticketed changes starts with evidence it can reuse, while a team that approves changes in chat must redesign the process before the matrix can describe it. Confirm each of these four factors in writing before any control is drafted.

Which criteria the matrix must cover for your system

The 2017 Trust Services Criteria contain 61 criteria in total. The common criteria CC1 to CC9 apply to every SOC 2 and hold 33 criteria, from CC1.1 to CC9.2, while the four other categories add criteria only when they are in scope. Confirm the categories with your CPA firm before you map a single control.

CC1 to CC5: control foundations

These series restate the 17 COSO internal control principles, covering integrity and ethics, board oversight, communication, risk assessment, monitoring and control activities. Every control in the matrix should trace back to at least one of these foundations. Check that governance records such as board minutes, policy approvals and risk registers exist for each principle, because auditors test those records as well as the controls themselves.

CC6 to CC9: operations and risk

These series add the criteria most engineering teams recognize: logical and physical access (CC6), system operations and incident response (CC7), change management (CC8) and risk mitigation including vendor oversight (CC9). They usually generate the largest share of evidence requests. Map each access, change and monitoring control to a named system of record so the population can be drawn and sampled during fieldwork.

A1 availability: three criteria

The availability category adds criteria on capacity management, environmental protections, backup and recovery infrastructure, and recovery plan testing. Include it only when customers rely on uptime or recovery commitments in contracts or service descriptions. If you include it, the matrix needs controls that produce capacity data, backup job results and recovery test records, not only written plans.

C1 confidentiality: two criteria

The confidentiality category covers identifying and protecting confidential information and disposing of it when it is no longer needed. Add it when customer contracts or non-disclosure terms define data as confidential. Controls should show how confidential data is classified, where it is stored and how deletion is verified, so ask your CPA firm which systems hold that data before you write the mapping.

PI1 processing integrity: five criteria

Processing integrity covers processing specifications and controls over inputs, processing, outputs and storage. It fits platforms where customers rely on the accuracy of calculations, transactions or data transformations. Expect the matrix to need validation rules, reconciliation checks and error handling records. Confirm with the CPA firm whether the category applies before you spend effort on these controls.

P1 to P8 privacy: eighteen criteria

The privacy category holds 18 criteria across notice, choice and consent, collection, use, retention, disposal, access, disclosure, quality, and monitoring and enforcement. It is the largest optional set and often overlaps with GDPR or other privacy duties. Decide early whether privacy is in scope, because it changes the policies, retention rules and data subject request records the matrix must support.

How to build the matrix from criteria to evidence

The five phases run in order: inventory the scope, list the controls, map them to criteria, assign owners and cadence, and define the evidence an auditor will inspect. Each phase produces an artifact that the next one depends on, and the finished matrix feeds the system description and the evidence request list.

Inventory the in-scope systems and third parties
Start by listing what the examination will cover: the production systems, the data they store or process, the locations and cloud accounts that host them, and the third parties that touch them. Engineering and operations leads usually own this list, with the security or compliance lead reviewing it against the trust services categories chosen for the report. The output is a scope inventory that names each system, its data classes, its hosting location and each subservice provider. You know the step is done when every system in the inventory has an owner and when the scope inventory matches the boundary you intend to describe in the system description.
List existing and planned controls
Next, record every control the organization runs or plans to run against that inventory. Each entry needs a short plain-language description of what the control does, the system it protects, and whether it is operating today or planned. Include technical controls such as access provisioning and log collection, and procedural controls such as policy approval and vendor review. Pull from existing policies, tickets and runbooks so the list reflects what people actually do rather than what a template says. The output is a control register with one row per control. The step is complete when a reviewer can point to a system for every control and no control is described only in general terms.
Map each control to the criteria it supports
Map every control in the register to each criterion it supports, using the 2017 Trust Services Criteria and its points of focus as guidance for design and evaluation, not as a checklist that every point must satisfy. Many controls serve several criteria, so record each link rather than duplicating the control. Mark which criteria in the applicable categories have no control yet, and which have only one control carrying the full load. The output is a control-to-criteria map plus a gap list. Teams often reuse an existing mapping from ISO 27001 or a NIST crosswalk at this point, but each reused link should still be checked against the control's real behavior. The step is done when every common criterion in scope has at least one mapped control or a documented gap.
Assign owners and review frequency
For each control, name one accountable owner who can explain how it works and produce its evidence, and set the review frequency that the control itself requires. A quarterly access review, a continuous alert on failed logins and an annual policy approval each need a different cadence, and the frequency should match how the control is designed to run. Owners should be people with authority over the system, not only the team that prepares the paperwork. The output is an ownership and cadence column in the matrix. The step is complete when no control lacks a named owner and every recurring control has a cadence that someone has agreed to run.
Define the evidence and its population
For each control, define the evidence the auditor will inspect, such as a system-generated access report, a change ticket with approval, a configuration export or a log sample, and state the population it is drawn from. The population matters because auditors test samples from a defined set, so the matrix should say which tickets, accounts, hosts or deployments make up that set and where the records live. Prefer system-generated records over screenshots where the platform can produce them, and note any control whose evidence depends on a manual record. The output is an evidence specification for each control. The step is done when a reviewer could hand each row to a person who can produce the evidence without asking the control owner what it means.
Feed the matrix into the system description and evidence requests
Finally, confirm that the matrix is consistent with the rest of the examination file. Controls and their owners should match the system description, including any complementary user entity controls and subservice organization treatment that the matrix relies on. The evidence specifications become the starting point for the evidence request list, so each row should be traceable to a request. Ask an independent reviewer or the CPA firm to read a sample of rows and challenge the mapping. The output is an approved matrix version that management can sign off on. You know the step is complete when the system description, matrix and evidence list reference the same controls with the same names and owners.

How to use points of focus without treating them as a checklist

The 2017 Trust Services Criteria, in the version with revised points of focus published in 2022, attach points of focus to each criterion as characteristics that can help you design and evaluate controls. They are not separate requirements, and not every point of focus has to be addressed. The practical consequence for your control matrix is that a criterion can be fully met by a control design that addresses only some of its points of focus, provided the design still achieves the criterion. Treating each point of focus as a line item that needs its own control produces a matrix that looks thorough but is hard to defend, because the auditor will test the controls, not the number of boxes ticked.

CC5.1 shows how this works. Its points of focus cover integration with risk assessment, entity-specific factors, relevant business processes, a mix of control activity types, the level at which activities apply, and segregation of duties. For a SaaS company, a reasonable starting point is to confirm that each control in the matrix traces back to a risk in the CC3 risk register, that approvals for production access and change deployment are separated from requesting them, and that you can explain why a mix of preventive and detective controls fits your environment. Points such as the level at which an activity applies may be relevant to one system and immaterial to another, so the matrix should show a deliberate decision rather than silence.

For each criterion, record in the matrix whether each relevant point of focus was addressed by an existing control, adapted to your environment, or set aside, along with a short reason. A set-aside entry might say that a point concerns a business process your system does not perform, and name the evidence that supports that statement. This reasoning is what reviewers and auditors ask about first, because it shows that the design reflects your entity rather than a template. Ask your auditor early which level of rationale they expect and whether they want the reasoning kept in the matrix or in a separate design memo, and have the control owner sign off on each entry.

Build from criteria or start from an existing mapping

This table compares three ways to start a SOC 2 control matrix, plus a GRC tool that carries framework mappings. Read each row as a starting point that still needs your own system scope, control design and evidence checks. The main takeaway is that no mapping replaces your own review of how your controls meet each applicable criterion.

Approach	What it gives you	What you must still check
Build directly from the 2017 TSC	A matrix tied to each criterion and its points of focus, designed around your own system, risks and commitments.	Every applicable criterion has at least one control, the points of focus you skipped have a stated reason, and the control set fits your environment rather than a template.
Start from the AICPA mapping of ISO 27001 to the 2017 TSC	A published correspondence between ISO 27001 requirements and the 2017 TSC, published 4 May 2018 with March 2020 updates, which can cut duplicate work if you already hold ISO 27001 controls.	Access to the mapping requires AICPA or CIMA membership, the mapping is a correspondence rather than a substitute for your own design, and your ISO controls must actually operate as the mapping implies.
Start from the NIST Privacy Framework crosswalk to the 2017 TSC	A crosswalk posted November 2023 in the NIST privacy resource repository, useful as a starting point for privacy and GRC teams doing readiness work.	NIST offers it without a guarantee of accuracy, so confirm each row against the current criteria text and check it covers the categories you have in scope.
Use a GRC tool such as CISO Assistant (AGPL-3.0-only)	A tool that ships more than 200 frameworks including SOC 2 and runs assessments with automatic mapping between frameworks.	Confirm how each automatic mapping was produced and reviewed, which framework version it uses, and whether your auditor accepts the tool's evidence trail before relying on it.

Reusing ISO 27001 or NIST mappings without inheriting their gaps

Reuse saves real work, but only if you treat each reused control as a new claim. ISO/IEC 27001 and the NIST frameworks overlap heavily with the common criteria, particularly CC3 risk assessment, CC5 control activities, CC6 access, CC7 system operations and CC8 change management, so one control often serves both an ISO 27001 Annex A control and a SOC 2 criterion. Start from the mappings your team already holds, such as the AICPA's mapping of ISO 27001 to the 2017 Trust Services Criteria, which is available to AICPA and CIMA members, or the NIST Privacy Framework crosswalk to the 2017 TSC posted in November 2023. Confirm your access to the AICPA document before you plan around it.

The risk is that a mapping only says two items are related. It does not say the control meets the criterion for your system, your population, your observation period and your evidence. The NIST crosswalk is offered as a starting point with no guarantee of accuracy, and an ISO-to-TSC mapping says nothing about whether your ISO control operated across the months an auditor will sample. A reused control can pass an ISO surveillance audit and still fail a Type 2 test because its evidence is a screenshot taken on one day, or because it covers only part of the in-scope system.

For each inherited mapping, re-read the criterion wording and the points of focus in the 2017 TSC, then decide whether the control, as operated in your environment, addresses the criterion you have mapped it to. Record which mappings were inherited from which framework, the version used, the person who verified each one and the date of verification. Keep that register with the control matrix so an auditor can see the reasoning, and so that a later change to the ISO control does not silently change your SOC 2 position. Point out any gap in the register to your auditor early, since a documented gap is easier to resolve than one found during fieldwork.

Who does what: your team, the implementation partner and the CPA firm

Your organization owns the control matrix. Management decides which controls exist, who runs them, how often they operate and what the risk assessment says about them. The control set has to describe how your company really works, because the auditor will test it against your actual people, tools and records. Your team also writes the policies that the controls depend on and signs off that the matrix is accurate before any outside party reviews it.

Controls and owners: Name a accountable owner for every row, including the person who performs the control and the person who reviews the output.
Risk assessment: Document the risks each control addresses, the scoring method and the decisions made about residual risk.
Policies: Approve the policies that the matrix cites, and confirm they match practice.
Criteria in scope: Agree with the CPA firm which trust services categories apply to your system.
Accuracy sign-off: Management confirms in writing that the matrix describes the controls in operation.

Before fieldwork starts, check that every row names an owner who can produce the evidence without help from the implementation partner.

Why copied template controls draw auditor and peer reviewer scrutiny

A control matrix copied from a template or another client tends to fail in the same few places. Each card below names one failure mode, why it matters for the matrix behind a SOC 2, and what to check before the auditor does. The May 2026 AICPA peer review alert makes these patterns a practical concern, not just a style issue.

Controls for tools the company does not run

A matrix that describes a SIEM, a vulnerability scanner or a ticketing workflow the company never deployed fails at the first inquiry. Auditors test what operates in the system, so a control naming an unused tool produces either an exception or a control that was never in place. Before fieldwork, walk each control with the engineer who runs it and confirm the named system, its configuration and the place where its output lives.

Identical risk assessments across clients

A risk assessment that reads the same as one written for another company suggests the risks were never assessed for this system. The May 2026 AICPA peer review alert treats identical SOC 2 risk assessments as a risk indicator. Build the risk register from this company's architecture, data flows, vendors and past incidents, and record who approved each rating and when.

Controls with no owner or population

A control without a named owner has no one to answer for its performance, and a control without a defined population has nothing an auditor can sample. For example, an access review control with no list of in-scope systems or accounts cannot be tested in a meaningful way. For each control, record the owner, the frequency, the system of record and the population the sample will be drawn from.

Criteria marked covered with no control

A mapping that marks a criterion as addressed but links it to no control, or to a control that does not test that criterion, leaves a gap the auditor will find during walkthroughs. Common examples include change management criteria mapped only to a policy document. Review each criterion against its linked controls and confirm that every applicable criterion has at least one control whose design answers it.

Points of focus pasted without reasoning

The 2017 Trust Services Criteria present points of focus as characteristics that can help design and evaluate controls, not as separate requirements. Pasting every point of focus into a matrix without deciding which apply produces controls that do not match the system. Document, for each criterion, which points of focus the company considered, which it addressed and why any were set aside.

Matrix out of step with the system description

The control matrix and the system description must describe the same system, boundary, services and subservice organizations. When a matrix lists controls for components the description omits, or the description names a service with no control, the auditor will question both documents. Reconcile the two side by side before the auditor's evidence request list arrives, and update both when the architecture changes.

Questions teams ask about building a SOC 2 control matrix

Does the AICPA require a SOC 2 control matrix?

The AICPA does not publish a form called a control matrix as a requirement, but a SOC 2 examination needs a documented set of controls that the service organization can describe, run and show to the auditor. In practice the matrix is the working document that holds that set. The auditor's process effectively requires it, because the auditor must test each control against the criteria it addresses and needs a clear list to draw samples and request evidence. The matrix also feeds the system description and management's assertion, so the format matters less than whether every control is traceable to a criterion and an owner. Confirm the expected format and level of detail with your CPA firm before building it.

Can one control satisfy more than one SOC 2 criterion?

Yes. A single control often addresses several criteria because the criteria overlap. For example, a quarterly access review may support logical access criteria in CC6, risk-related monitoring in CC4, and the segregation of duties points of focus under CC5.1. The matrix should show each mapping explicitly so the auditor can see which criteria a control covers and whether its design and operation are tested for each one. Be careful about stretching a control to cover a criterion it does not really address. Auditors look for a clear, specific link, and a vague mapping invites follow-up questions and additional testing. Points of focus are guidance, so you do not need to address every one of them for every control.

How many controls should a SOC 2 control matrix contain?

There is no fixed number. The count depends on the systems and categories in scope, the size and structure of the organization, how many products and environments the examination covers, and how the organization chooses to design its controls. A narrow system with a single product will need far fewer controls than a multi-product platform with several environments and categories beyond security. Avoid copying a number from a peer or a template, since the count should follow from your own risk assessment and system boundaries. Ask your CPA firm to confirm what level of granularity they expect and how they will sample each control across the examination period.

Can ISO 27001 or NIST mappings be reused for a SOC 2 matrix?

They can serve as a starting point, but each mapping must be checked against your own systems and against the 2017 Trust Services Criteria. The AICPA publishes a mapping of ISO 27001 to the criteria, and NIST hosts a crosswalk to the criteria that its contributor describes as a starting point without a guarantee of accuracy. Check that each reused control still operates the way the mapping says, that the evidence is produced for your in-scope systems, and that the criteria covered match the categories you chose. Frameworks differ in scope and wording, so a control that satisfies an ISO clause may not address the SOC 2 point you need. Treat any mapping as a draft that your own testing and your auditor's review must confirm.

Who inside the organization should own the control matrix?

Ownership usually sits with a senior person who can coordinate control owners across engineering, IT, HR, legal and operations, often the security or compliance lead, with executive sponsorship from the CISO, CIO or CTO. The matrix owner maintains the document, keeps mappings current, and checks that every control has a named operator and evidence source. Each control also needs its own owner who runs it and can show the evidence. Separating these roles avoids a situation where one person writes controls that nobody operates. Review the matrix at least when systems, vendors or criteria in scope change, and make sure the owner can explain each control to the auditor during fieldwork.

Can a partner build the control matrix while we keep ownership of the controls?

Yes, provided the division of responsibilities is written down before work starts. An implementation partner can prepare systems, draft the matrix, document the mappings, configure tooling that produces evidence, and train control owners. DeployOpen, for example, plans, implements and documents self-hosted platforms in your own infrastructure and prepares controls and evidence for assessment. The organization still owns its controls, decides which ones it will run, and signs its own management assertion. Only an independent CPA firm issues the SOC 2 report. A fixed-scope engagement should state deliverables, the systems covered, handover to internal owners, and what the partner will not do, such as making decisions that belong to management or the auditor.

How DeployOpen prepares the control matrix and evidence for your audit

DeployOpen helps your team build one control set mapped to the SOC 2 criteria that apply to your system, then prepares the systems and evidence that show those controls running. Your organization owns the controls and the assertion, and an independent CPA firm performs the examination and issues the report.

How we scope

Agree the in-scope system, boundaries and Trust Services categories in a written scope before work starts.
Confirm which common criteria CC1 to CC9 apply and which optional categories are added to the examination.
Identify the infrastructure, tools and subservice providers whose controls feed the control matrix.

How we build

Draft a single control set and map each control to the applicable criteria, using points of focus as design guidance.
Test any reused ISO 27001 or NIST mapping against your own environment rather than accepting it as written.
Document owner, frequency, system source and evidence type for each control so the matrix can be tested.

How we hand over

Deliver the control matrix, system configurations and evidence sources in a form your CPA firm can review.
Provide a population and sample-ready record for each control, such as system-generated access and change reports.
Hand over documentation so your team can explain each control in its own words during fieldwork.

How we support

Offer ongoing support and continuous testing as a retainer after the first examination period.
Update the control matrix when systems, vendors or criteria in scope change, with changes recorded for the auditor.
Confirm with your CPA firm which evidence formats and sample periods it expects before the Type 2 period begins.

Building a SOC 2 control matrix mapped to the criteria