SOC 2 Controls List and Matrix (2026): Free Excel and PDF

On this page

Download the SOC 2 Controls Matrix (Excel, PDF, CSV)
SOC 2 Control Examples Mapped to Evidence
Security Controls (CC1–CC9) Mapped to Evidence
Availability Controls (A1.1–A1.3) Mapped to Evidence
Processing Integrity Controls (PI1.1–PI1.5) Mapped to Evidence
Confidentiality Controls (C1.1–C1.2) Mapped to Evidence
Privacy Controls (P1–P8 series) Mapped to Evidence
What Are SOC 2 Controls?
What Are the Five SOC 2 Trust Services Criteria?
Gap Checks Before You Mark a Control Ready
How Do You Implement and Document SOC 2 Controls?
How Do You Prepare for a SOC 2 Audit?
Answering Your Top SOC 2 Control Questions

There is no official SOC 2 controls list. The AICPA’s 2017 Trust Services Criteria set 61 criteria, not controls: 33 Common Criteria, which make up Security and apply to every report, plus 28 across Availability, Processing Integrity, Confidentiality, and Privacy, which you add by scope. Your organization designs the controls that meet them. Our free library maps 82 example controls to all 61 criteria, each with the evidence an auditor may request and a common gap. Filter it to your scope below.

Download the matrix: Excel, PDF or CSV, free with no signup.

Download the SOC 2 Controls Matrix (Excel, PDF, CSV)

A SOC 2 controls matrix is a spreadsheet that lines each control up with the criteria it addresses, the evidence that shows it works, and an owner. SOC 2 has no official matrix, so this one starts as example controls that you tailor to your systems, assign, and attach evidence to.

	What it holds	Who fills it in
`library_control_id`	The example control’s ID in our library, such as AC-06, shown on its row in the tables below.	Filled in by us
`category`, `criterion_reference`	The Trust Services category and the criteria the example control maps to, such as CC6.2.	Filled in by us
`example_control`	The control written as an action you can adopt or rewrite.	Filled in by us
`evidence_example`, `evidence_source`	What an auditor may request, and the system each item comes from, such as the identity provider, ticketing tool, or cloud console.	Filled in by us
`type_2_period_evidence`	What must exist across the audit period for a Type 2 report.	Filled in by us
`cadence`, `common_gap`	A suggested cadence to replace with your own, and a gap that is common for that control.	Filled in by us
`system_scope`, `tailored_control_statement`, `applicability`	Your boundary, your own wording of the control, and whether it applies and why.	Blank for you
`organization_control_id`, `owner`, `policy_or_risk_reference`, `status`, `notes`	Your identifier, the person responsible, the policy or risk it traces to, and progress.	Blank for you
`evidence_reference`, `gap_decision`, `remediation_action`	Links to your dated artifacts, whether a gap is open, and the fix, owner, and due date.	Blank for you

The Excel template and the CSV have the same columns. The Excel file adds a status dropdown, a frozen header row, an Instructions sheet, and a criteria-coverage sheet that lists the example controls mapped to each of the 61 criteria. The PDF is a printable copy grouped by category.

This editable starter matrix is SOC2Auditors’ implementation guidance, not an official AICPA control list. It contains criterion identifiers, our own short labels, and our examples, not AICPA criterion or points-of-focus wording. An example mapped to a criterion does not show that your organization meets it. Use the official AICPA Trust Services Criteria resource, and confirm applicability, evidence, and testing with your CPA firm, which sets the actual requests and samples.

Download the Excel template

Also available as an editable CSV and a PDF. All three hold the same 82 controls.

SOC 2 controls at a glance
Category	Criteria	Add it when	Example controls	Jump to
Security	CC1.1 to CC9.2 (33 criteria)	Almost always. Its Common Criteria apply to every SOC 2 report.	60	Security controls
Availability	A1.1 to A1.3 (3 criteria)	You commit to uptime or recovery.	4	Availability controls
Processing Integrity	PI1.1 to PI1.5 (5 criteria)	Customers rely on your processing being complete and accurate.	6	Processing Integrity controls
Confidentiality	C1.1 to C1.2 (2 criteria)	You hold data designated as confidential.	2	Confidentiality controls
Privacy	P1.1 to P8.1 (18 criteria)	You collect personal information directly from individuals.	10	Privacy controls

Jump to a Common Criteria series: CC1 (1.1 to 1.5), CC2 (2.1 to 2.3), CC3 (3.1 to 3.4), CC4 (4.1 to 4.2), CC5 (5.1 to 5.3), CC6 (6.1 to 6.8), CC7 (7.1 to 7.5), CC8 (8.1), CC9 (9.1 to 9.2).

SOC 2 Control Examples Mapped to Evidence

Each row pairs an example control with the criteria it maps to, the evidence an auditor may request, what must exist across a Type 2 audit period, a suggested cadence, and a common gap. The Security rows answer the Common Criteria, which apply to every SOC 2 report; the Availability, Processing Integrity, Confidentiality, and Privacy rows apply when the report includes those categories. The SOC 2 requirements overview sets out which parts are mandatory and which are optional. For detailed access and operations design, use the CC6/CC7 security controls guide. For the order of work from scoping to report, see the SOC 2 compliance checklist.

All rows show until you change a filter. Untick the categories outside your report, and turn on the switches that describe you (solo founder, PaaS only, no office, no device management, no hosted AI models) to hide controls that would not apply; rows that a switch can hide say why in their Control column. Two options hide nothing: the HIPAA add-on marks controls that overlap the HIPAA Security Rule, and your stack choices name the system each piece of evidence comes from. The filtered list downloads as a CSV.

See the same evidence grouped by the system you pull it from

Security Controls (CC1–CC9) Mapped to Evidence

Security has 33 Common Criteria, CC1.1 through CC9.2, and each one has at least one example control below. Some controls answer several criteria and some criteria take several controls, so the number of rows is not the number of criteria. The cadences shown are common choices; set yours, including the risk assessment schedule and access-removal deadlines, from your documented risks and policies, not a fixed SOC 2 schedule.

