SOC 2 Security Controls (2026): CC6 & CC7 Explained

SOC 2 security controls are the controls you design to meet the AICPA's Security Common Criteria, CC1 through CC9. CC6 covers logical and physical access, and CC7 covers detecting, evaluating, and responding to security events. The Common Criteria apply to every SOC 2 report, and nearly every report includes Security as a category. Common implementations include MFA, role-based access with periodic reviews, vulnerability management, centralized logging, and a tested incident-response plan; the criteria do not mandate a specific tool such as a SIEM.

What Are SOC 2 Security Controls?

The AICPA publishes the 2017 Trust Services Criteria with revised points of focus (2022). The criteria set the objectives; your controls explain how your system meets them. For example controls and evidence under all 33 Common Criteria, see our criterion-by-criterion SOC 2 controls library and Trust Services Criteria scope guide.

The IDs on this page follow those criteria, which reports use today. On 26 October 2026 the AICPA released an exposure draft of proposed 2027 criteria, which is not yet in force. If the AICPA issues it as final, it applies to engagements beginning on or after 31 December 2027, with early implementation permitted, and it renumbers these areas: access moves to CC5, system operations (monitoring and incident response) to CC6, and change management to CC7. See what the proposed 2027 criteria change.

CC6 and CC7 answer two practical questions: who can reach the system, and how does the organization detect and respond when something changes or goes wrong? The rest of this page separates each criterion’s objective from implementation examples and evidence an auditor may test.

These are examples, not fixed AICPA requirements. The right control and cadence depend on the risk assessment, system commitments, and population the auditor is testing. The library mapping for CC6 and CC7 names the controls and evidence behind each row.

CC6 — Logical and Physical Access Controls spans eight sub-criteria (CC6.1 through CC6.8). It covers everything from network perimeter defenses to how you manage SSH keys and whether your server room has a badge reader. It enforces least privilege across every layer of your environment.

CC7 — System Operations spans five sub-criteria (CC7.1 through CC7.5). It governs how you detect, evaluate, and respond to security events. Strong access controls do not offset a material monitoring or response gap, but the opinion impact depends on the exception’s nature and extent.

---

What Does CC6 (Logical and Physical Access Controls) Require?

Keep logical access, physical access, and disposal in the same scope inventory. A strong identity-provider configuration does not establish that office badges were revoked or retired equipment was sanitized. If you need policy wording, use the SOC 2 access control policy template.

CC6.1 — Logical Access Security

Objective: Protect information assets through logical access controls. Authentication and access architecture belong here; outside-threat protection is addressed specifically by CC6.6.

Common implementation choices:

• Identity inventory: Record human users, service accounts, software identities, and their owners across in-scope systems. Include access paths that bypass your main identity provider.
• Authentication: Enforce MFA for the user and system populations defined by your risk assessment and policy. Document exceptions and compensating controls. Workload identities need appropriate machine authentication rather than a human MFA prompt.
• Credential protection: Restrict access to secrets, keys, and certificates; keep them out of source repositories and shared messages. Set rotation and revocation rules appropriate to their use.
• Access architecture: Use approved roles, scoped permissions, and segmentation where relevant to restrict access to protected assets. CC6.3 develops the authorization and least-privilege aspect further.

Evidence an auditor may inspect: Identity and asset inventories, authentication enforcement settings, role configurations, secrets-management settings, and records showing exceptions were approved and reviewed. A written MFA rule needs corresponding enforcement evidence.

CC6.2 — User Registration, Authorization, and Removal

Objective: Register and authorize new internal and external users before issuing credentials or granting access, and remove their credentials when access is no longer authorized. This covers users whose access your organization administers. Changes to an existing user’s role fall under CC6.3.

Common implementation choices:

• Access request workflow: Route each new user (employee, contractor, or vendor) through a documented request and approval before access is granted. Use a record that preserves the requester, authorized approver, access scope, and approval time. The evidence matters more than the ticketing product.
• Onboarding checklist: HR triggers access provisioning for new employees, and IT provisions by role rather than by ad hoc request. Keep the completed checklist as evidence.
• Least privilege by default: New accounts start with minimal access, and elevated permissions go through a separate, documented request.
• Contractor and vendor access: Define an owner, authorized scope, and end-of-engagement revocation process. Use expiry or review controls appropriate to the risk. Include employees and external users in offboarding evidence.

