SOC 2 Controls ListEvery Trust Services Criterion, Example Controls, and the Evidence Auditors Ask For
If you are searching for a SOC 2 controls list, the first thing to know is that SOC 2 does not publish one. The AICPA defines a fixed set of Trust Services Criteria, and each organization designs its own controls to meet the criteria it puts in scope. What follows is the closest thing to an official list that exists: all 61 criteria across the five Trust Services categories, with what each one requires, the controls a small or mid-sized business typically implements to satisfy it, and the evidence a SOC 2 auditor will request. Petronella Technology Group has prepared regulated businesses in Raleigh, the Research Triangle, and nationwide for compliance examinations since 2002, and this reference reflects how those engagements actually unfold.
Last Updated: October 24, 2026
- There is no fixed SOC 2 controls list. The AICPA Trust Services Criteria (TSC 2017, with points of focus revised in 2022) are fixed. The controls that satisfy them are written by each organization and tested by its auditor. Two companies with clean SOC 2 reports can have very different control sets.
- Security is mandatory; the other four categories are optional. Every SOC 2 report includes the 33 Common Criteria (CC1 through CC9). Availability, Processing Integrity, Confidentiality, and Privacy are added only when they matter to your customers.
- 61 criteria in total. 33 common criteria, 3 for Availability, 5 for Processing Integrity, 2 for Confidentiality, and 18 for Privacy. Many small and mid-sized businesses begin with Security only or Security plus Availability.
- Type 1 tests design; Type 2 tests operation. A Type 1 report evaluates whether controls are suitably designed as of a point in time. A Type 2 report also tests whether they operated effectively across a review period, commonly 3 to 12 months.
- Evidence is the whole game. A control you cannot prove is a control the auditor cannot credit. This page lists the evidence an auditor typically asks for next to every criterion.
Why There Is No Official SOC 2 Controls List (and What Exists Instead)
SOC 2 is an attestation framework, not a prescriptive standard. The AICPA publishes the Trust Services Criteria, a set of outcomes a service organization's system must achieve, along with points of focus that describe what an auditor should consider when evaluating each criterion. The organization under examination writes its own controls: specific, repeatable activities performed by named people or systems that produce evidence. The independent CPA firm then forms an opinion on whether those controls are suitably designed to meet the criteria and, in a Type 2 report, whether they operated effectively during the review period.
This is the opposite of frameworks like PCI DSS or NIST SP 800-171, which publish numbered requirements that every organization must implement in substantially the same way. It is why a search for "soc 2 controls list" returns so many conflicting answers. Vendors publish their own control libraries and present them as if they were the standard. They are not. They are one firm's interpretation of how to meet the criteria, and your auditor will test your controls, not theirs.
The practical consequence for a business in Raleigh or anywhere else preparing for its first examination is this: you do not need to adopt someone else's giant list. You need to understand the 33 common criteria (plus any optional categories you include), write a reasonable number of controls that genuinely address them, and prove those controls work. The sections below walk through every criterion with that goal in mind. For the step-by-step readiness process, see our SOC 2 compliance checklist; for an overview of the examination itself, see SOC 2 compliance services.
SOC 2 Trust Services Criteria at a Glance
The table below summarizes the five Trust Services categories, the criterion identifiers in each, how many criteria they contain, and whether the category is required. The Security category is organized into nine series called the Common Criteria, because the same criteria also serve as the foundation when any optional category is added. CC1 through CC5 correspond to the 17 principles of the COSO 2013 Internal Control framework, which is why they read more like governance requirements than technical ones.
| Category / Series | Criteria IDs | Count | Mandatory? |
|---|---|---|---|
| CC1 Control Environment | CC1.1 to CC1.5 | 5 | Yes (Security) |
| CC2 Communication and Information | CC2.1 to CC2.3 | 3 | Yes (Security) |
| CC3 Risk Assessment | CC3.1 to CC3.4 | 4 | Yes (Security) |
| CC4 Monitoring Activities | CC4.1 to CC4.2 | 2 | Yes (Security) |
| CC5 Control Activities | CC5.1 to CC5.3 | 3 | Yes (Security) |
| CC6 Logical and Physical Access Controls | CC6.1 to CC6.8 | 8 | Yes (Security) |
| CC7 System Operations | CC7.1 to CC7.5 | 5 | Yes (Security) |
| CC8 Change Management | CC8.1 | 1 | Yes (Security) |
| CC9 Risk Mitigation | CC9.1 to CC9.2 | 2 | Yes (Security) |
| Availability | A1.1 to A1.3 | 3 | Optional |
| Processing Integrity | PI1.1 to PI1.5 | 5 | Optional |
| Confidentiality | C1.1 to C1.2 | 2 | Optional |
| Privacy | P1.1, P2.1, P3.1 to P3.2, P4.1 to P4.3, P5.1 to P5.2, P6.1 to P6.7, P7.1, P8.1 | 18 | Optional |
| Total | All five categories | 61 | 33 mandatory, 28 optional |
Everything that follows uses the same four-column format: the criterion, what it requires in plain language, two to four example controls that a small or mid-sized business realistically implements, and the evidence an auditor typically requests. Treat the example controls as a starting vocabulary, not a checklist to copy. The right control for your business depends on your system, your people, and the commitments you have made to customers.
CC1: Control Environment (5 Criteria)
CC1 asks whether leadership has built an organization where controls can succeed: ethical expectations are stated, oversight exists, responsibilities are assigned, people are competent, and someone is accountable. For a company of twenty people these criteria are satisfied with a handful of documents and a few recurring activities. The mistake is treating them as paperwork and letting the evidence lapse mid-period.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC1.1 | The entity demonstrates a commitment to integrity and ethical values. | Written code of conduct acknowledged by every employee and contractor at hire and annually; documented disciplinary process; anonymous reporting channel for ethics concerns. | Signed acknowledgments for a sample of employees; the code of conduct itself; evidence that the reporting channel exists and is communicated. |
| CC1.2 | The board of directors or equivalent demonstrates independence from management and exercises oversight of internal control. | Board or advisory committee charter; quarterly security and compliance briefing to the board; for founder-led companies, a documented oversight role such as an outside advisor or fractional CISO. | Charter or bylaws; meeting minutes or briefing decks showing security topics were discussed; attendance records. |
| CC1.3 | Management establishes structures, reporting lines, and authorities and responsibilities in pursuit of objectives. | Current organizational chart; information security policy naming the owner of the security program; RACI or responsibility matrix for key controls. | Org chart with dates; policy with named owner and approval date; job descriptions for security-relevant roles. |
| CC1.4 | The entity demonstrates a commitment to attract, develop, and retain competent individuals. | Background checks before hire; role-based onboarding checklist including security training; annual security awareness training with completion tracking; performance review cycle. | Background check confirmations for a sample of new hires; training completion reports; onboarding checklists completed for sampled hires. |
| CC1.5 | The entity holds individuals accountable for their internal control responsibilities. | Security responsibilities written into job descriptions; annual performance reviews that include policy compliance; sanctions policy applied when violations occur. | Sampled job descriptions; completed performance reviews; sanction records (or a statement that none were required) for the period. |
CC2: Communication and Information (3 Criteria)
CC2 covers the flow of information: whether the organization produces quality information to run its controls, whether it tells its own people what they need to know, and whether it communicates with customers, vendors, and other external parties about security commitments and incidents. Your system description and your customer-facing security commitments live here.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC2.1 | The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. | Centralized logging from production systems, identity provider, and endpoints; asset inventory maintained in a system of record; data classification scheme applied to repositories. | Log retention configuration; asset inventory export with dates; data classification policy and examples of labeled assets. |
| CC2.2 | The entity internally communicates information, including objectives and responsibilities for internal control. | Published policy library accessible to all staff; annual policy acknowledgment; new-hire security orientation; internal channel for security announcements. | Policy acknowledgment reports; orientation materials and attendance; samples of security communications sent during the period. |
| CC2.3 | The entity communicates with external parties regarding matters affecting the functioning of internal control. | Published system description and security commitments (terms of service, SLA, trust page); customer incident notification procedure with defined timelines; vendor security requirements in contracts. | System description; customer agreements; incident notification templates; evidence of notifications sent if an incident occurred. |
CC3: Risk Assessment (4 Criteria)
CC3 requires a documented, repeated process for identifying what could prevent the organization from meeting its objectives, including fraud risk and the risk introduced by change. Auditors look for a risk register that is actually used, not a spreadsheet created the week before fieldwork. A formal compliance risk assessment performed annually and refreshed after significant changes satisfies all four criteria for most SMBs.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC3.1 | The entity specifies objectives with sufficient clarity to enable identification and assessment of risks relating to objectives. | Documented business and security objectives tied to customer commitments; risk assessment methodology that references those objectives. | Risk assessment policy; objectives statement in the system description or risk methodology document. |
| CC3.2 | The entity identifies risks to the achievement of its objectives and analyzes risks as a basis for determining how they should be managed. | Annual enterprise risk assessment producing a risk register with likelihood, impact, owner, and treatment; vendor risk assessment for critical third parties; vulnerability scanning feeding the register. | Completed risk register with dates and approvals; vendor risk reviews; evidence the assessment was reviewed by management. |
| CC3.3 | The entity considers the potential for fraud in assessing risks. | Fraud risk scenarios included in the risk assessment; segregation of duties for payments and production deployments; privileged access limited and logged. | Fraud section of the risk register; segregation of duties matrix; privileged account list. |
| CC3.4 | The entity identifies and assesses changes that could significantly impact the system of internal control. | Risk assessment refreshed on major change triggers (new product, new cloud region, acquisition, key personnel departure); change management process includes a risk impact field. | Updated risk register entries tied to specific changes; change tickets showing risk assessment fields completed. |
CC4: Monitoring Activities (2 Criteria)
CC4 asks whether the organization checks that its controls are working and fixes them when they are not. This is where continuous compliance tooling and an internal audit function, however informal, earn their place. An auditor wants to see that someone other than the control operator looked at the control during the period and that findings were tracked to closure.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC4.1 | The entity selects, develops, and performs ongoing and separate evaluations to ascertain whether components of internal control are present and functioning. | Quarterly internal control self-assessment; continuous monitoring platform that tests configuration controls daily; annual penetration test; periodic vulnerability scans. | Self-assessment results; monitoring platform dashboards and test history; penetration test report; scan reports with dates. |
| CC4.2 | The entity evaluates and communicates internal control deficiencies in a timely manner to parties responsible for taking corrective action, including senior management and the board. | Findings tracker with owners and due dates; deficiencies reported to leadership in a recurring security review; remediation verified before closure. | Findings log showing open and closed items with dates; management review minutes; evidence of remediation for sampled findings. |
CC5: Control Activities (3 Criteria)
CC5 is the bridge between risk and action. It requires that the organization select controls that actually respond to identified risks, that technology controls are chosen deliberately, and that policies are backed by procedures someone follows. If your risk register says "ransomware" and nothing in your control set addresses backups, endpoint detection, or phishing training, CC5 is where that gap surfaces.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC5.1 | The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. | Risk register maps each risk to one or more controls; control matrix maintained and reviewed annually; segregation of duties where feasible, with compensating review where not. | Risk-to-control mapping; control matrix with review dates; segregation of duties analysis. |
| CC5.2 | The entity selects and develops general control activities over technology to support the achievement of objectives. | Baseline configuration standards for servers, endpoints, and cloud accounts; infrastructure as code with peer review; endpoint detection and response on all managed devices. | Configuration baselines; sample of infrastructure change reviews; endpoint agent coverage report. |
| CC5.3 | The entity deploys control activities through policies that establish what is expected and procedures that put policies into action. | Policy set reviewed and approved annually by management; procedures or runbooks for recurring controls such as access reviews and backup restoration tests. | Policies with approval signatures and dates; procedure documents; evidence procedures were followed (completed checklists, tickets). |
Not Sure Which Criteria Belong in Your Scope?
Petronella Technology Group runs a SOC 2 readiness assessment that maps your current practices against every criterion on this page, identifies where controls are missing or unprovable, and produces a prioritized remediation plan before you engage an audit firm. Craig Petronella, CMMC Registered Practitioner and author of the CMMC 2.0 Certification Guide, leads the control-mapping work. Tell us what your customers are asking for and we will tell you what the examination will actually require.
CC6: Logical and Physical Access Controls (8 Criteria)
CC6 is the largest series and the one where most exceptions are written. It covers the full identity lifecycle: who gets access, how they authenticate, how access is reviewed and removed, how data is protected at rest and in transit, and how physical locations and media are secured. Nearly every control here produces evidence continuously, which makes it the easiest series to automate and the most painful to reconstruct after the fact.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC6.1 | The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. | Single sign-on with multi-factor authentication enforced for all workforce accounts; role-based access control in production systems; encryption of data at rest; network segmentation between production and corporate environments. | MFA enforcement configuration and exception list; role definitions and assignment reports; encryption settings for databases and storage; network diagrams. |
| CC6.2 | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users; credentials are removed when access is no longer authorized. | Access request ticket approved by manager before provisioning; automated deprovisioning triggered by HR termination; offboarding checklist completed within one business day. | Sampled access requests with approvals; termination list reconciled to account disablement dates; completed offboarding checklists. |
| CC6.3 | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design, considering least privilege and segregation of duties. | Quarterly user access review of all production and administrative accounts; role change triggers access re-approval; privileged accounts separate from daily-use accounts. | Access review records showing reviewer, date, and actions taken; privileged account inventory; evidence of access removed following reviews. |
| CC6.4 | The entity restricts physical access to facilities and protected information assets to authorized personnel. | Badge access to office with visitor log; cloud data center physical controls inherited from the provider's SOC 2 report (carved out or included as a complementary subservice organization control). | Badge access list and visitor logs; provider SOC 2 report reviewed and on file with documented review. |
| CC6.5 | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data has been diminished and is no longer required. | Full-disk encryption on all laptops; media sanitization or certified destruction before disposal or return; cloud storage deletion procedures. | Encryption compliance report from device management; destruction certificates; asset disposal records. |
| CC6.6 | The entity implements logical access security measures to protect against threats from sources outside its system boundaries. | Firewalls and security groups with default-deny rules; web application firewall for public applications; intrusion detection; annual external penetration test. | Firewall rule exports; WAF configuration; IDS alert samples; penetration test report and remediation tracking. |
| CC6.7 | The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal. | TLS 1.2 or higher enforced on all external endpoints; email encryption for sensitive data; data loss prevention rules blocking uploads of classified data to unapproved destinations; USB storage restricted. | TLS configuration scans; DLP policy and alert samples; device management policy showing removable media restrictions. |
| CC6.8 | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. | Endpoint detection and response on every workstation and server through a Managed XDR service; application allowlisting or restricted installation rights; automated patching with defined timelines. | EDR coverage and alert reports; patch compliance reports; local administrator rights report. |
CC7: System Operations (5 Criteria)
CC7 covers detection and response: knowing when something is wrong, investigating it, containing it, and recovering from it. Auditors test this series by asking what happened during the period. If you had incidents, they will trace them through your process. If you had none, they will ask for evidence that you would have known, which means monitoring alerts, vulnerability scans, and a tested incident response plan.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC7.1 | The entity uses detection and monitoring procedures to identify changes to configurations that result in new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. | Authenticated vulnerability scanning on a defined cadence; configuration drift detection in cloud accounts; file integrity monitoring on critical servers; vulnerability remediation timelines by severity. | Scan schedules and reports; drift alerts; remediation tickets showing closure within the policy timeline. |
| CC7.2 | The entity monitors system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives. | Centralized log collection with alerting; 24/7 security operations center monitoring; uptime and performance monitoring with on-call escalation. | SIEM or log platform configuration; sample alerts and triage notes; on-call schedule and escalation records. |
| CC7.3 | The entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives (security incidents) and, if so, takes actions to prevent or address such failures. | Documented triage procedure classifying events by severity; incident tickets for every escalated event; post-incident review for significant incidents. | Incident log for the period; sampled incident tickets with classification and timeline; post-incident review documents. |
| CC7.4 | The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents. | Written incident response plan with roles, contact list, and customer notification criteria; annual tabletop exercise; retained incident response and forensics capability. | Incident response plan with approval date; tabletop exercise report and attendance; incident records demonstrating the plan was followed. |
| CC7.5 | The entity identifies, develops, and implements activities to recover from identified security incidents. | Backup and restoration procedures tested at least annually; lessons-learned process feeding control improvements; recovery runbooks for critical systems. | Backup restoration test results; post-incident action items tracked to closure; recovery runbooks. |
CC8: Change Management (1 Criterion)
CC8 is a single criterion with an outsized share of audit testing, because every production change during the review period is a potential sample. The auditor wants to see that changes are authorized, tested, reviewed by someone other than the author, and deployed through a controlled process. Engineering teams that already practice pull-request review and CI/CD are most of the way there; the work is making the trail visible and consistent.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC8.1 | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. | All code changes through version control with mandatory peer review before merge; automated test suite must pass before deployment; production deployment restricted to a deployment pipeline or named individuals; emergency change procedure with retroactive review; infrastructure changes tracked the same way as code. | Branch protection settings; sample of merged pull requests showing reviewer and test status; deployment logs reconciled to approved changes; emergency change records with after-the-fact approvals. |
CC9: Risk Mitigation (2 Criteria)
CC9 addresses two specific risk areas that the AICPA broke out from CC3: business disruption and vendors. For most SMBs the vendor half is the harder one, because it requires knowing which third parties touch customer data, assessing them, and holding them to commitments in writing.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| CC9.1 | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions. | Business continuity and disaster recovery plan with defined recovery objectives; annual DR test; cyber insurance coverage reviewed annually. | BC/DR plan with approval date; DR test results and remediation; insurance policy summary. |
| CC9.2 | The entity assesses and manages risks associated with vendors and business partners. | Vendor inventory classifying each by data access and criticality; security review (SOC 2 report, questionnaire, or equivalent) before onboarding critical vendors and annually thereafter; contractual security and confidentiality terms; vendor offboarding procedure. | Vendor inventory with classification; completed vendor reviews for sampled critical vendors; signed agreements with security clauses. |
Availability Criteria (A1.1 to A1.3)
Availability is the most commonly added optional category, because customers of hosted software care whether the service is up. It does not require a specific uptime percentage. It requires that you manage capacity, protect the environment, and be able to recover. Include it when your contracts contain uptime commitments or your customers' vendor questionnaires ask about them.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| A1.1 | The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and enable additional capacity. | Capacity and performance monitoring with alert thresholds; autoscaling or documented capacity planning review; quarterly capacity review. | Monitoring dashboards; alert configuration; capacity review notes. |
| A1.2 | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure. | Automated daily backups with encryption and offsite or cross-region copies; backup monitoring and failure alerts; environmental controls inherited from cloud provider. | Backup job logs; backup configuration; provider SOC 2 report coverage of environmental controls. |
| A1.3 | The entity tests recovery plan procedures supporting system recovery to meet its objectives. | Annual restoration test from backup to a clean environment; DR failover exercise; documented results and corrective actions. | Restoration test records with dates and outcomes; failover exercise report. |
Processing Integrity Criteria (PI1.1 to PI1.5)
Processing Integrity asks whether the system processes data completely, accurately, on time, and with authorization. It is most relevant to payment processors, payroll providers, claims processors, and any platform whose customers rely on calculated outputs. Many software companies skip it because their customers do not ask; financial services clients in the Research Triangle and beyond frequently do.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| PI1.1 | The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications. | Documented data definitions and processing specifications; published product documentation describing inputs, outputs, and limitations. | Specification documents; customer-facing documentation. |
| PI1.2 | The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet objectives. | Input validation and schema enforcement; rejected-record handling and reporting; reconciliation of received versus processed records. | Validation rules; rejection reports; reconciliation records. |
| PI1.3 | The entity implements policies and procedures over system processing to result in products, services, and reporting to meet objectives. | Automated processing jobs with completion monitoring; error handling and alerting; calculation logic covered by automated tests. | Job logs; error reports and resolution; test coverage for processing logic. |
| PI1.4 | The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet objectives. | Output reconciliation to source; delivery confirmation and retry logic; customer-visible processing status. | Output reconciliation records; delivery logs. |
| PI1.5 | The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet objectives. | Database integrity constraints; retention schedule applied to stored data; backup integrity verification. | Schema and constraint documentation; retention configuration; backup verification results. |
Confidentiality Criteria (C1.1 to C1.2)
Confidentiality covers information that is designated confidential by agreement, such as customer business data, source code, or contract terms, as distinct from personal information, which Privacy handles. It is a frequent second category for B2B software companies because it maps directly to the confidentiality clauses in their customer contracts.
| Criterion | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| C1.1 | The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality. | Data classification policy defining confidential categories; tagging or labeling of confidential repositories; access to confidential data restricted by role and logged. | Classification policy; inventory of confidential data stores; access logs or access reports for confidential systems. |
| C1.2 | The entity disposes of confidential information to meet the entity's objectives related to confidentiality. | Retention schedule with automated deletion; customer data deletion on contract termination with confirmation; secure deletion of backups past retention. | Retention configuration; deletion confirmations for sampled terminated customers; backup lifecycle settings. |
Privacy Criteria (18 Criteria Across P1 to P8)
Privacy is the largest optional category and the least commonly included. It applies when your organization collects, uses, retains, discloses, and disposes of personal information under its own privacy notice, and it borrows heavily from the AICPA's Generally Accepted Privacy Principles. Organizations already subject to HIPAA, GDPR, or CCPA sometimes include it to consolidate assurance; many others address personal information under Confidentiality instead. The table groups the 18 criteria by series.
| Series | What It Requires | Example Controls | Typical Evidence |
|---|---|---|---|
| P1.1 Notice | The entity provides notice to data subjects about its privacy practices. | Published privacy notice covering collection, use, retention, disclosure, and disposal; notice reviewed when practices change. | Privacy notice with version history; change review records. |
| P2.1 Choice and Consent | The entity communicates choices available regarding collection, use, retention, disclosure, and disposal, and obtains consent where required. | Consent capture at collection points; preference management; consent records retained. | Consent flow screenshots; consent database records for sampled users. |
| P3.1 to P3.2 Collection | Personal information is collected consistent with objectives, and explicit consent is obtained for sensitive information. | Data inventory limiting collection to stated purposes; explicit opt-in for sensitive categories. | Data inventory; collection forms; explicit consent records. |
| P4.1 to P4.3 Use, Retention, and Disposal | Personal information is used only for stated purposes, retained only as long as needed, and disposed of securely. | Purpose limitation documented per data element; retention schedule; automated deletion and disposal logs. | Purpose documentation; retention policy and configuration; disposal records. |
| P5.1 to P5.2 Access | Data subjects can access their personal information and request corrections. | Data subject request procedure with identity verification; request tracking and response timelines. | Request log with dates and outcomes; procedure document. |
| P6.1 to P6.7 Disclosure and Notification | Disclosures to third parties are authorized and tracked, third parties are held to privacy commitments, and breaches are notified. | Third-party disclosure inventory; data processing agreements; breach notification procedure; complaint handling process. | Disclosure log; signed agreements; breach notification records or confirmation none required; complaint records. |
| P7.1 Quality | Personal information is kept accurate, complete, and relevant. | Data correction workflow; periodic data quality review. | Correction records; quality review documentation. |
| P8.1 Monitoring and Enforcement | The entity monitors compliance with its privacy commitments and addresses complaints and disputes. | Privacy complaint intake and escalation; periodic privacy compliance review; corrective action tracking. | Complaint log; review results; corrective actions. |
How to Choose Which Trust Services Categories to Include
Scope is the single decision that most affects the cost and effort of a SOC 2 examination, and it is decided before any control is written. Security is not a choice; it is in every report. The four optional categories should be chosen based on what you have promised customers and what they are asking for in security questionnaires, not on what looks impressive on a trust page.
Start with your contracts
Read your master services agreement, SLA, and data processing terms. If they promise uptime, Availability belongs in scope. If they contain confidentiality clauses specific to customer data, Confidentiality does. If they commit to accurate processing of transactions, Processing Integrity does. The criteria should cover the commitments you have already made.
Read the questionnaires you keep receiving
Vendor risk questionnaires reveal what your buyers' security teams actually evaluate. If every questionnaire asks about backups and disaster recovery, Availability will pre-empt those questions. If few ask about personal data handling, Privacy may be unnecessary for your first report.
Consider Security-only for a first report
A Security-only Type 1 followed by a Type 2 is a common path for startups pursuing SOC 2. It establishes the 33 common criteria and the evidence habits behind them, and categories can be added in the next period once the foundation is stable.
Know what each addition costs
Each category adds criteria, controls, evidence, and audit hours. Availability adds three criteria and leans on controls you likely already have. Privacy adds eighteen and usually requires new processes. Choose deliberately, and read our SOC 1 vs SOC 2 comparison if your customers' auditors care about financial reporting rather than security.
How SOC 2 Common Criteria Map to NIST 800-171, HIPAA, and ISO 27001
Organizations rarely face a single framework. A Raleigh software company might need SOC 2 for commercial customers, NIST SP 800-171 and CMMC Level 2 for a defense contract, and the HIPAA Security Rule for a healthcare client. The good news is that well-designed controls satisfy multiple frameworks at once. The mapping below is intentionally high-level; the exact correspondence depends on how each control is written, and the mappings are described as "commonly maps to" for that reason. Craig Petronella's CMMC 2.0 Certification Guide covers the NIST 800-171 side of this mapping in depth.
| SOC 2 Series | NIST 800-171 / CMMC Level 2 | HIPAA Security Rule | ISO 27001:2022 Annex A |
|---|---|---|---|
| CC1 Control Environment | Commonly maps to Awareness and Training (3.2) and Personnel Security (3.9) | Security management process, assigned security responsibility, workforce security | Organizational controls (5.x): policies, roles, segregation of duties; People controls (6.x) |
| CC2 Communication and Information | Commonly maps to Audit and Accountability (3.3) and System and Information Integrity (3.14) | Information system activity review; security awareness and training | 5.x policy communication; 8.15 logging |
| CC3 Risk Assessment | Commonly maps to Risk Assessment (3.11) and Security Assessment (3.12) | Risk analysis and risk management (required implementation specifications) | Clause 6.1.2 risk assessment; 5.7 threat intelligence |
| CC4 Monitoring Activities | Commonly maps to Security Assessment (3.12) and Audit and Accountability (3.3) | Evaluation standard; information system activity review | Clause 9 performance evaluation; 5.35 independent review; 5.36 compliance with policies |
| CC5 Control Activities | Commonly maps to Configuration Management (3.4) and the policy requirements across all 14 families | Policies and procedures; documentation requirements | 5.1 policies; 8.9 configuration management |
| CC6 Logical and Physical Access | Commonly maps to Access Control (3.1), Identification and Authentication (3.5), Physical Protection (3.10), Media Protection (3.8), System and Communications Protection (3.13) | Access control, person or entity authentication, transmission security, facility access controls, device and media controls, encryption | 5.15 to 5.18 access control; 8.2 to 8.5 identity and authentication; 7.x physical controls; 8.24 cryptography |
| CC7 System Operations | Commonly maps to Incident Response (3.6), System and Information Integrity (3.14), Audit and Accountability (3.3) | Security incident procedures; protection from malicious software; audit controls | 5.24 to 5.28 incident management; 8.7 malware protection; 8.8 vulnerability management; 8.16 monitoring |
| CC8 Change Management | Commonly maps to Configuration Management (3.4) | No direct standard; addressed under security management process and evaluation | 8.32 change management; 8.25 to 8.31 secure development |
| CC9 Risk Mitigation | Commonly maps to Risk Assessment (3.11) and System and Communications Protection (3.13) for external connections | Business associate agreements; contingency plan | 5.19 to 5.23 supplier relationships; 5.29 to 5.30 business continuity |
If you are pursuing more than one framework, design each control once and tag it to every requirement it satisfies. That approach is the basis of the CMMC and HIPAA compliance work Petronella Technology Group performs alongside SOC 2, and it is how the ComplianceArmor platform organizes evidence so a single access review record can support a SOC 2 auditor, a C3PAO, and a HIPAA risk analysis at the same time.
Common SOC 2 Control-Design Mistakes
Many exceptions in first-year SOC 2 reports are caused by control design and evidence habits rather than missing technology. They are caused by controls that were written badly, operated inconsistently, or could not be proven. These are the patterns that show up repeatedly in readiness work.
Copying a vendor's control library wholesale. A control template written for a much larger company will include controls you cannot operate. Every control you list is a control the auditor will test, and an untested or unperformed control becomes an exception. Write fewer controls that you actually perform.
Writing controls with no frequency, owner, or evidence. "Access is reviewed periodically" is not testable. "The IT manager reviews all production and administrative accounts quarterly, records the review in the ticketing system, and removes unneeded access within five business days" is.
Letting policies and practice diverge. If the password policy says 14 characters and the identity provider enforces 8, the auditor will note it. Policies should describe what the systems actually do, and when systems change, policies must follow.
Starting evidence collection after the review period begins. A Type 2 report tests the entire period. If quarterly access reviews began in month four of a twelve-month period, there is a gap the auditor must report. Controls should be operating and producing evidence before the period starts.
Ignoring subservice organizations. Cloud providers, payroll processors, and managed service providers perform controls on your behalf. Your system description must state whether they are carved out or included, and you must obtain and review their SOC 2 reports. Forgetting this leaves CC6.4, CC9.2, and A1.2 under-supported.
Treating security awareness as a one-time event. CC1.4 and CC2.2 expect training to be recurring and tracked. Annual security awareness training with simulated phishing produces completion reports and click-rate data that serve as evidence all year.
Assuming the auditor will tell you what to fix. The CPA firm's independence rules prevent it from designing your controls. Remediation guidance comes from a readiness partner, which is why the comparison below separates the two roles.
As Craig Petronella writes in How Hackers Can Crush Your Business, attackers target the gap between what a small business believes it has secured and what it has actually verified. SOC 2 control design is the discipline of closing that gap on paper and then proving it with evidence.
Turn This Criteria List Into Your Control Set
Petronella Technology Group takes the 61 criteria on this page and produces the deliverables an auditor expects: a scoped control matrix written for your actual environment, the policies and procedures behind each control, and an evidence calendar loaded into ComplianceArmor® so nothing is reconstructed at fieldwork. Serving Raleigh, Durham, Chapel Hill, Cary, and clients nationwide since 2002.
DIY vs Audit Firm Only vs Managed Readiness
There are three ways to get from this criteria list to a signed report. Each is legitimate. The difference is who does the control design, who collects the evidence, and how much of the auditor's fieldwork turns into surprises.
| Dimension | Do It Yourself | Audit Firm Only | Petronella Technology Group Managed Readiness |
|---|---|---|---|
| Control design | Internal team interprets each criterion and writes controls, often from a template | Auditor cannot design controls for you under independence rules; you arrive with what you have | Controls written with you for your environment, mapped to each criterion in scope and to any other frameworks you face |
| Gap analysis | Self-assessed; blind spots are common in CC3, CC4, and CC9 | Gaps surface as exceptions in the report | Readiness assessment identifies gaps before fieldwork with a prioritized remediation plan |
| Evidence collection | Manual, usually assembled in the weeks before the audit | Requested by the auditor; you produce it on demand | Evidence calendar and automated collection in ComplianceArmor® throughout the review period |
| Technical controls | Sourced and operated separately: EDR, logging, scanning, pen testing | Not provided | Available as integrated services: Managed XDR Suite, 24/7 SOC, penetration testing, security awareness training, vCISO |
| Policy library | Written from scratch or adapted from templates | Not provided | Policies and procedures drafted to match your actual systems and reviewed annually |
| Auditor interaction | You field every request and clarification | Direct, with no intermediary | Petronella coordinates evidence requests and clarifications alongside your team |
| Between reports | Controls often lapse until the next audit approaches | No engagement between fieldwork periods | Continuous monitoring and bridge letter support between review periods |
| Best fit | Mature security teams with prior SOC 2 experience | Organizations that already have a readiness partner or internal compliance staff | SMBs pursuing a first report or expanding scope without a dedicated compliance team |
How Petronella Technology Group and ComplianceArmor Support Control Design and Evidence
Petronella Technology Group was founded in April 2002, has held a BBB A+ rating since 2003, and is a CyberAB Registered Provider Organization (RPO #1449). Headquartered at 5540 Centerview Dr. in Raleigh, North Carolina, the firm serves Durham, Chapel Hill, Cary, the Research Triangle, and clients nationwide. SOC 2 readiness work is led by Craig Petronella, CMMC Registered Practitioner, NC Licensed Digital Forensics Examiner (License 604180-DFE), MIT-certified in cybersecurity, and author of 15 books on cybersecurity and compliance.
- Scoping workshop to select Trust Services categories based on your contracts and customer questionnaires
- Control matrix written for your environment, with frequency, owner, and evidence defined for every control
- Policy and procedure drafting that matches what your systems actually enforce
- Gap analysis against all criteria in scope with a prioritized remediation plan
- Technical remediation through Managed XDR Suite, 24/7 SOC, penetration testing, and security awareness training with simulated phishing
- vCISO oversight to satisfy CC1.2 and CC1.3 for organizations without a security executive
- SOC 2 module organized by criterion, so every control and its evidence sits under the criterion it supports
- Evidence calendar that schedules recurring controls (access reviews, backup tests, vulnerability scans) and tracks completion through the review period
- Continuous monitoring of configuration controls with alerts when a control drifts
- Gap analysis dashboards showing which criteria are fully evidenced and which need attention
- SSP generator and shared evidence library for organizations also pursuing CMMC, HIPAA, or PCI DSS
- Auditor-ready export of controls, policies, and evidence for fieldwork
"Petronella's work has been a major factor in our business success, helping it to become one of the most secured networks of its kind on the Internet."Financial Services Firm, Raleigh, NC
Petronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews. For the readiness process in sequence, see the SOC 2 compliance checklist; for what the Type 2 examination itself involves, see SOC 2 Type II certification; for ongoing advisory support, see SOC 2 consulting.
SOC 2 Controls List: Frequently Asked Questions
How many SOC 2 controls are there?
SOC 2 does not define a fixed number of controls. It defines 61 Trust Services Criteria: 33 Common Criteria for Security, which are mandatory, plus 3 for Availability, 5 for Processing Integrity, 2 for Confidentiality, and 18 for Privacy, which are optional. Each organization writes its own controls to meet the criteria in its scope. A small company with a Security-only report typically operates a smaller control set than a larger organization that includes several categories; the count depends on how controls are written and grouped. The number that matters is whether every criterion in scope is addressed by at least one control you can prove.
Is there an official AICPA SOC 2 controls list I can download?
No. The AICPA publishes the Trust Services Criteria (the 2017 edition with points of focus revised in 2022), which describe outcomes and considerations, not controls. Any downloadable "SOC 2 controls list" is a vendor's or consultant's interpretation of how to satisfy the criteria. These lists can be useful starting vocabulary, but your auditor tests the controls you document in your system description, not the ones in someone else's template.
Which SOC 2 criteria are mandatory?
The Security category, also called the Common Criteria, is included in every SOC 2 report. It contains 33 criteria across nine series: CC1 Control Environment, CC2 Communication and Information, CC3 Risk Assessment, CC4 Monitoring Activities, CC5 Control Activities, CC6 Logical and Physical Access Controls, CC7 System Operations, CC8 Change Management, and CC9 Risk Mitigation. Availability, Processing Integrity, Confidentiality, and Privacy are optional and are added based on the commitments you make to customers.
What is the difference between a criterion, a point of focus, and a control?
A criterion is a required outcome defined by the AICPA, such as CC6.1 on logical access security. A point of focus is a consideration the AICPA lists under each criterion to help auditors and organizations evaluate whether the criterion is met; points of focus are guidance, not requirements, and not every one must apply. A control is a specific activity your organization performs, such as a quarterly access review documented in a ticket, that provides evidence the criterion is met. Auditors test controls, evaluate them against criteria, and use points of focus as a lens.
Do SOC 2 Type 1 and Type 2 reports use the same criteria?
Yes. Both report types evaluate the same Trust Services Criteria and the same controls. The difference is what the auditor tests. A Type 1 report evaluates whether controls are suitably designed as of a specific date. A Type 2 report also tests whether those controls operated effectively over a review period, commonly 3 to 12 months, which means the auditor samples evidence from throughout the period rather than examining design alone.
Can one control satisfy multiple SOC 2 criteria?
Yes, and well-designed control sets rely on this. A quarterly user access review can support CC6.2 and CC6.3. A centralized logging and alerting platform can support CC2.1, CC7.1, and CC7.2. Annual security awareness training can support CC1.4 and CC2.2. Mapping each control to every criterion it addresses reduces the total number of controls you must operate and makes the audit more efficient. The same approach extends across frameworks: a single control can be tagged to a SOC 2 criterion, a NIST 800-171 requirement, and a HIPAA Security Rule standard.
What evidence do SOC 2 auditors ask for most often?
The most frequently requested evidence includes user access review records, new hire and termination lists reconciled to account provisioning and deprovisioning, multi-factor authentication configuration, a sample of change tickets or pull requests showing review and approval, vulnerability scan and penetration test reports with remediation tracking, backup job logs and restoration test results, security awareness training completion reports, the risk assessment and risk register, vendor review records for critical third parties, incident logs, and signed policy acknowledgments. Collecting these continuously, rather than reconstructing them before fieldwork, is the single largest factor in a smooth examination.
Does Petronella Technology Group perform the SOC 2 audit?
No. SOC 2 reports are issued by independent licensed CPA firms, and auditor independence rules prevent the same firm from both designing your controls and auditing them. Petronella Technology Group provides the readiness side: scoping, control design, policy drafting, gap analysis, technical remediation, and evidence collection through the ComplianceArmor platform. We then support your team through fieldwork with the CPA firm you select. Call 919-348-4912 or schedule a free consultation to discuss your scope.
Related SOC 2 and Compliance Pages
SOC 2 Compliance Services
→SOC 2 Compliance Checklist
→SOC 2 Type II Certification
→SOC 2 Readiness Assessment
→SOC 2 for Startups
→SOC 2 Bridge Letter
→SOC 1 vs SOC 2
→ComplianceArmor® Platform
→Last Updated: October 24, 2026 (first published October 24, 2026). This page describes the AICPA Trust Services Criteria (2017, with points of focus revised in 2022) as applied in SOC 2 examinations. Example controls and evidence reflect common practice for small and mid-sized service organizations and are not a substitute for the control set your own system description defines. Framework mappings are approximate and depend on how each control is written. Written by Craig Petronella, CMMC Registered Practitioner, North Carolina Licensed Digital Forensics Examiner, and author of How Hackers Can Crush Your Business and the CMMC 2.0 Certification Guide.
Get a Control Set Built for Your Auditor
Petronella Technology Group has prepared regulated businesses for compliance examinations since 2002, holds a BBB A+ rating dating to 2003, and is a CyberAB Registered Provider Organization. Bring us the criteria you need to meet and we will return the controls, policies, and evidence to meet them.
5540 Centerview Dr., Suite 200
Raleigh, NC 27606
919-348-4912
info@petronellatech.com