The Type 2 line in each row is what must exist across the audit period; see SOC 2 Type 2 controls.
Criteria	Control	Evidence auditors request	Common gap
CC1.1 Integrity and ethical values C1.1 Identifying and protecting confidential information	GV-01 Publish a code of conduct and a confidentiality agreement. Every employee and contractor signs both before receiving system access and re-acknowledges the code of conduct each year. Cadence Annual	Signed code of conduct and confidentiality agreement for each hire, dated on or before the day access was granted Source: HR system Annual acknowledgment report listing every active employee and contractor with the date each signed Source: HR system Current code of conduct with its approval date and the consequences for violations Source: Policy repository Type 2: what must exist across the audit period A signed agreement for every person hired during the period and a completed annual acknowledgment cycle, so the auditor can sample both new hires and existing staff.	New hires sign days or weeks after they were given system access, or contractors are left out of the acknowledgment.
CC1.2 Board oversight	GV-02 Brief your board on security risks, incidents and control status at least annually, and record questions and agreed actions in minutes. With no board, name an outside advisor or investor to do this; founders reviewing their own work are not independent. Cadence Annual	Board or advisory charter, or a written note of who provides oversight and how independent they are from management Source: Board and management records Dated minutes or briefing deck showing security and risk discussed, with the questions raised and follow-up actions Source: Board and management records Type 2: what must exist across the audit period Minutes for each oversight meeting due in the period, showing security on the agenda as often as the charter or policy says.	Security never reaches the board agenda, or the minutes record a presentation with no questions, decisions or follow-up.
CC1.3 Structure, reporting lines and authority	GV-03 Maintain an org chart and written role descriptions that name who owns security, who they report to, and who may approve access, changes and risk exceptions. Cadence Annual	Current org chart with reporting lines, dated or under version control Source: HR system Responsibility matrix naming the security owner and the approvers for access, changes and risk acceptance Source: Policy repository Type 2: what must exist across the audit period Org chart versions or HR records showing reporting lines kept current as people joined, left or changed roles during the period.	Nobody is formally named as security owner, so approvals in tickets come from people with no assigned authority to give them.
CC5.3 Policies and procedures	PL-01 Keep written security policies covering topics such as access, change, incident response, vendors, data handling and acceptable use, with procedures that put each into practice. Management approves them and reviews them at least annually. Cadence Annual	Policy set with version history, owner, approval date and next review date for each policy Source: Policy repository Record of management approval for the latest review, such as a signed approval page or approval ticket Source: Board and management records Procedures and runbooks that carry out each policy, such as the offboarding checklist and incident runbook Source: Policy repository Type 2: what must exist across the audit period Each policy reviewed and approved on its stated cadence during the period, and procedures in use that match the approved versions.	Policies are templates describing tools, cadences or roles the company does not use, so testing finds the written control and actual practice disagree.
CC2.2 Internal communication of responsibilities	PL-02 Publish policies where every employee and contractor can find them, have each person acknowledge them at hire and annually, and tell staff how to report a security concern or policy violation. Cadence Annual	Acknowledgment report showing each person, the policy version acknowledged and the date Source: Training platform Internal handbook page listing current policies and the channel for reporting security concerns Source: Policy repository Notice sent to staff when a policy changed materially, with the date sent Source: Policy repository Type 2: what must exist across the audit period Acknowledgments for everyone hired in the period and for the annual cycle, plus a staff notice for each material policy change made during the period.	A policy changed mid-period but staff only ever acknowledged the old version, or contractors with system access acknowledged nothing.
CC2.3 Communication with outside parties	PL-03 Tell customers what you commit to and what they must do themselves: state security commitments in contracts or a trust page, publish a security contact, and notify customers of changes that affect them. Cadence Per event	Customer agreement or terms showing your security, availability and confidentiality commitments Source: Customer and vendor contracts Published security contact and vulnerability reporting route, such as a security page or security.txt file Source: Customer communications Customer documentation of the controls customers run themselves, such as managing their own users and SSO Source: Customer communications Dated notices to customers about material changes, such as new subprocessors or changed commitments Source: Customer communications Type 2: what must exist across the audit period Dated customer notices for changes made in the period, and a record that reports to the security contact were received and answered.	Customer responsibilities assumed in the system description are never communicated to customers, or the security contact goes to an unmonitored inbox.
CC1.4 Hiring and keeping competent people	HR-01 Run background checks, where local law allows, on employees and contractors who will have access to production or customer data, and complete each check before that access is granted. Cadence Per event Does not apply for Solo founder. A one-person company has no hires to screen. Add this row back before your first employee or contractor gets system access.	Background check completion records with the completion date for each in-scope hire Source: HR system Hiring procedure stating which roles are screened and what the check covers in each country Source: Policy repository Type 2: what must exist across the audit period A check completed before the access grant for every in-scope hire in the period, so the auditor can compare check dates with provisioning dates.	Checks finish after the person already has production access, or contractors and staff hired through agencies bypass the process.
CC1.4 Hiring and keeping competent people CC2.2 Internal communication of responsibilities	HR-02 Train every employee and contractor on security at hire and annually, and give engineers and support staff extra training on secure coding and handling customer data. Cadence Annual	Training completion report listing each person, the course and the completion date Source: Training platform Course content covering phishing, data handling, incident reporting and acceptable use Source: Training platform Role-specific completion records, such as secure coding training for engineers Source: Training platform Type 2: what must exist across the audit period Completion records for each new hire within the deadline your policy sets and for the annual cycle, covering everyone active during the period.	New hires finish training weeks after starting, or the completion report leaves out contractors and people who left during the period.
CC1.5 Accountability for controls	HR-03 Review each employee's performance at least annually, including how they carry out assigned security responsibilities, and apply a documented disciplinary process when someone breaks a policy. Cadence Annual Does not apply for Solo founder. A one-person company has nobody else to evaluate or discipline. Show accountability through the named owner of each control in your control matrix.	Dated performance review records showing reviews were completed for current employees Source: HR system Disciplinary procedure referenced by the security policies Source: Policy repository Record of each policy violation in the period and the action taken Source: HR system Type 2: what must exist across the audit period Completed reviews for employees active through the review cycle, and a record for each policy violation found during the period.	Performance reviews at an early-stage company are informal conversations, so there is no dated record for the auditor to inspect.
CC3.1 Objectives clear enough to assess risk CC3.2 Risk identification and analysis	RA-01 Each year, write down your service commitments and security objectives, identify threats to them (including vendor risks), rate each risk's likelihood and impact, and record a treatment decision and owner for every risk. Cadence Annual	Statement of the service commitments and system requirements the assessment started from Source: Board and management records Dated risk register listing each risk, its rating, treatment decision, owner and linked controls Source: Risk register Management sign-off on the completed assessment and on any risks accepted rather than treated Source: Board and management records Type 2: what must exist across the audit period An assessment completed within the period on the cadence your policy states, with treatment actions tracked to completion or formally accepted.	The register is a template that never changes from year to year, or its risks are not linked to the controls meant to treat them.
CC3.3 Fraud risk	RA-02 Include fraud in the risk assessment: consider how staff, contractors or outsiders could misuse access, alter records or billing, or override controls, and name the controls that address each scenario. Cadence Annual	Fraud scenarios in the risk register with ratings and the controls that mitigate each Source: Risk register Assessment notes showing who considered insider misuse, management override and payment or billing fraud Source: Risk register Type 2: what must exist across the audit period The fraud portion of the assessment completed within the period, with any resulting actions tracked.	The risk assessment covers outside attackers only and never considers insider misuse or management overriding a control.
CC3.4 Significant changes	RA-03 Before a significant change, such as a new product line, a major architecture change, an acquisition or a new critical vendor, assess its effect on security risk and update the risk register and controls. Cadence Per event	Risk review ticket or note for each significant change, with the date and the decision Source: Ticketing system Risk register entries added or updated as a result of each review Source: Risk register Type 2: what must exist across the audit period A risk review for each significant change made during the period, dated before or at the change, so the auditor can match changes to reviews.	Major changes such as a new cloud region or an AI feature ship with no record that their risks were considered until the next annual assessment.
CC5.1 Controls that reduce risk CC5.2 General technology controls CC1.5 Accountability for controls	RA-04 Maintain a control matrix that links each risk to the controls that treat it, including technology controls over infrastructure, access and software development, and names an owner and cadence for every control. Cadence Annual	Control matrix listing each control with its owner, cadence, the risks it addresses and the criteria it maps to Source: Risk register Record of the annual matrix review showing controls added, changed or retired Source: Board and management records Type 2: what must exist across the audit period The matrix in force during the period, and evidence that each named owner performed their control at the stated cadence.	A control has no owner, or the named owner left the company, so nobody performed it for part of the period.
CC4.1 Ongoing and separate evaluations	CE-01 Monitor whether each control ran on its cadence, using automated tests where available and a dated checklist where not, and have a named owner review the results at least monthly. Cadence Monthly	Control monitoring log or dashboard export showing each control's test results and dates Source: Compliance platform Tickets opened for failed control tests, with owner and resolution date Source: Ticketing system Type 2: what must exist across the audit period Dated monitoring results across the whole period with no unexplained gaps, and follow-up recorded for each failure.	A compliance platform shows tests failing for weeks with no ticket or owner response, so the monitoring control looks as if it did not operate.
CC4.1 Ongoing and separate evaluations	CE-02 Once a year, have someone independent of the control owners, such as an internal auditor or outside consultant, evaluate whether key controls are designed and operating as described. The SOC 2 audit itself does not count. Cadence Annual	Dated evaluation report naming the evaluator, the controls covered, the method used and the findings Source: Board and management records Management response to each finding with owner and due date Source: Ticketing system Type 2: what must exist across the audit period An evaluation performed within the period by someone who does not run the controls, with its findings entered in deficiency tracking.	The only evaluation is a self-assessment by the people who run the controls, or its scope skips the controls most likely to fail.
CC4.2 Reporting and fixing deficiencies	CE-03 Log every control failure, audit finding and test exception as a deficiency with an owner, severity and due date, report open items to management, and track each one to closure. Cadence Quarterly	Deficiency log or tickets with severity, owner, due date and closure evidence Source: Ticketing system Management or board report showing open deficiencies and their status Source: Board and management records Type 2: what must exist across the audit period Each deficiency raised during the period traced to remediation or a documented acceptance, with reports to management on the stated cadence.	Deficiencies get fixed with no record, or sit open past their due dates with no escalation to management.
CC6.1 Logical access security	AC-01 Require multi-factor authentication for every workforce account on in-scope systems, through single sign-on where the system supports it, and turn off sign-in methods that bypass it, such as local passwords. Give each person a unique user ID, with no shared accounts. Cadence Continuous	Identity provider policy export showing MFA required, not optional, for all users Source: Identity provider List of in-scope applications connected to SSO, with any exceptions and their compensating controls Source: Identity provider Settings for accounts outside SSO, such as the cloud root account, showing MFA enforced Source: Cloud console User list showing one named account per person and no shared logins Source: Identity provider Type 2: what must exist across the audit period Configuration evidence that enforcement stayed on through the period, and a record of each exception approved and when it ended.	MFA is offered but not enforced, or root, break-glass (emergency admin) and non-SSO accounts still sign in with a password alone.
CC6.1 Logical access security	AC-02 Store secrets, API keys and service-account credentials in a secrets manager, give each service account a named owner, and rotate or revoke credentials when an owner leaves or a key is exposed. Cadence Per event	Secrets manager configuration and access policy showing who can read production secrets Source: Cloud console Service account inventory with owner, purpose and last rotation date Source: Cloud console Secret-scanning results for code repositories, with each detected secret revoked Source: Source control and CI/CD Type 2: what must exist across the audit period Rotation or revocation records for credentials owned by people who left, or for keys exposed, during the period.	Long-lived service account keys have no owner and were never rotated, or secrets sit in source code and committed configuration files.
CC6.2 User registration and removal	AC-03 Grant access to in-scope systems only after a recorded approval from the person's manager or the system owner, at the level the role needs. Apply this to employees, contractors and vendor users alike. Cadence Per event	Access request tickets showing requester, approver, systems, access level and approval time Source: Ticketing system Account creation timestamps to compare against each approval time Source: Identity provider Role-to-access mapping used to set default access for each job Source: Policy repository Type 2: what must exist across the audit period An approval dated before provisioning for each account created in the period, drawn from a complete list of new accounts.	Accounts are created before approval is recorded, or access is granted over chat and the ticket is written afterward.
CC6.2 User registration and removal	AC-04 Remove all access for departing employees and contractors by the deadline in your access policy, triggered by the HR termination record, and recover company devices. Cadence Per event	Termination list showing each person's last day Source: HR system Account deactivation timestamps for the same people Source: Identity provider Offboarding tickets showing access removed from systems outside SSO and devices returned Source: Ticketing system Type 2: what must exist across the audit period For every person who left during the period, a deactivation time within the policy deadline of their termination date.	Accounts outside SSO, such as the cloud console, the database or a shared admin tool, stay active after the identity provider account is disabled.
CC6.3 Role-based access and least privilege CC5.2 General technology controls	AC-05 Define roles with the minimum permissions each job needs, assign access through those roles or groups rather than one-off grants, and require approval for anything beyond the role. Cadence Per event	Role matrix listing each role and the permissions it grants in each system Source: Policy repository Export of current user-to-role and group assignments Source: Identity provider Approval tickets for permissions granted outside a standard role Source: Ticketing system Type 2: what must exist across the audit period Approval records for role changes and extra permissions granted in the period, and assignments that still match the role matrix.	Most users hold an admin or owner role because it was easier, so the documented role matrix does not match real permissions.
CC6.2 User registration and removal CC6.3 Role-based access and least privilege	AC-06 Each quarter, have system owners review every account and its permissions on production and other in-scope systems, record a keep or remove decision for each, and remove unneeded access by a set deadline. Cadence Quarterly	Dated export of the accounts and permissions used for each review Source: Identity provider Quarterly access review sign-off listing the reviewer, the accounts reviewed, the decisions and the changes made Source: Ticketing system Removal records showing access marked for removal was actually removed Source: Ticketing system Type 2: what must exist across the audit period A completed review for every quarter in the period, each with the population reviewed, the decisions made and proof that removals happened.	Reviewers approve the whole list without checking actual permissions, or removals decided in the review are never carried out.
CC6.1 Logical access security CC6.3 Role-based access and least privilege	AC-07 Limit admin and production data access to named people with a recorded need, use separate or time-limited elevated sessions for admin work, keep a monitored break-glass (emergency admin) account, and log privileged actions. Cadence Quarterly	List of admin and production-access accounts with the justification for each Source: Cloud console Access settings showing elevated rights are time-limited or need a separate role Source: Cloud console Break-glass procedure stating who holds the credentials and when the account may be used Source: Policy repository Admin activity log tying privileged actions to named people, including each break-glass use and its review Source: Logging and monitoring (SIEM) Type 2: what must exist across the audit period Privileged access lists reviewed through the period, and a log entry and review for each break-glass use.	Shared admin credentials or the cloud root account are used for routine work, so actions cannot be tied to a person.
CC6.1 Logical access security	AC-08 Protect customer logins to your product: enforce password rules, offer MFA or SSO, throttle repeated failed attempts, expire idle sessions, and check tenant boundaries on every data request. Cadence Continuous	Application authentication settings or code showing password rules, lockout and session timeouts Source: Application and data stores Automated tests or code review records covering tenant isolation on data queries Source: Source control and CI/CD Penetration test results covering authentication and cross-tenant access Source: Penetration test or external assessment Type 2: what must exist across the audit period Code or configuration history showing the settings stayed in place through the period, and test results that cover the release in use.	Tenant isolation is enforced only in the user interface, so a signed-in user can fetch another customer's records through the API.
CC6.1 Logical access security CC6.6 Protection against outside threats	AC-09 Each quarter, review the third-party apps and OAuth grants connected to your workspace, code host and chat tools, remove any that are unused or unapproved, and limit who can authorize new ones. Cadence Quarterly	Export of connected apps and OAuth grants with their scopes and the user who authorized each Source: Identity provider List of apps and integrations installed in the code host, with their permissions Source: Source control and CI/CD Admin setting restricting which users may approve new third-party apps Source: Identity provider Review record listing the apps removed and the date Source: Ticketing system Type 2: what must exist across the audit period A completed review for each quarter in the period, with the removals it decided carried out.	Old integrations keep broad access to email, files or repositories long after the person who connected them has left.
CC6.4 Physical access	PE-01 Restrict entry to offices and to any room holding network or storage equipment to authorized people, log visitors, and remove badge or key access when people leave. Cadence Per event Does not apply for No office. You run no office or facility that holds in-scope systems. Your providers run the data centers; review their SOC 2 reports for physical security instead.	Badge system user list compared with current staff, or a key issuance log Source: Physical security records Visitor log for the period Source: Physical security records Badge or key removal records for departed staff Source: Physical security records Type 2: what must exist across the audit period Visitor entries and badge removals across the period, with each departure matched to a badge deactivation.	Badges stay active after people leave, or a shared office has no record of who can enter.
CC6.4 Physical access A1.2 Environmental protection, backup and recovery	PE-02 As part of the vendor review, read your cloud and hosting providers' SOC 2 reports each year for their physical and environmental protection results, note any exceptions, and confirm you perform the controls they expect of customers. Cadence Annual	Current SOC 2 report for each hosting provider, with the period it covers Source: Vendor inventory Review note recording physical and environmental protection results, exceptions and the customer controls you rely on Source: Vendor inventory Type 2: what must exist across the audit period A review done during the period of a report whose coverage overlaps your period, with a bridge letter (the provider's statement covering the months since its report ended) on file for any gap.	The provider's report is downloaded but never read, so its exceptions and the customer controls it expects go unaddressed.
CC2.1 Quality information for controls CC6.1 Logical access security	AM-01 Maintain an inventory of in-scope systems, cloud accounts, SaaS tools, data stores and company devices with an owner for each, plus a current network and data-flow diagram. Cadence Quarterly	System and data store inventory with owner, environment and data classification Source: Asset inventory Cloud resource export used to confirm the inventory is complete Source: Cloud console Network and data-flow diagrams with a revision date Source: Policy repository Device inventory with assigned user and serial number Source: Asset inventory Type 2: what must exist across the audit period Inventory updates for systems and devices added or retired during the period, and diagrams that match the environment as it ran.	Resources created during the period, such as a new database or cloud account, never reach the inventory and so miss logging, backups and reviews.
CC6.5 Asset disposal C1.2 Disposing of confidential information	AM-02 Before a device or storage medium is reused, returned or thrown away, wipe or destroy it by a method suited to the data it held, and record the asset, method, date and who did it. Cadence Per event	Disposal log linked to the asset inventory, with method, date and the person who performed it Source: Asset inventory Remote wipe confirmation for each managed device Source: Endpoint management (MDM) Destruction certificate from the disposal vendor listing serial numbers Source: Asset inventory Type 2: what must exist across the audit period A disposal record for every device retired during the period, traceable to its inventory entry.	Laptops from departed staff are reissued or sold without a recorded wipe, or the destruction certificate lists no serial numbers.
CC6.6 Protection against outside threats	NS-01 Expose to the internet only the endpoints the service needs, keep admin interfaces and databases off public networks, segment internal networks so production is separate, use provider protections such as a web firewall or rate limits, and review exposure rules each quarter. Cadence Quarterly	Firewall, security group or platform network settings showing the inbound traffic allowed Source: Cloud console Network layout showing production separated from other environments and internal services Source: Cloud console Inventory of public endpoints and domains with an owner for each Source: Asset inventory Dated quarterly review of inbound rules with the changes made Source: Ticketing system Type 2: what must exist across the audit period Rule reviews on the stated cadence, and change records for exposure rules altered during the period.	Broad inbound rules, such as an open database port, were added for testing and never removed, or production shares a flat network with everything else.
CC6.6 Protection against outside threats CC6.1 Logical access security	NS-02 Reach production servers and networks only through an authenticated, logged path such as a bastion host (a hardened jump server), VPN, zero-trust proxy or the cloud provider's session manager, never through SSH or RDP exposed to the internet. Cadence Continuous Does not apply for PaaS only (no servers or networks you manage). You run no servers or networks of your own. Admin access goes through your platform's console, covered by the MFA and privileged access rows.	Remote-access path configuration showing SSO and MFA required Source: Cloud console Session logs for production connections made through that path Source: Logging and monitoring (SIEM) Network rules showing SSH and RDP closed to the internet Source: Cloud console Type 2: what must exist across the audit period Session logs across the period showing production access went through the approved path.	SSH is open to the internet with shared keys, so production access is neither tied to a person nor logged.
CC6.7 Data transmission and removal	NS-03 Encrypt data in transit on every external connection with TLS 1.2 or later, turn off older protocols, and let customer data leave production only through approved transfer methods that leave a record. Cadence Continuous	TLS scan results for public endpoints showing the protocol versions accepted Source: Vulnerability scanner Data handling rule naming approved transfer methods and barring personal email or storage for customer data Source: Policy repository Log or tickets for bulk exports of customer data Source: Application and data stores Type 2: what must exist across the audit period Scan results across the period showing TLS settings held, and a record for each bulk export of customer data.	A legacy endpoint still accepts TLS 1.0, or engineers export customer data to laptops and spreadsheets with no record.
CC6.1 Logical access security CC6.8 Malicious software	EP-01 Enroll every company laptop in device management and enforce disk encryption, screen lock, automatic OS updates and remote wipe, with alerts when a device falls out of compliance. Cadence Continuous Does not apply for No device management (MDM). You do not use a device management tool. Check the device baseline on each laptop through posture checks or signed attestations instead.	Enrollment report compared with the device inventory Source: Endpoint management (MDM) Compliance report showing encryption, screen lock and OS version for each device Source: Endpoint management (MDM) Tickets for non-compliant devices with the fix and the date Source: Ticketing system Type 2: what must exist across the audit period Compliance reports from across the period, not only its end, and a resolution record for each device that fell out of compliance.	Contractors' laptops are never enrolled, or non-compliant devices stay that way for months because nobody acts on the alerts.
CC6.8 Malicious software	EP-02 Run malware protection on laptops and on servers where the platform allows it, restrict or monitor software installation on company devices, and investigate and close every malware alert. Cadence Continuous	Endpoint protection coverage report listing devices, agent status and last check-in Source: Endpoint management (MDM) Malware alert log with the investigation and outcome for each alert Source: Logging and monitoring (SIEM) Device settings or reports that restrict or monitor software installation and local admin rights Source: Endpoint management (MDM) Type 2: what must exist across the audit period Coverage reports across the period and a closed record for every malware alert raised.	Some devices never installed the agent or stopped reporting, unnoticed because coverage was never compared with the inventory.
CC6.1 Logical access security CC6.8 Malicious software	EP-03 Set a minimum baseline for any device that reaches company systems, including personal ones: disk encryption, screen lock, a supported OS and malware protection. Check it with device posture rules or signed attestations. Cadence Quarterly	Device security standard stating the baseline and which devices it covers Source: Policy repository Device posture rules in the identity provider blocking devices that miss the baseline Source: Identity provider Dated signed attestation from each person using a personal device Source: Compliance platform Type 2: what must exist across the audit period Posture checks or attestations covering everyone who used an unmanaged device during the period, on the cadence your standard sets.	Personal devices are allowed but the policy says nothing about them, so the auditor finds devices with no proof of encryption or updates.
CC7.1 Configuration and vulnerability detection	VM-01 Set secure configuration baselines for cloud accounts and hosts or containers, or for your managed platform's security settings. Scan for vulnerabilities, misconfigurations and outdated dependencies on a set schedule and after major changes, across every in-scope environment. Cadence Monthly	Configuration baseline or hardening standard, including the security settings of any managed platform Source: Policy repository Dated scan reports from across the period with the assets each scan covered Source: Vulnerability scanner Configuration findings measured against the baseline Source: Cloud console Dependency scanning results from the CI pipeline Source: Source control and CI/CD Type 2: what must exist across the audit period A dated scan for every scheduled interval in the period, with coverage that matches the system inventory.	Scans cover only part of the environment, such as one cloud account, or the schedule lapsed for a month with no record of why.
CC7.1 Configuration and vulnerability detection	VM-02 Fix vulnerabilities and apply security patches within deadlines set by severity in your policy, track each finding in a ticket, and record a signed risk acceptance for anything that cannot meet its deadline. Cadence Per event	Remediation tickets for critical and high findings with open date, owner and close date Source: Ticketing system Follow-up scan showing each fixed finding cleared Source: Vulnerability scanner Signed risk acceptances for findings left open past their deadline Source: Risk register Type 2: what must exist across the audit period For findings raised in the period, close dates within the policy deadline or an approved acceptance, which the auditor can sample against scan output.	The same critical finding appears in several months of scans with no ticket and no recorded risk acceptance.
CC4.1 Ongoing and separate evaluations CC7.1 Configuration and vulnerability detection	VM-03 Commission an independent penetration test of the in-scope application and infrastructure at least annually and after major changes, then fix the findings and retest the serious ones. Cadence Annual	Penetration test report with scope, dates, tester, method and findings Source: Penetration test or external assessment Remediation tickets for each finding, closed or formally accepted Source: Ticketing system Retest report or letter confirming high-severity fixes Source: Penetration test or external assessment Type 2: what must exist across the audit period A test dated within the period, or recent enough for your auditor to accept it, scoped to the system as it ran, with findings tracked to closure.	The test scope leaves out the production application or its API, or findings are filed with no remediation record or retest.
CC7.2 Monitoring for anomalies CC2.1 Quality information for controls	LG-01 Send security-relevant logs from the cloud, identity provider, application and other in-scope systems to a central store, protect them from change, and keep them long enough that the start of the audit period is still available when the auditor tests it. Cadence Continuous	Logging configuration showing audit logs enabled in every cloud account and region in use Source: Cloud console List of log sources feeding the central store, compared with the system inventory Source: Logging and monitoring (SIEM) Retention and access settings for the log store Source: Logging and monitoring (SIEM) Type 2: what must exist across the audit period Logs available for the full period, so the auditor can pull events from its first months as well as its last.	A cloud account or service added during the period was never connected to logging, or retention deletes the period's first months before fieldwork.
CC7.2 Monitoring for anomalies CC7.3 Evaluating security events	LG-02 Alert on suspicious activity such as repeated failed logins, privilege changes and unusual data access, route alerts to an on-call owner, and record a triage decision for each against written severity criteria. Cadence Continuous	Alert rule configuration listing what triggers each alert and where it is sent Source: Logging and monitoring (SIEM) On-call schedule or alert routing in effect during the period Source: Logging and monitoring (SIEM) Alert records with acknowledgment time, triage notes and outcome Source: Ticketing system Severity criteria for deciding when an event is an incident Source: Policy repository Type 2: what must exist across the audit period A triage record for alerts raised throughout the period, showing who reviewed each one and whether it became an incident.	Alerts land in a chat channel nobody owns, so there is no record that anyone looked at them or decided whether they were incidents.
CC7.4 Incident response	IR-01 Keep an incident response plan that defines severity levels, roles, escalation, containment, evidence preservation, and customer and regulator communications, and review it at least annually. Cadence Annual	Incident response plan with owner, version and last review date Source: Policy repository Current contact list for responders, legal counsel and critical vendors Source: Policy repository Type 2: what must exist across the audit period The plan reviewed within the period, and incidents in the period handled according to its steps.	The plan names people who have left or tools the company no longer uses, so it has not been kept current.
CC7.4 Incident response CC7.5 Incident recovery	IR-02 Test the incident response plan at least once a year with a tabletop exercise or simulation that includes recovery steps, then update the plan with what the exercise showed. Cadence Annual	Exercise record with date, scenario, participants and findings Source: Exercise and test records Tickets or plan revisions made from the exercise findings Source: Ticketing system Type 2: what must exist across the audit period An exercise dated within the period, with its follow-up actions completed or tracked.	The plan was never exercised, or a tabletop happened but nothing records who took part or what changed afterward.
CC7.4 Incident response CC7.5 Incident recovery	IR-03 Record every security incident with its timeline, the actions taken, the systems restored and how their integrity was confirmed, and complete a post-incident review with corrective actions for significant incidents. Cadence Per event	Incident tickets with detection, containment, recovery and closure times Source: Ticketing system Post-incident reviews with root cause and corrective actions Source: Ticketing system Corrective action tickets tracked to completion Source: Ticketing system Type 2: what must exist across the audit period A complete incident log for the period with full records for each sampled incident. If none occurred, the auditor may rely on the exercise instead.	Incidents were handled in chat with no ticket, so nothing shows the response or recovery, or corrective actions were never finished.
CC2.3 Communication with outside parties CC7.4 Incident response	IR-04 Notify affected customers, and regulators where required, about security incidents within the time frames set by your contracts and applicable law, and keep a copy of each notice. Cadence Per event	Notification procedure listing the contractual and legal notice deadlines that apply Source: Policy repository Copies of notices sent, with dates, to compare against the incident timeline Source: Customer communications Customer contract clauses setting notification commitments Source: Customer and vendor contracts Type 2: what must exist across the audit period A dated notice for each incident in the period that required one, sent within the committed deadline.	Contracts promise notice within a set number of hours that the incident plan never mentions, so nobody tracks that deadline.
CC8.1 Change management CC5.1 Controls that reduce risk	CM-01 Require a pull request reviewed and approved by someone other than the author before any code or infrastructure-as-code change merges to the production branch, enforced by branch protection. Cadence Per event Does not apply for Solo founder. With no second reviewer, rely on the required test gate and a recorded self-review before deploy, keep the deployment log so every change can be traced, and agree this with your auditor.	Branch protection settings requiring approval and blocking self-approval and force pushes Source: Source control and CI/CD List of pull requests merged during the period with reviewer and approval time Source: Source control and CI/CD List of who can bypass branch protection, and a log of each bypass Source: Source control and CI/CD Type 2: what must exist across the audit period Branch protection on throughout the period, and an approval from someone other than the author on each sampled merge.	Admins can bypass branch protection and did, or infrastructure is changed in the cloud console instead of through reviewed code.
CC8.1 Change management	CM-02 Run automated tests and security checks in the CI pipeline on every change, and block the merge or deploy when they fail. Cadence Per event	CI configuration showing the checks required on the production branch Source: Source control and CI/CD Pipeline run history showing checks passed for each deployed change Source: Source control and CI/CD Type 2: what must exist across the audit period Passing check results tied to the changes deployed during the period.	Tests run but are not required, so changes merge with failing or skipped checks.
CC8.1 Change management CC5.2 General technology controls	CM-03 Deploy to production only through the pipeline from the approved branch, restrict who can change production directly, and record each deployment with its commit and time. Cadence Per event	Deployment log linking each release to a commit, an approved change and a timestamp Source: Source control and CI/CD List of people with direct write access to production, with the reason for each Source: Cloud console Type 2: what must exist across the audit period A deployment record for every release in the period that ties back to an approved change.	Engineers deploy from their laptops or edit production directly, leaving changes with no review or record.
CC8.1 Change management	CM-04 Define an emergency change path that lets an urgent fix ship first, then requires review, test evidence and approval within a set number of business days. Cadence Per event	Emergency change procedure stating who can use it and the follow-up deadline Source: Policy repository Emergency change tickets with after-the-fact review and approval dates Source: Ticketing system Type 2: what must exist across the audit period Each emergency change in the period identified as one and approved after the fact within the deadline.	Hotfixes go straight to production with no ticket and no later review, and nobody can list which changes were emergencies.
CC8.1 Change management C1.1 Identifying and protecting confidential information	CM-05 Keep development and test environments separate from production, and keep real customer data out of them unless it is masked or the copy is approved. Cadence Continuous	Cloud account or project structure showing separate production and non-production environments Source: Cloud console Test data rule and the approval for each copy of production data made Source: Policy repository Type 2: what must exist across the audit period No unapproved production data in lower environments during the period, and an approval and masking record for each copy made.	A production database snapshot was restored to staging for debugging and left there under weaker access controls.
CC8.1 Change management	CM-06 Make manual changes to production data, such as fixes run as scripts or edits in a database console, only through an approved ticket, and keep a record of exactly what was run. Cadence Per event	Tickets for production data changes with the approval and the script or query run Source: Ticketing system Database audit log of changes made outside the application Source: Logging and monitoring (SIEM) Type 2: what must exist across the audit period An approved ticket for each manual data change in the period that matches the database log.	Support engineers fix customer records directly in the database with no ticket, so the changes cannot be matched to an approval.
CC9.2 Vendor and business partner risk	VR-01 Keep an inventory of vendors that hold or can reach customer data or affect the service, with a risk tier, an owner and the data each receives. Update it as vendors change, and revoke access when one leaves. Cadence Per event	Vendor inventory with risk tier, owner, data shared and contract dates Source: Vendor inventory Offboarding records for vendors removed in the period, showing access revoked and data returned or deleted Source: Vendor inventory Type 2: what must exist across the audit period Inventory updates for vendors added and removed during the period, each traceable to a contract or invoice.	Tools bought on a company card or by a single team never reach the inventory, so they skip review entirely.
CC9.2 Vendor and business partner risk	VR-02 Assess each vendor's security before signing, and yearly for high-risk ones. Review the SOC 2 report of every provider your service runs on; where none exists, record what you checked instead and a risk decision. Note exceptions and the controls each vendor expects of you. Cadence Annual	Vendor review records with date, reviewer, report period covered and conclusion Source: Vendor inventory Current SOC 2 report for each provider the service runs on, or a record of what was checked instead and the risk decision Source: Vendor inventory List of controls each key vendor expects you to run, and how you meet them Source: Vendor inventory Type 2: what must exist across the audit period A review before onboarding for each vendor added in the period, and an annual review for each high-risk vendor.	Vendors are signed before security reviews them, or a critical provider has no SOC 2 report and nothing records what was checked instead.
CC9.2 Vendor and business partner risk CC2.3 Communication with outside parties	VR-03 Include security, confidentiality, breach notification and data return or deletion terms in contracts with vendors that handle customer data or affect the service. Cadence Per event	Signed agreements or data processing addenda with security and breach-notice clauses Source: Customer and vendor contracts Contract checklist or template listing the terms required for each vendor tier Source: Customer and vendor contracts Type 2: what must exist across the audit period Signed terms in place, before they received customer data, for vendors added during the period.	Click-through terms with key vendors were never checked, so there is no breach-notice commitment the company can rely on.
A1.2 Environmental protection, backup and recovery CC9.1 Business disruption risk	BC-01 Back up production databases and other critical data automatically, encrypt the backups, store them apart from the primary system, and alert an owner when a backup fails. Cadence Continuous	Backup configuration showing schedule, retention, encryption and storage location Source: Backup system Backup job history across the period, with failures and their follow-up Source: Backup system Type 2: what must exist across the audit period Backup job results across the period, with each failure investigated and resolved.	A database added mid-period was never added to the backup schedule, or failure alerts go to no one.
CC9.1 Business disruption risk CC1.4 Hiring and keeping competent people	BC-05 Keep a business continuity plan that covers losing key people, vendors, offices or systems, cross-train or name a successor for each critical role, decide which risks to transfer through insurance, and review the plan annually. Cadence Annual	Business continuity plan with owner and last review date Source: Policy repository Business impact analysis listing critical processes and their dependencies Source: Risk register Cross-training or succession record naming a backup for each critical role Source: HR system Cyber insurance policy, or the documented decision not to carry one Source: Customer and vendor contracts Type 2: what must exist across the audit period The plan and impact analysis reviewed within the period.	The plan covers a data center outage but not losing the one engineer who knows how to deploy, or an outage at a critical vendor.
CC6.1 Logical access security C1.1 Identifying and protecting confidential information	DP-01 Encrypt customer data at rest in databases, storage, backups and replicas, manage keys in your provider's key management service, and limit who can use or change the keys. Cadence Continuous	Encryption-at-rest settings for each data store, backup and replica Source: Cloud console Key policies showing who can use and who can administer each key Source: Cloud console Type 2: what must exist across the audit period Encryption on for data stores created during the period, not only for those that existed at the start.	A storage bucket or replica created mid-period was left unencrypted, and the gap surfaces when the inventory is compared with a live export.
CC9.2 Vendor and business partner risk	AIM-01 Approve each hosted AI model provider and AI tool before customer data is sent to it, review its security, data use and retention terms, keep an approved list staff must follow, and list providers that receive customer data as subprocessors. Cadence Per event Does not apply for No hosted AI models. Neither your product nor your staff send data to hosted AI models. Staff using an AI chat or coding tool at work counts as use, so keep this row if they do.	Approved list of AI providers and tools with the data types permitted in each Source: Vendor inventory Security review for each AI provider covering its assurance reports and data terms Source: Vendor inventory Acceptable-use rule for AI tools, acknowledged by staff Source: Policy repository Subprocessor list entries for each AI provider that receives customer data Source: Customer communications Type 2: what must exist across the audit period A review dated before first use for each AI provider or tool added during the period.	Staff paste customer data into AI tools nobody approved, so the vendor inventory misses providers that now hold customer data.
CC6.7 Data transmission and removal C1.1 Identifying and protecting confidential information	AIM-02 Configure each AI provider so customer data is not used for training, retention is the shortest available and data stays in committed regions. Redact or allowlist the fields sent to models. Recheck quarterly and when terms change. Cadence Quarterly Does not apply for No hosted AI models. You send no data to hosted AI models, so there are no provider settings to configure.	Provider account settings showing training opt-out, retention period and data region Source: AI model provider console Provider data terms or enterprise agreement confirming training and retention commitments Source: Customer and vendor contracts Data-flow diagram showing which customer data is sent to each model Source: Policy repository Redaction rules or field allowlist applied before requests reach a model Source: Source control and CI/CD Type 2: what must exist across the audit period Settings evidence from within the period, and a recorded check each time the provider changed its terms.	A developer account on default terms runs in production, so prompts may be retained or used for training against customer commitments.
CC7.2 Monitoring for anomalies	AIM-03 Log AI requests made by the product with timestamp, model and version, the calling user or service, and any tool actions taken. Store prompt content only where needed, and restrict access to logs that contain customer data. Cadence Continuous Does not apply for No hosted AI models. Your product makes no calls to hosted AI models, so there is no AI activity to log.	Logging configuration for AI calls showing the fields captured Source: Logging and monitoring (SIEM) Sample log entries tying requests to users and model versions Source: Logging and monitoring (SIEM) Retention and access settings for logs holding prompts or outputs Source: Logging and monitoring (SIEM) Type 2: what must exist across the audit period AI request logs available across the period at the level of detail your control describes.	Raw prompts containing customer data are kept indefinitely in a general log store that most of the company can read.
CC8.1 Change management	AIM-04 Treat changes to prompts, model versions, retrieval sources and AI tool permissions as production changes: review, test against an evaluation set, approve and record each one. Cadence Per event Does not apply for No hosted AI models. Your product uses no hosted AI models, so there are no prompts or model versions to change.	Pull requests or tickets for prompt and model changes, with approval Source: Source control and CI/CD Evaluation results run before each release Source: Source control and CI/CD Version history of prompts and model configuration Source: Source control and CI/CD Type 2: what must exist across the audit period A review and evaluation record for each AI change released during the period.	Prompts are edited in a provider dashboard outside source control, so changes have no review, test or history.