Evidence an auditor may inspect: A sample of new-user provisioning tickets from the period, each showing approval by an authorized approver (often the user’s manager or the system owner) and an account created after that approval, not before. Sample size is the auditor’s judgment, based on population size and risk. In a Type 2 examination the sample spans the whole observation period, not just recent months.

CC6.3 — Role-Based Access with Appropriate Permissions

Objective: Authorize, modify, and remove access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to least privilege and segregation of duties. This is the design and maintenance of your permission model.

Common implementation choices:

• Documented role definitions: Document the permissions for each role (for example, “Developer,” “Support Engineer,” “Finance”). Auditors usually compare the documented permissions with the actual permissions in your IAM system.
• Periodic access reviews: The points of focus describe periodic review of access roles and rules but set no frequency. Define a review cadence from system risk, contractual commitments, and your policy. Keep the population, reviewer, decisions, date, and completed remediation as evidence.
• Segregation of duties (SoD): Separate roles whose combination creates a conflict of interest. For example, the same person should not be able to both approve financial transactions and execute them, and in engineering the developer who writes code should not be the only person who approves it for production.
• Privileged access management (PAM): Limit admin and root-level access to named individuals with a documented business need. Auditors ask for named admin accounts and a documented reason for any account that is shared.

Evidence an auditor may inspect: Role definitions with a permissions matrix, access review records for each in-scope system (with dates, reviewer names, and sign-off), IAM exports showing current user-to-role assignments, and records of access removed for departed employees, which overlaps with CC6.2.

A CC6.3 gap to check before fieldwork: access reviews performed once and never repeated, or review records that show a user list was confirmed but not that actual permissions were evaluated.

CC6.4 — Physical Access Restricted to Authorized Personnel

Objective: Restrict physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel.

A cloud provider may operate the data-center physical controls. Identify which facilities and assets it covers, which responsibilities your organization retains, and how the provider is treated in your report scope. Your own offices, equipment, and storage locations still need appropriate controls.

Common implementation choices:

• Provider assurance review: Review relevant provider assurance evidence for scope, period, physical controls, exceptions, and customer responsibilities. Record the review and follow-up actions. Possessing a provider report does not automatically satisfy CC6.4 for your whole system.
• Office physical access: Badge readers or key card access for office entry (or documented visitor policy if your office lacks electronic controls). Visitor logs for any data-center-equivalent space.
• Server room / network closet controls: If you keep server or networking equipment on premises, a common choice is a locked room with an entry log and a periodic review of who holds access. Some teams add camera coverage.
• Clean desk / screen lock policy: Documented policy requiring screen locks and no sensitive data left unattended. Auditors may ask about this during interviews.

Evidence an auditor may inspect: The current SOC 2 report of each relevant cloud or hosting provider with your review of its physical security controls, office access control documentation or badge access logs, the visitor policy or visitor log, and the physical security policy.

CC6.5 — Asset Disposal and Media Sanitization

Objective: Keep physical assets protected until data and software that no longer need to remain recoverable have been made unreadable before protections are discontinued. This addresses equipment disposal or transfer, rather than MFA or password settings.

Common implementation choices:

• Disposal inventory: Identify laptops, drives, removable media, servers, and leased equipment scheduled for reuse, return, sale, or destruction. Link each asset to its custodian and disposal decision.
• Sanitization procedure: Choose a method suited to the media and data classification, such as verified erasure or destruction. Confirm retention requirements before removing data.
• Verification and custody: Record the asset identifier, method, date, performer, and verification result. Retain a disposal-vendor record or destruction certificate when that is part of your process.
• Provider responsibilities: Establish how a hosting or disposal provider handles relevant assets and what evidence supports that responsibility. Cover company-owned devices separately.

Evidence an auditor may inspect: Asset retirement records, disposal approvals, sanitization results, custody records, and relevant provider assurance evidence. A disposal invoice alone may not establish that the specific asset was sanitized.

CC6.6 — Protection Against Threats Outside System Boundaries

Objective: Protect the system from outside threats. A third-party account inventory supports access management, but does not by itself demonstrate boundary protection.