Access reviews and deprovisioning are useful places to check before fieldwork because both produce dated evidence an auditor can sample. For AI vendors, include model providers, training-data flows, and subprocessors in the CC9.2 risk assessment rather than treating the cloud infrastructure as the whole vendor boundary.

To go deeper on individual rows, use the access control policy template and the MFA section of the CC6/CC7 security controls guide for CC6.1 to CC6.3, the encryption requirements for stored and transmitted data, security awareness training for staff communication, logging, monitoring and incident response for CC7 (covered in the same guide), change management controls for CC8.1, and vendor management requirements for CC9.2.

Worked Example: Privileged-Access Review

This illustrative entry tailors one library row, the quarterly access review (CC6.2 and CC6.3, in the Security table above), to a single population: production cloud administrators. Replace each value with your own.

Matrix fields	Example entry
Scope, ID, and tailored control	Production cloud administrative access; AC-06. The assigned engineering owner reviews the administrative-access population on the access policy’s cadence, approves retain/revoke decisions, and verifies required removals by the policy deadline.
Owner, cadence, and policy reference	Director of Engineering; quarterly; Access Control Policy, section 4 (privileged access reviews).
Evidence reference	Dated export of production administrator accounts; the owner’s retain/revoke decisions; a removal ticket for each revoked account. Linked artifacts, not just filenames.
Applicability, gap decision, and remediation	Applicable to production cloud administrators. Gap decision: open evidence gap if any removal ticket is missing. Remediation: owner assigned, due date set, closure tracked. An access export alone does not prove review or completed removal.