Common implementation choices:

• External access-point inventory: Document public endpoints and approved remote-access paths in the system architecture.
• Boundary restrictions: Configure firewall rules, security groups, application protections, or equivalent controls appropriate to each exposed service. Document why permitted traffic is needed.
• Protected remote access: Use authenticated, restricted access paths, such as VPN or zero-trust access where suitable. The criterion does not require one specific product or connection method.
• Monitoring and review: Review boundary configurations on your defined cadence and after relevant changes; investigate suspicious traffic through the CC7 monitoring and response process.

Evidence an auditor may inspect: Network diagrams, approved rule sets and review records, remote-access settings, configuration changes, and boundary alerts with follow-up. Vendor and contractor authorization also belongs in the CC6.1–CC6.3 lifecycle.

CC6.7 — Restricted to Authorized Users for Transmission

Objective: Restrict the transmission, movement, and removal of information to authorized internal and external users and processes, and protect it during transmission, movement, or removal.

Common implementation choices:

• TLS/SSL in transit: Encrypt customer data in transit using protocols supported by your security policy and risk assessment. TLS 1.2 or later is a common baseline in 2026, but the TSC does not prescribe a protocol version. Auditors may inspect certificates and endpoint configuration. Our SOC 2 encryption requirements guide covers the at-rest and in-transit evidence.
• Email encryption policy: A common rule is that sensitive data never goes by unencrypted email. Document the rule and, where technically feasible, implement DLP controls to enforce it.
• Encrypted data transfers: Send files containing customer or other sensitive data over SFTP, HTTPS, or an equivalent encrypted protocol. Plain FTP for that data is an exception if one of your controls requires encrypted transfer. If no control covers that path, the auditor may conclude that CC6.7’s protection during transmission is not met.
• Data loss prevention (DLP): For organizations handling highly sensitive data, DLP controls detect and block unauthorized transmission of sensitive data outside the organization.
• Removable media policy: Document controls over USB drives and removable storage. Some organizations prohibit removable media for production data.

Evidence an auditor may inspect: TLS certificate and configuration evidence for customer-facing endpoints, email and data-transfer policy documentation, and DLP policy or tool configuration where you use DLP.

CC6.8 — Managing Malicious Software Threats

Objective: Implement controls to prevent or detect and act upon the introduction of unauthorized or malicious software. Vulnerability scanning and patching sit under CC7.1.

Common implementation choices:

• Anti-malware or EDR: The points of focus name antivirus and anti-malware software on servers and endpoints. An endpoint detection and response (EDR) tool such as CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint is one way to meet this. Auditors usually ask for a coverage export listing each managed device with the agent enrolled.
• Endpoint management (MDM): A Mobile Device Management (MDM) tool (Jamf, Intune) can enforce security baselines such as disk encryption (FileVault, BitLocker), screen lock, and automatic updates. Document how software restrictions, detection, and remediation cover your managed devices. Encryption and screen-lock evidence alone do not show malicious-software protection.
• Restricted software installation: Limit who can install or modify software, as the points of focus describe. On production servers, one approach is to run only approved software; container platforms can enforce this by verifying signed images (for example, with Sigstore or Notation).

Evidence an auditor may inspect: An enrollment report from the malware protection tool (each endpoint, enrollment date, last check-in), malware alert records with the outcome of each, and an MDM compliance report where device baselines are part of your control.

---

What Does CC7 (System Operations) Require?

CC7.1 — Detection and Monitoring Procedures

Objective: Use detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.

Common implementation choices:

• Configuration standards and drift detection: Define hardening standards for in-scope systems and alert when production configuration drifts from the approved baseline, for example with infrastructure-as-code (Terraform, CloudFormation) drift detection.
• Vulnerability scanning: The points of focus describe periodic scans and scans after significant changes, with timely remediation, but set no frequency. Set one from your risk assessment and policy. Qualys, Tenable, and Wiz are examples of scanners.
• Patch management: Set remediation deadlines by severity in a documented policy, and track each finding or patch to closure against them. The criteria do not set the deadlines.

Evidence an auditor may inspect: The hardening standard, dated scan reports covering the in-scope systems, and a sample of remediation tickets or scan findings from the period, checked against the deadlines in your policy.

CC7.2 — Monitoring for Anomalies and Indicators of Compromise

Objective: Monitor system components and the operation of those components for anomalies that indicate malicious acts, natural disasters, and errors affecting your ability to meet your objectives, and analyze anomalies to determine whether they represent security events.

Common implementation choices:

• Centralized logging: Send security-relevant logs from in-scope systems (cloud accounts, identity provider, application, endpoints) to a central log store or SIEM. The criteria do not require a SIEM. Auditors check that log sources cover the in-scope systems and that retention reaches back to the start of the period they test.
• Log aggregation and retention policy: Define what is logged, where it is stored, and for how long. Retention should cover the audit period and your incident-investigation needs; hot/cold tiers are an implementation choice, not an AICPA rule.
• Actionable alerting: A SIEM or other monitoring stack should surface security-relevant events rather than only store logs. Examples include failed-login thresholds, privilege escalation, unusual access patterns, and configuration changes.
• Behavioral analytics / anomaly detection: Some teams add behavioral or machine-learning detection on top of rule-based alerts to flag deviations from normal patterns: unusual data egress volumes, access at atypical hours, logins from new geographies.
• Alert tuning and review: Review and tune alert rules periodically and keep a record. Thousands of untriaged alerts a day give an auditor little evidence that anomalies are analyzed.
• On-call rotation: Define an on-call rotation with documented coverage and a target time for an alert to reach a person. A paging tool’s rotation schedule (PagerDuty or equivalent) is the usual evidence.
• Cloud provider threat detection: Amazon GuardDuty, Microsoft Defender for Cloud, and Google Cloud Security Command Center use threat intelligence to flag activity such as traffic from known malicious IP addresses. If you enable one, route its findings into your alerting workflow.

Evidence an auditor may inspect: A list of log sources compared with the system inventory, the retention policy and settings, a sample of high-priority alert rules, the on-call schedule and escalation policy, and alert records with triage notes from the period, including any incident tickets raised from alerts.

CC7.3 — Evaluation of Security Events

Objective: Evaluate security events to determine whether they could or did cause a failure to meet your objectives (a security incident) and, if so, act to prevent or address that failure.

This sub-criterion covers triage and classification — the bridge between detection (CC7.2) and response (CC7.4).

Common implementation choices:

• Incident classification criteria: A documented definition of a security incident, often tiered by severity (for example, P1/Critical, P2/High, P3/Medium). Written criteria give the auditor a standard to test your classifications against.
• Triage workflow: A defined process for investigating an alert: initial assessment, escalation criteria, who gets notified at each severity level. This can be embedded in your incident response plan or maintained as a runbook.
• Ticket tracking: Track security events that need evaluation in a ticketing system (Jira, ServiceNow, PagerDuty), with timestamps showing when each was detected, triaged, classified, and resolved. Auditors usually sample these records from the period.
• Regular security review meetings: Communicating detected events to the people who run the security program is a point of focus. A recurring review meeting, with notes or agendas, is one way to show it.

Evidence an auditor may inspect: The incident classification criteria, the triage section of the incident response plan, a sample of event and incident tickets from the period with classification, timestamps, and resolution, and notes from security review meetings where you hold them.

CC7.4 — Response to Security Incidents

Objective: Respond to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate.

Common implementation choices:

• Incident Response Plan (IRP): The criterion calls for a defined program, and a written plan is the usual way to show one. A common plan covers roles and responsibilities, internal escalation and external customer notification thresholds, containment and eradication procedures, and post-incident review. Auditors usually check its last review date against the cycle your policy sets. If Privacy is in scope, the CC7.4 privacy points of focus include defining and applying breach response procedures for confirmed privacy incidents.
• Incident-response exercise: The points of focus include evaluating the response program’s effectiveness periodically. A tabletop exercise on the cadence your commitments and risk assessment support is one way to do it. Keep the scenario, participants, findings, and resulting plan changes.
• Communication templates: Pre-approved templates for customer breach notifications, regulatory notifications, and internal escalations. Having these ready reduces time-to-notification during an actual incident.
• Forensics capability: A documented process for preserving evidence when an incident needs investigation: log preservation, disk imaging procedures, chain of custody. Smaller organizations can rely on an external forensics retainer.
• Post-incident review (PIR): After any significant security incident, conduct and document a root cause analysis and corrective action plan. The points of focus include reviewing incidents for patterns and root causes that call for system changes.