Availability Controls (A1.1–A1.3) Mapped to Evidence

The Type 2 line in each row is what must exist across the audit period; see SOC 2 Type 2 controls.
Criteria	Control	Evidence auditors request	Common gap
A1.2 Environmental protection, backup and recovery	BC-02 Document a disaster recovery plan with recovery time and recovery point targets that match customer commitments, and design production so it can meet them, for example with multi-zone deployment or a tested restore path. Cadence Annual	Disaster recovery plan with recovery time and recovery point targets, roles and recovery steps Source: Policy repository Architecture settings or restore design showing how the targets can be met, such as multi-zone deployment Source: Cloud console Type 2: what must exist across the audit period The plan reviewed within the period, and a production design that matched it while the service ran.	Recovery targets in customer contracts are tighter than anything the architecture or backup schedule could deliver.
A1.3 Recovery plan testing	BC-03 Test recovery at least annually by restoring backups and walking through the disaster recovery plan, compare the results with recovery targets, and fix the gaps found. Cadence Annual	Restore test record with date, data restored, time taken and how the result was validated Source: Backup system Recovery test report comparing results with recovery targets, with lessons learned Source: Exercise and test records Tickets for gaps found in testing Source: Ticketing system Type 2: what must exist across the audit period A recovery test dated within the period, with results recorded and follow-up completed.	Backups run every day but nobody has ever restored one, so the plan's recovery times are untested assumptions.
A1.1 Capacity monitoring	BC-04 Monitor use of compute, storage and database capacity against set thresholds, alert before limits are reached, and review capacity needs on a set cadence. Cadence Quarterly	Monitoring dashboards and alert thresholds for capacity metrics Source: Logging and monitoring (SIEM) Capacity review notes or tickets with the actions taken Source: Ticketing system Type 2: what must exist across the audit period Capacity alerts and reviews across the period, with the actions taken for each.	Dashboards exist but no thresholds are defined, so nobody is alerted until customers notice slowdowns.
A1.1 Capacity monitoring CC7.2 Monitoring for anomalies CC2.3 Communication with outside parties	BC-06 Monitor availability with external uptime checks, handle outages through the incident process, keep customers informed on a status page, and measure availability against the targets you commit to. The trust services criteria set no uptime number; your commitments do. Cadence Continuous	Uptime monitor setup showing the endpoints checked, the interval and where alerts go Source: Logging and monitoring (SIEM) Outage tickets with start and end times, cause and customer impact Source: Ticketing system Status page history showing outage notices and updates Source: Customer communications Availability measured for each reporting interval and compared with customer commitments Source: Logging and monitoring (SIEM) Type 2: what must exist across the audit period Uptime data for the whole period, an outage record and status update for each outage, and availability compared with commitments for each interval.	Contracts promise an uptime percentage that nobody measures, or outages were fixed with no status update and no record of how long they lasted.