Evidence an auditor may inspect: The current IRP with its last-reviewed date, exercise records (date, participants, scenario, findings), a sample of incident tickets showing the plan was followed, and post-incident reviews for any incidents during the period.

CC7.5 — Recovery from Security Incidents

Objective: Restore operation after identified security incidents and address the conditions that allowed them. Detection, triage, and immediate incident response sit in CC7.1–CC7.4; CC7.5 focuses on recovery.

Common implementation choices:

• Recovery procedures: Define who can rebuild or restore affected systems, validate their integrity, and approve a return to service.
• Recovery exercises: Test relevant incident scenarios on a cadence chosen from risk and commitments. Record results and remediate failed steps.
• Root-cause and corrective actions: Record the cause, assign owners for preventive changes, and track completion.
• Lessons and communications: Update response and recovery procedures after incidents or exercises, and communicate recovery status to the appropriate stakeholders.

Evidence an auditor may inspect: Recovery runbooks, restoration and validation results, exercise records, post-incident reviews, and completed corrective-action tickets. Breach notification can be an incident-response obligation, but a notification policy alone is not recovery evidence.

---

Which library controls and evidence map to each CC6 and CC7 criterion?

The SOC 2 controls library holds 82 example controls across all criteria. The table below lists the ones mapped to CC6 and CC7. Control IDs do not change once issued. These are our example controls, not AICPA requirements, and your risk assessment decides what you run.

The middle column shows where one control does double duty. AC-06 supports CC6.2 and CC6.3, and AC-07 supports CC6.1 and CC6.3. NS-02 and AC-09 each support CC6.1 and CC6.6, EP-01 and EP-03 support CC6.1 and CC6.8, LG-02 supports CC7.2 and CC7.3, and IR-02 and IR-03 support CC7.4 and CC7.5. A missed AC-06 review therefore leaves the evidence for two criteria incomplete.

The mapping is also uneven. CC6.1 draws on controls for authentication, secrets, privileged access, inventory and encryption, while in our mapping CC7.3 rests on LG-02 alone. If alerts reach a channel nobody owns, there is no triage record and no second control behind that criterion.

To size the population and sample for any row, see how SOC 2 Type 2 controls are tested and how auditors decide sample size. Policy wording for CC6.1 to CC6.3 is in the access control policy template, and CC8 sits on the change management controls page.

---

What Are the Most Common Exceptions in CC6 and CC7?

This table is a readiness checklist, not a claim about exception frequency or opinion outcome.

---

What Changes When You Use a SOC 2 Software Tool?

A compliance platform can collect evidence, show failed tests, and coordinate access reviews. It does not decide whether a control is suitable or whether the evidence is sufficient. In its FAQ on the effect of software tools on SOC 2 examinations, first issued in 2021, the AICPA describes these tools as designed to improve the efficiency of preparing for and undergoing an examination, and says a tool does not change the service auditor’s responsibilities.

For CC6 and CC7, that distinction has practical consequences:

• Confirm that each integration covers the full in-scope population, not just the systems that were easy to connect.
• Validate that imported data is complete and accurate before treating a green test as audit evidence.
• Expect the auditor to inspect evidence outside the platform and to apply independent judgment to scope, sampling, and exceptions.
• Ask how any commercial relationship between the tool provider and CPA firm is disclosed and how the firm protects its independence.

The tool shortens collection and coordination. Management still owns the controls, and the CPA firm still owns the examination opinion.

---

How Do CC6 and CC7 Connect to the Other Common Criteria?

CC6 and CC7 form the operational core of the Security criterion, but they do not stand alone. Understanding their dependencies prevents gaps at the boundaries.

CC1 — Control Environment: CC1 establishes governance: organizational structure, board oversight, commitment to competence, and accountability. A weak CC1 (no CISO or security owner, no documented organizational security commitment) undermines auditor confidence in CC6 and CC7 controls, because those controls require human ownership and oversight to operate consistently.