A dated recovery-test result shows that the procedure operated; a disaster-recovery document alone does not. Our SOC 2 business continuity controls guide covers backups, failover, and recovery testing.

Processing Integrity Controls (PI1.1–PI1.5) Mapped to Evidence

The Type 2 line in each row is what must exist across the audit period; see SOC 2 Type 2 controls.
Criteria	Control	Evidence auditors request	Common gap
PI1.1 Processing specifications	PRC-01 Document each in-scope process: the inputs it accepts, what it does to them, the outputs it produces, and the accuracy and timing you promise customers. Cadence Annual	Processing specifications or data dictionary for each in-scope workflow Source: Application and data stores Customer documentation describing processing commitments Source: Customer communications Type 2: what must exist across the audit period Specifications updated for each processing change released during the period.	Processing logic lives only in code and in engineers' heads, so the auditor has nothing to test the outputs against.
PI1.2 Input controls	PRC-02 Validate inputs on the server for type, format, range and required fields, reject or hold bad records, and log each rejection so it can be corrected. Cadence Continuous	Validation rules in code or configuration Source: Source control and CI/CD Rejected-input logs or error queues with how each record was resolved Source: Application and data stores Type 2: what must exist across the audit period Rejection logs across the period, and evidence that rejected records were corrected or returned.	Validation runs only in the browser, so API callers can submit records that skip it.
PI1.3 Processing controls	PRC-03 Monitor processing jobs for failures, delays and incomplete runs, alert an owner, and record how each exception was fixed or the data reprocessed. Cadence Continuous	Job monitoring dashboard and alert settings Source: Logging and monitoring (SIEM) Exception tickets showing cause, reprocessing and resolution Source: Ticketing system Type 2: what must exist across the audit period Exceptions raised during the period, each with a resolution record.	Failed jobs retry silently or drop records, and nobody can show that every input was processed.
PI1.3 Processing controls	PRC-04 Test every change to processing logic, such as calculations and data transformations, against expected results before release, hotfixes included. Cadence Per event	Test cases for processing logic with their expected results Source: Source control and CI/CD Release records showing those tests passed before deployment Source: Source control and CI/CD Type 2: what must exist across the audit period Passing test results for each processing change released during the period.	Hotfixes to processing logic skip the test suite, so calculation errors can reach customers.
PI1.4 Output controls	PRC-05 Reconcile outputs to inputs using record counts or control totals, and deliver outputs only to the intended recipients through approved channels. Cadence Per event	Reconciliation reports with any differences and their resolution Source: Application and data stores Output delivery settings showing recipients and access restrictions Source: Application and data stores Type 2: what must exist across the audit period A reconciliation for each processing run or batch in the period, with differences resolved.	Output reports are checked for format but never reconciled to inputs, so missing records go unnoticed.
PI1.5 Storage of inputs, work in progress and outputs	PRC-06 Protect stored inputs, in-process data and outputs from unauthorized change, keep an audit trail of changes to those records, and retain them as long as your specifications require. Cadence Continuous	Audit trail or change history settings for in-scope records Source: Application and data stores Access settings limiting who can modify stored processing data Source: Cloud console Retention settings for inputs and outputs Source: Application and data stores Type 2: what must exist across the audit period Audit trail entries across the period showing changes were captured and attributable to a person or process.	Records can be edited with no history, so nobody can show that stored outputs still match what was originally produced.

For reconciliation controls, retain evidence that traces inputs through processing to outputs, including errors and their resolution. An output report alone may not show whether the full input population was processed.

Confidentiality Controls (C1.1–C1.2) Mapped to Evidence

The Type 2 line in each row is what must exist across the audit period; see SOC 2 Type 2 controls.
Criteria	Control	Evidence auditors request	Common gap
C1.1 Identifying and protecting confidential information	DP-02 Classify your data, mark which customer and business information is confidential, and set handling rules for each class covering where it may be stored, who may access it and how it may be shared. Cadence Annual	Data classification policy with handling rules for each class Source: Policy repository Data inventory showing where confidential information is stored and how it is classified Source: Asset inventory Customer contract clauses identifying information you must treat as confidential Source: Customer and vendor contracts Type 2: what must exist across the audit period Handling rules applied to data stores added during the period, with the inventory updated to match.	There is no classification scheme, so nobody can say which data the confidentiality terms in customer contracts actually cover.
C1.2 Disposing of confidential information	DP-03 Delete confidential information when its retention period ends or a customer leaves, including copies in exports and with vendors, let backups expire on schedule, and record each deletion. Cadence Per event	Retention schedule by data type, including backup expiry Source: Policy repository Deletion records or job logs for departed customers and expired data Source: Application and data stores Vendor confirmations of deletion where a vendor held the data Source: Vendor inventory Type 2: what must exist across the audit period A deletion record for each customer that left during the period, and logs from scheduled deletion jobs across it.	Deletion is promised in contracts but never done, or done in the main database while copies remain in exports and analytics tools.