CC3 — Risk Assessment: CC6 and CC7 controls should trace to your risk assessment. CC3.2 requires you to identify risks to your objectives and analyze them as the basis for deciding how to manage them, and its points of focus include assessing likelihood and impact. Auditors may ask: “How did you determine that quarterly access reviews (CC6.3) are the right frequency?” The answer should reference your risk assessment. An undocumented risk methodology makes CC6/CC7 controls look arbitrary.

CC8 — Change Management: CC8 governs how changes to infrastructure, software, and configurations are authorized and implemented. It is a direct operational complement to CC6 and CC7. CC6 controls what exists in your environment; CC8 controls how it changes; CC7 monitors for unexpected changes. A finding in CC8 (e.g., unauthorized deployments to production) creates a correlated finding risk in CC7.1 (your monitoring should have detected it) and CC6.3 (who had access to make that change?).

CC9 — Risk Mitigation: Vendor and business-disruption risks can cross several control areas. Vendor permissions connect to CC6.1–CC6.3; exposed connection paths connect to CC6.6. For a vendor-caused incident, your CC7.4 response and CC7.5 recovery procedures should identify responsibilities, communications, and how service will be restored.

For a full overview of all nine Common Criteria series, see our guide to SOC 2 Trust Services Criteria.

---

FAQ

There is no fixed CC6 or CC7 implementation timeline. It depends on your current controls, in-scope systems, remediation work, and evidence needs. Inventory the gaps and assign owners before setting a date. Agree readiness and the Type 2 observation period with your CPA firm; choose review cadences from risk and commitments rather than treating quarterly reviews as a universal rule. If the gap inventory is long, readiness firms can work through it with you before the observation period starts.

Can we use a compliance automation tool (Vanta, Drata, Secureframe) to satisfy CC6 and CC7?

Yes, with caveats. These tools automate evidence collection, connection to your cloud accounts, and access review workflows. They significantly reduce the effort of demonstrating CC6.3 (access reviews) and CC7.2 (log monitoring). They do not replace the controls themselves: whatever you choose for authentication, malware protection, and incident response, your team still has to run it. The tool collects evidence; the controls must actually exist and operate. See our SOC 2 evidence request list for detail on what evidence to prepare.

What is the difference between CC6.1 and CC6.6?

CC6.1 covers logical access security over protected information assets, including authentication and access architecture. CC6.6 specifically addresses threats from outside system boundaries, such as attacks against public endpoints. Some controls support both. Authorized vendor and contractor access is also governed by the CC6.1–CC6.3 access lifecycle.

Do we need a SOC 2 Type 2 report to satisfy CC7.4, or does Type 1 suffice?

A Type 1 report considers control design at a point in time. A Type 2 report also tests operating effectiveness during the review period. If no incident occurred during the period, the auditor confirms that and states in the report that the response control did not need to operate, with no change to the opinion. Exercising the response plan is usually a separate control, which the auditor tests either way.

What counts as “quarterly” for CC6.3 access reviews?

The evidence must match the cadence in your control description. If your policy says quarterly, a 12-month period should normally contain four reasonably spaced review cycles; a January review followed by a December review does not demonstrate quarterly operation. Choose the cadence from risk, then operate and document it consistently.

How detailed does the CC7.3 incident classification need to be?

Detailed enough that the classification criteria are objective and applied consistently. The criteria set no format. One approach is a severity matrix (for example, Critical, High, Medium) with explicit definitions for each tier (the data types, systems, and estimated impact involved) and a worked example for each. The goal is that two different analysts evaluating the same event would classify it the same way.

Is vulnerability scanning required for SOC 2?

Not in the criterion’s own words, but CC7.1 requires detection and monitoring procedures that identify susceptibilities to newly discovered vulnerabilities, and its points of focus include periodic infrastructure and software vulnerability scans, scans after significant changes, and timely remediation. A scanner is the usual way to meet it, and auditors usually ask for scan reports covering the in-scope systems and for remediation tickets set against the deadlines in your policy.

---

Ready to find an auditor for a CC6/CC7-heavy engagement? SOC2Auditors matches you with verified SOC 2 audit firms against your tech stack, timeline, and budget — no sales calls. Find your SOC 2 auditor to shortlist firms, or read our SOC 2 evidence request list to prepare the artifacts auditors test against. To budget the engagement first, see what a SOC 2 audit costs.