For a disposal control, keep evidence of completed deletion and relevant sub-processor disposal records. A retention policy states the rule; it does not show that deletion occurred.

Privacy Controls (P1–P8 series) Mapped to Evidence

Privacy adds 18 individual criteria across eight series: notice (P1), choice and consent (P2), collection (P3), use, retention and disposal (P4), access (P5), disclosure and notification (P6), quality (P7), and monitoring and enforcement (P8). Each of the 18 has at least one example control below, and some controls answer more than one: the third-party disclosure row covers P6.1, P6.2, and P6.7.

The Type 2 line in each row is what must exist across the audit period; see SOC 2 Type 2 controls.
Criteria	Control	Evidence auditors request	Common gap
P1.1 Privacy notice	PV-01 Publish a privacy notice covering what personal information you collect, why, how long you keep it, who receives it and people's rights, and update it before practices change. For data you process for customers, describe your handling in your terms or processing agreement. Cadence Annual	Current privacy notice with version history and effective dates Source: Privacy records Review record comparing the notice with actual data flows Source: Privacy records Type 2: what must exist across the audit period The notice versions in effect during the period, and a review showing they matched practice.	The notice was copied from a template and lists uses or retention periods that do not match what the product does.
P2.1 Choice and consent P3.2 Explicit consent at collection	PV-02 Show people their choices when you collect personal information, record consent where law or your notice requires it (explicit for sensitive data), and honor withdrawals by the deadline your notice or the law sets. Cadence Per event	Consent records showing the person, what they agreed to, the notice version and a timestamp Source: Privacy records Opt-out and withdrawal requests with the date each took effect Source: Privacy records Screenshots of the consent and choice points in the product Source: Application and data stores Type 2: what must exist across the audit period Consent records for people who signed up during the period and the processing date for each withdrawal. For personal information customers send you, document that consent is their responsibility and process it only as your contract allows.	Consent is captured but stored without a timestamp or notice version, so the company cannot show what a person agreed to.
P3.1 Collection limited to stated objectives P4.1 Use limited to identified purposes	PV-03 Keep an inventory of the personal information you hold, each field's purpose and where it flows, and review new features before they collect it or use it for a new purpose. Use personal information customers send you only for the purposes in your contract with them. Cadence Per event	Personal data inventory or record of processing with the purpose for each category Source: Privacy records Privacy review records for new features and new data uses Source: Privacy records Type 2: what must exist across the audit period A privacy review for each feature launched during the period that touched personal information.	Analytics and support tools collect fields the notice never mentions, so collection goes beyond the stated purposes.
P4.2 Retention P4.3 Disposal	PV-04 Set retention periods for personal information, delete or anonymize it when the period ends or a valid deletion request arrives, and record each deletion. Cadence Per event	Retention schedule for each type of personal information Source: Privacy records Deletion job logs and deletion request records with completion dates Source: Application and data stores Type 2: what must exist across the audit period Deletion records for requests received and scheduled purges run during the period.	No retention periods are defined, so personal information is kept indefinitely across databases, logs and backups.
P5.1 Data subject access	PV-05 Handle requests from individuals to see their personal information: verify identity, respond within legal and committed deadlines, and log each request and response. Route requests about data you hold for a customer to that customer. Cadence Per event	Request log with received date, identity check, response date and outcome Source: Privacy records Request handling procedure, including when requests pass to the customer who controls the data Source: Policy repository Type 2: what must exist across the audit period A log entry and a response for each access request received during the period.	Requests arrive by email and are answered ad hoc with no log, so neither timeliness nor identity checks can be shown.
P5.2 Correction requests P7.1 Data quality	PV-06 Let individuals correct their personal information, validate key fields when they are collected, pass corrections on to vendors that received the data, and route requests about customer-held data to that customer. Cadence Per event	Correction request log with outcome and date Source: Privacy records Product settings or support workflow that lets users update their own data Source: Application and data stores Validation rules that check key personal fields, such as email and date of birth, when they are collected Source: Source control and CI/CD Type 2: what must exist across the audit period A record for each correction request received in the period, including updates sent to vendors.	Corrections update the main database but not the copies held by vendors or downstream systems.
P6.1 Consent before disclosure to third parties P6.2 Record of authorized disclosures P6.7 Accounting of disclosures	PV-07 Share personal information with third parties only for purposes your notice describes or with consent, keep a list of subprocessors, and record disclosures so you can tell a person who received their data. Cadence Per event	Published subprocessor list with its change history Source: Customer communications Disclosure log for sharing outside the subprocessor list, such as legal requests Source: Privacy records Responses to individuals who asked who received their data Source: Privacy records Type 2: what must exist across the audit period Disclosure records for the period, and a notice for each subprocessor change made during it.	New subprocessors are added without updating the public list or notifying customers as their contracts require.
P6.3 Record of unauthorized disclosures P6.6 Breach notification to affected parties	PV-08 Log every unauthorized disclosure of personal information and assess whether notice is required. Where a customer controls the data, notify that customer, who notifies individuals and regulators. Where you control it, notify them yourself. Meet legal and contractual deadlines. Cadence Per event	Privacy incident log with date, data involved, assessment and notice decision Source: Privacy records Copies of notifications sent, with dates Source: Customer communications Type 2: what must exist across the audit period An entry for each privacy incident in the period, with its notice decision and any notices sent on time.	Small disclosures, such as an email sent to the wrong customer, are never logged, so the record of unauthorized disclosures is empty.
P6.4 Vendor privacy commitments P6.5 Vendor notice of unauthorized disclosures	PV-09 Sign data processing terms with every vendor that receives personal information, requiring privacy commitments that match yours and prompt notice of any unauthorized disclosure. Cadence Per event	Signed data processing agreements for each vendor that receives personal information Source: Customer and vendor contracts Vendor review notes on each vendor's privacy practices Source: Vendor inventory Disclosure notices received from vendors and how each was handled Source: Privacy records Type 2: what must exist across the audit period Agreements in place before personal information went to any vendor added during the period.	The vendor list and the signed processing agreements do not match, leaving some vendors with personal data and no privacy terms.
P8.1 Inquiries, complaints and monitoring	PV-10 Give individuals a way to send privacy questions and complaints, log and resolve each one, forward complaints about customer-controlled data to that customer, and review privacy compliance at least annually with fixes tracked. Cadence Annual	Privacy contact channel published in the notice Source: Customer communications Inquiry and complaint log with resolution dates Source: Privacy records Annual privacy compliance review with findings and remediation Source: Privacy records Type 2: what must exist across the audit period A logged outcome for each inquiry received in the period, and the annual review completed with follow-up.	Complaints reach support as ordinary tickets and are never flagged as privacy issues, so nobody reviews them for patterns or fixes the cause.

What Are SOC 2 Controls?

A control is a defined action or process that addresses a risk and maps to applicable criteria. A policy states the requirement; the control implements it; evidence records its design or performance. MFA enforcement, access reviews, and recovery tests are examples. A control description is not itself evidence that the control operated.

What Are the Five SOC 2 Trust Services Criteria?

The five Trust Services categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Every SOC 2 report covers the Common Criteria behind Security, and nearly every report includes Security as a category. You add the other four according to the commitments you make to customers. The at-a-glance table near the top of this page lists each category’s criteria, when to add it, and how many example controls our library maps to it.

Which Categories to Add

Add Availability if you commit to uptime or recovery, Processing Integrity if customers rely on your processing being complete and accurate, Confidentiality if you hold data designated as confidential, and Privacy if you collect personal information directly from individuals. The Trust Services Criteria guide explains how to choose categories against customer commitments. For the wider framework, see the SOC 2 compliance guide.

Gap Checks Before You Mark a Control Ready

Use these checks alongside the tables; they describe gaps to investigate, not measured exception rates.

Connect each control to an identified risk, an applicable criterion, and a responsible owner. Reassess scope when systems or vendor data flows change; for AI services, include model providers and training-data flows where relevant.
For access, check all in-scope access paths, approved exceptions, dated review decisions, and completed removal records against your policy’s deadline. Keep physical access and asset disposal evidence separate.
For changes, retain approval and testing evidence, including the emergency-change process. For incidents, retain response/recovery records or exercise outcomes and follow-up actions.
For monitoring, demonstrate that your designed evaluations ran and that identified deficiencies were assessed and followed up. Choose the evaluation approach for your scope and risks; tooling alone does not demonstrate performance.
Where scoped, test recovery against your commitments, trace processing inputs to outputs, verify confidential-data disposal, and connect privacy notices, consent, access requests, and disclosure processes to actual practice. Keep dated results and unresolved findings.

Testing and monitoring evidence has its own guides: SOC 2 penetration testing requirements, with red team assessments for broader testing. For identity and email threats, see the access control policy template and security awareness training.

How Do You Implement and Document SOC 2 Controls?

Work through the blank columns in the Excel template or CSV in this order. Blank means undecided; it does not mean a control is implemented or out of scope.

Tailor each example control to your actual system and risk. Fill system_scope and tailored_control_statement with the boundary, action, population, and how completion is checked.
Map the control to an internal policy or risk reference. Record applicability and the reason for including or excluding the example.
Assign an owner and operating cadence. Use organization_control_id for your internal identifier, and replace the suggested cadence with the schedule or event trigger your policy defines.
Attach dated evidence and record the current exception status. Put artifact links or repository paths in evidence_reference; use gap_decision to distinguish missing control design, missing performance evidence, unresolved remediation, or no identified gap. In remediation_action, record the action, responsible person, due date, and closure evidence.

Keep policies, tailored control descriptions, and evidence linked but distinct. Type 1 evaluates design as of a specified date; Type 2 also tests operating effectiveness over an agreed period. For Type 2, retain the relevant populations and performance records across that period rather than replacing them with a final screenshot. The Type 2 controls guide explains populations and sampling. To write the procedure behind a control, use our SOC 2 internal control procedure template. For collecting and organizing the evidence itself, see the SOC 2 evidence request list; SOC 2 compliance software compared covers tools that automate it.

How Do You Prepare for a SOC 2 Audit?

Once the inventory exposes gaps, use the SOC 2 compliance checklist, which has a free Excel, PDF, and CSV, for the wider preparation sequence, or the SOC 2 readiness assessment to see which gaps matter before fieldwork. If you would rather not close them alone, you can compare SOC 2 readiness firms that help with remediation. Compare scope and fees in the SOC 2 audit cost guide and Type 2 cost guide. To compare CPA firms by industry and engagement fit, browse the auditor directory or request matched quotes.

Answering Your Top SOC 2 Control Questions

Is There an Official AICPA SOC 2 Controls List?

No. The AICPA publishes criteria, not controls. The 2017 Trust Services Criteria with revised points of focus (2022) define 61 criteria: 33 Common Criteria under Security (CC1–CC9), plus 28 supplemental criteria for Availability, Processing Integrity, Confidentiality, and Privacy. Privacy has 18 of them, across the P1–P8 series. Your organization designs controls for its applicable criteria. Our library maps example controls to all 61, but your auditor tests your own controls and evidence, not the examples.

Is There a Free SOC 2 Controls List in Excel?

Yes. The Excel template maps 82 example controls to all 61 criteria, with the evidence, the Type 2 period evidence, and a common gap for each, and it is free with no signup. Download it from the matrix section above, or take the PDF or CSV. The workbook adds a status dropdown, an Instructions sheet, and a criteria-coverage sheet. The files are starting points, so tailor each control and confirm applicability with your CPA firm.

How Many SOC 2 Controls Do I Really Need?

There is no fixed number. Our library holds 82 example controls across all five categories, as a starting inventory rather than a target. Linford & Company, a CPA firm, wrote in February 2025 that a report covering the Security criteria alone usually involves about 60 to 80 controls, with more for each added category. Your own count depends on your services, risks, system boundaries, and scope. Check coverage of the applicable criteria and whether each control works as designed, rather than aiming for a number.

What Evidence Do SOC 2 Auditors Request for Each Control?

Evidence depends on the control, scope, and report type. Examples include MFA settings, dated access-review decisions and removal tickets, scan reports with remediation records, approved changes, recovery-test results, reconciliation reports, and deletion logs. Type 1 evaluates design as of a specified date; Type 2 also tests operating effectiveness over an agreed period. Your CPA firm sets the actual requests and samples.

What’s the Difference Between a Control and a Policy?

A policy defines the requirement; a control is the action that implements it. For example, a policy may require MFA for human administrative access to production systems. An implementing control enforces MFA for that defined population, checks approved exceptions, and retains configuration and review evidence. This is an illustrative access-policy example, not a universal SOC 2 prescription.

Can I Just Use a Template for My Controls?

Use a template to start an inventory, then tailor the scope, action, owner, cadence, and evidence. Review applicable-criterion coverage with your CPA firm; a filled spreadsheet does not prove that coverage or operation.

How Often Should We Review Our SOC 2 Controls?

Define review cadences according to your risks, commitments, and policies. Reassess when products, systems, vendor relationships, or data handling change. Record the review, decisions, and follow-up; a calendar entry shows only that a review was scheduled.

SOC 2 Controls List and Matrix (2026): Free Excel and PDF

Download the SOC 2 Controls Matrix (Excel, PDF, CSV)

SOC 2 Control Examples Mapped to Evidence

Security Controls (CC1–CC9) Mapped to Evidence

Worked Example: Privileged-Access Review

Availability Controls (A1.1–A1.3) Mapped to Evidence

Processing Integrity Controls (PI1.1–PI1.5) Mapped to Evidence

Confidentiality Controls (C1.1–C1.2) Mapped to Evidence

Privacy Controls (P1–P8 series) Mapped to Evidence

What Are SOC 2 Controls?

What Are the Five SOC 2 Trust Services Criteria?

Which Categories to Add

Gap Checks Before You Mark a Control Ready

How Do You Implement and Document SOC 2 Controls?

How Do You Prepare for a SOC 2 Audit?

Answering Your Top SOC 2 Control Questions

Is There an Official AICPA SOC 2 Controls List?

Is There a Free SOC 2 Controls List in Excel?

How Many SOC 2 Controls Do I Really Need?

What Evidence Do SOC 2 Auditors Request for Each Control?

What’s the Difference Between a Control and a Policy?

Can I Just Use a Template for My Controls?

How Often Should We Review Our SOC 2 Controls?

Go deeper, by topic

Controls implementation

Skip the auditor RFP grind.

SOC 2 Controls List and Matrix (2026): Free Excel and PDF

Download the SOC 2 Controls Matrix (Excel, PDF, CSV)

SOC 2 Control Examples Mapped to Evidence

Security Controls (CC1–CC9) Mapped to Evidence

Worked Example: Privileged-Access Review

Availability Controls (A1.1–A1.3) Mapped to Evidence

Processing Integrity Controls (PI1.1–PI1.5) Mapped to Evidence

Confidentiality Controls (C1.1–C1.2) Mapped to Evidence

Privacy Controls (P1–P8 series) Mapped to Evidence

What Are SOC 2 Controls?

What Are the Five SOC 2 Trust Services Criteria?

Which Categories to Add

Gap Checks Before You Mark a Control Ready

How Do You Implement and Document SOC 2 Controls?

How Do You Prepare for a SOC 2 Audit?

Answering Your Top SOC 2 Control Questions

Is There an Official AICPA SOC 2 Controls List?

Is There a Free SOC 2 Controls List in Excel?

How Many SOC 2 Controls Do I Really Need?

What Evidence Do SOC 2 Auditors Request for Each Control?

What’s the Difference Between a Control and a Policy?

Can I Just Use a Template for My Controls?

How Often Should We Review Our SOC 2 Controls?

Go deeper, by topic

Controls implementation

Next step

Compare SOC 2 readiness firms

Skip the auditor RFP grind.