SOC 2 Security Controls (2026): CC6 & CC7 Deep-Dive

Quick Answer: CC6 (Logical and Physical Access Controls) and CC7 (System Operations) are the two criteria most commonly cited in qualified SOC 2 opinions. CC6 requires MFA, RBAC, quarterly access reviews, and physical access controls. CC7 requires a SIEM, vulnerability scanning, an incident response plan, and an annual DR test. Together they account for 68% of exceptions found in qualified SOC 2 reports — making them the two criteria every company must get right.

What Are CC6 and CC7? The Heart of SOC 2 Security

The SOC 2 Security criterion — formally known as the Common Criteria — is organized into nine series (CC1 through CC9). While all nine matter, CC6 and CC7 are where audits are won or lost. They cover the two domains that are simultaneously the most technically demanding and the most operationally exposed: who has access to your systems and what is happening inside them at any given moment.

CC6 — Logical and Physical Access Controls spans eight sub-criteria (CC6.1 through CC6.8). It governs everything from network perimeter defenses to how you manage SSH keys and whether your server room has a badge reader. It is the criterion that enforces the principle of 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. A company with strong access controls but no monitoring can still receive a qualified opinion — CC7 ensures you have the operational visibility to know when something goes wrong and a tested process for responding.

This diagram shows how the Security criterion anchors the entire SOC 2 report structure.

The remaining sections go deep on each sub-criterion: what it requires, what controls satisfy it, and what evidence an auditor will actually test.

---

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

CC6 is the largest criterion in the Common Criteria set. Its eight sub-criteria move systematically from the network perimeter inward to endpoints, credentials, and data transmission. Weaknesses at any layer create exposure — and auditors test each one.

CC6.1 — Logical Access Security at the System Boundary

What it requires: The entity implements logical access security measures to protect against threats from sources outside system boundaries. This means your perimeter defenses must be documented, configured, and operating.

Controls that satisfy it:

• Network firewalls with documented rule sets reviewed at least annually. Every open port must have a business justification. Rules permitting broad inbound access (e.g., 0.0.0.0/0 on SSH) are immediate findings.
• Web Application Firewall (WAF) for any customer-facing application. AWS WAF, Cloudflare, or equivalent — configured with OWASP rule sets and logging enabled.
• Intrusion detection/prevention systems (IDS/IPS) or equivalent cloud-native capabilities (AWS GuardDuty, Azure Defender) generating alerts on anomalous traffic patterns.
• Network segmentation separating production from development and corporate environments. A flat network where a compromised developer laptop can reach production databases fails CC6.1.

Evidence auditors test:

• Firewall rule sets with review sign-off (dated within the last 12 months)
• WAF configuration and sample block/alert logs
• Architecture diagram showing network segmentation
• IDS/IPS alert policy documentation and sample alerts

CC6.2 — Restricting New User Access to Authorized Activities

What it requires: New internal and external users’ access is restricted to authorized and necessary activities. This is the provisioning side of the access control lifecycle.

Controls that satisfy it:

• Formal access request workflow: Every new user — employee, contractor, or vendor — must go through a documented request-and-approval process before receiving access. A Jira ticket or ServiceNow workflow with manager approval satisfies this. A Slack message does not.
• Onboarding checklist: HR triggers access provisioning for new employees; IT provisions based on role, not ad-hoc requests. The checklist must be retained as evidence.
• Least privilege by default: New accounts should start with minimal access. Elevated permissions require a separate, documented request.
• Contractor and vendor access: Third parties must have time-limited access that expires automatically or is reviewed on a fixed schedule. Shared credentials fail this criterion.

Evidence auditors test:

• A sample of new user provisioning tickets from the audit period (auditors typically sample 10–25 from a population)
• Evidence of manager approval in each sample ticket
• Proof that accounts were provisioned after — not before — approval
• For Type 2: consistency across the full observation period, not just recent months

CC6.3 — Role-Based Access with Appropriate Permissions

What it requires: Role definitions include appropriate access restrictions. This is the design and maintenance of your RBAC model.

Controls that satisfy it:

• Documented role definitions: Each role (e.g., “Developer,” “Support Engineer,” “Finance”) must have documented permissions. Auditors will compare the documented permissions to the actual permissions in your IAM system.
• Quarterly access reviews: This is the control most commonly missing or most commonly performed inconsistently. At least quarterly, system owners must certify that the users in their system have appropriate access. The review must be documented — a spreadsheet with dates and approver signatures, an export from Vanta or Drata showing completion, or equivalent.
• Segregation of duties (SoD): Roles that create a conflict of interest must be separated. The canonical example: the same person should not have the ability to both approve financial transactions and execute them. For engineering teams: the developer who writes code should not be the only person who approves it for production deployment.
• Privileged access management (PAM): Admin and root-level access must be limited to named individuals with documented business need. Shared admin accounts are a finding.

Evidence auditors test:

• Role definition documentation with 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
• Evidence of terminated employee access revocation (see CC6.2 overlap)

The most common CC6.3 exception: Access reviews that are performed once and never repeated, or reviews performed but not documented with sufficient detail to demonstrate that actual permissions were evaluated (not just list verified).

CC6.4 — Physical Access Restricted to Authorized Personnel

What it requires: Physical access to facilities and protected information assets is restricted to authorized personnel.

For most SaaS companies using cloud infrastructure (AWS, GCP, Azure), the physical access controls are largely inherited from the cloud provider — and auditors accept this when properly documented. However, this criterion still applies to your own offices, where equipment, workstations, and potentially sensitive printouts exist.

Controls that satisfy it:

• Cloud provider SOC 2 reports: Obtain the SOC 2 (or ISO 27001) reports from your cloud provider(s) annually. Document that physical data center security is a subservice organization control. This passes CC6.4 for production infrastructure.
• 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 have on-premise networking equipment, the room must have locked access, a log of entry, and security camera coverage or equivalent.
• Clean desk / screen lock policy: Documented policy requiring screen locks and no sensitive data left unattended. Auditors will ask about this during interviews.

Evidence auditors test:

• Cloud provider SOC 2 report (current year) with physical security controls noted
• Office access control documentation or badge access logs
• Visitor policy or visitor log
• Physical security policy document

CC6.5 — Protection of Logical Access Credentials

What it requires: Logical access credentials are protected (identification, authentication, and authorization mechanisms).

This sub-criterion is where MFA, password policy, and secrets management live. It is among the most-tested criteria in the entire CC series.

Controls that satisfy it:

• Multi-Factor Authentication (MFA): MFA must be enforced — not just available — on all access to production systems, code repositories, cloud consoles, and identity providers (Okta, Azure AD, Google Workspace). Auditors request screenshots of MFA enforcement policies and verify they are configured to prevent bypass. Advisory-mode MFA (where users can skip) is a finding.
• Password policy: Minimum length (12+ characters), complexity requirements, prohibition on reuse of the last 12 passwords. Enforced at the identity provider level, not just documented in a policy.
• Secrets management: Production credentials, API keys, and certificates must not be stored in plaintext — not in code repositories, not in .env files committed to version control, not in Slack. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager). Auditors commonly ask for evidence that secrets rotation is automated or reviewed.
• SSH key management: SSH keys to production servers must be inventoried, attributed to named individuals, and rotated when personnel change. Stale keys belonging to departed employees are a finding.
• Privileged session logging: For privileged access to production, session logging provides an audit trail of what was done.

Evidence auditors test:

• Screenshots of MFA enforcement policy in your identity provider
• Password policy configuration (not just the policy document — the actual system setting)
• Secrets management tool configuration and evidence of use
• SSH key inventory (or equivalent for certificate-based auth)

CC6.6 — Managing Logical Access to Assets Outside System Boundaries

What it requires: Logical access to assets outside the system boundary (including third-party assets and cloud providers) is managed and restricted to authorized users.

Controls that satisfy it:

• VPN for remote access: Remote workers and contractors accessing production environments must use a VPN. Split tunneling configurations should be reviewed — untunneled traffic to production is a gap.
• Third-party access management: Vendors and contractors with access to your systems must be inventoried. Access must be time-limited, scoped to minimum necessary, and revoked immediately upon engagement end.
• Vendor portal and SaaS application inventory: Maintain an inventory of third-party tools with access to customer data or production systems. Each must have a designated owner and an annual review.
• API access control: External API keys must be issued with minimal scope, tracked, and rotated. Wildcard or admin-scope keys issued to third parties are a finding.

Evidence auditors test:

• VPN policy and configuration evidence
• Third-party access inventory with access review records
• Evidence of offboarding for departed contractors
• API key inventory with scope documentation

CC6.7 — Restricted to Authorized Users for Transmission

What it requires: The transmission, movement, and removal of information is restricted to authorized internal and external users and processes.

Controls that satisfy it:

• TLS/SSL in transit: All customer data transmitted over networks must be encrypted in transit. TLS 1.2 minimum; TLS 1.3 preferred. Auditors will check SSL certificates and may run TLS configuration scans against your endpoints.
• Email encryption policy: Sensitive data must not be transmitted via unencrypted email. Document a policy and, where technically feasible, implement DLP controls to enforce it.
• Encrypted data transfers: File transfers containing customer or sensitive data must use SFTP, HTTPS, or equivalent encrypted protocols. FTP is a finding.
• 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. Many organizations simply prohibit use for production data.

Evidence auditors test:

• SSL/TLS certificate and configuration evidence for all customer-facing endpoints
• Email and data transfer policy documentation
• DLP policy or tool configuration (if applicable)

CC6.8 — Managing Malicious Software Threats

What it requires: Controls to prevent or detect and act upon the introduction of unauthorized or malicious software.

Controls that satisfy it:

• Endpoint Detection and Response (EDR): Deploy EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) on all company-managed endpoints. Auditors want evidence of coverage — typically an export showing all managed devices with EDR enrolled.
• Endpoint management (MDM): Use a Mobile Device Management (MDM) tool (Jamf, Intune) to enforce security baselines: disk encryption (FileVault/BitLocker), screen lock, automatic updates. Evidence of compliance vs. non-compliant device count is tested.
• Patch management: Documented policy for applying security patches within a defined SLA (commonly: critical patches within 30 days, high within 60 days, medium within 90 days). Auditors sample specific CVEs published during the audit period and verify they were patched within SLA.
• Software allowlisting or code signing: For production servers, only approved software should execute. Container environments with image signing (Docker Content Trust, Sigstore) satisfy this at the infrastructure layer.
• Vulnerability scanning: Regular scanning of endpoints and production systems using tools like Qualys, Tenable, or Wiz. Scan results and remediation tracking are core evidence.

Evidence auditors test:

• EDR tool enrollment report (all endpoints, enrollment date, last check-in)
• MDM compliance report showing encryption and lock screen enforcement
• Patch management policy with defined SLAs
• Vulnerability scan results with remediation ticket evidence

---

What Does CC7 (System Operations) Require?

CC7 covers the detection and response side of security operations. A company can have perfect access controls and still receive a qualified opinion if it cannot demonstrate that it monitors its environment and responds to threats effectively.

CC7.1 — Detection and Monitoring Procedures

What it requires: The entity uses 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.

Controls that satisfy it:

• SIEM (Security Information and Event Management): Aggregate logs from all critical systems — cloud infrastructure, identity provider, application, endpoints, network — into a centralized SIEM (Splunk, Datadog, Elastic Security, AWS Security Hub). Auditors verify that logs from all in-scope systems flow into the SIEM and that the retention period covers the audit window.
• Log aggregation and retention policy: Define what is logged, where it is stored, and for how long. Minimum retention is typically 90 days hot / 1 year cold. Logs must be tamper-evident (write-once storage or equivalent).
• Alerting configuration: The SIEM must generate alerts, not just store logs. Auditors test that alerts exist for security-relevant events: failed login thresholds, privilege escalation, unusual access patterns, and configuration changes.
• Configuration management / drift detection: Infrastructure-as-code (Terraform, CloudFormation) with drift detection alerts when production configuration diverges from the approved baseline.
• Vulnerability scanning cadence: Regular (at minimum monthly) scanning of production infrastructure. Scan results must be fed into a remediation tracking process.

Evidence auditors test:

• SIEM architecture diagram showing log sources
• Log retention policy documentation
• Sample alert rules with thresholds
• Vulnerability scan schedule and recent scan outputs

CC7.2 — Monitoring for Anomalies and Indicators of Compromise

What it requires: The entity monitors system components and the operation of those controls for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives.

Controls that satisfy it:

• Behavioral analytics / anomaly detection: Beyond rule-based alerting, use machine learning or behavioral baseline tools (AWS GuardDuty anomaly mode, Datadog anomaly monitors, Crowdstrike Falcon Insight) to detect deviations from normal patterns — unusual data egress volumes, access at atypical hours, logins from new geographies.
• Alert tuning and review: Documented evidence that your alert rules are reviewed and tuned periodically. Auditors look for evidence that alerts are actionable — a SIEM generating 10,000 low-fidelity alerts per day with no triage process is a control weakness.
• On-call rotation: Define an on-call rotation with documented coverage. Alerts must reach a human within a defined SLA. Evidence: PagerDuty rotation schedules, or equivalent.
• Cloud provider threat intelligence: AWS GuardDuty, Azure Defender, or GCP Security Command Center provide threat intelligence feeds that surface known malicious IPs and TTPs. These should be enabled and integrated into your alerting workflow.

Evidence auditors test:

• SIEM alert rule configuration (sample of high-priority rules)
• On-call rotation schedule and escalation policy
• Evidence of alert response (incident tickets tied to SIEM alerts during the audit period)
• Threat intelligence feed configuration

CC7.3 — Evaluation of Security Events

What it requires: Security events are evaluated to determine if they should be classified as security incidents.

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

Controls that satisfy it:

• Incident classification criteria: A documented matrix defining what constitutes a security incident, tiered by severity (P1/Critical, P2/High, P3/Medium). Without documented classification criteria, auditors cannot confirm that your team consistently applies the same standard.
• 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: Every security event requiring evaluation must be tracked in a ticketing system (Jira, ServiceNow, PagerDuty) with timestamps showing when it was detected, triaged, classified, and resolved. Auditors sample incidents from the audit period.
• Regular security review meetings: Many organizations hold weekly or biweekly security review sessions to evaluate open findings and trends. Meeting notes or agendas serve as evidence that security events receive structured attention.

Evidence auditors test:

• Incident classification matrix (documented severity tiers)
• Incident response plan (relevant triage section)
• Sample incident tickets from the audit period with classification, timestamps, and resolution
• Evidence of security review meetings (meeting notes or calendar invites with attendance)

CC7.4 — Response to Security Incidents

What it requires: Security incidents are responded to in accordance with incident response policies and procedures.

Controls that satisfy it:

• Incident Response Plan (IRP): A documented IRP is table stakes. It must cover: roles and responsibilities (CSIRT structure), communication plan (internal escalation and external customer notification thresholds), containment and eradication procedures, and post-incident review requirements. Auditors read the IRP and verify it is current (reviewed within the last 12 months).
• Annual IRP tabletop exercise: The IRP must be tested. An annual tabletop exercise (simulated incident walkthrough with the response team) satisfies this requirement. The exercise must be documented: scenario description, participants, findings, and any IRP updates resulting from the exercise.
• 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: At minimum, a documented process for preserving evidence when an incident requires investigation — log preservation, disk imaging procedures, chain of custody. External forensics retainer agreements are acceptable for smaller organizations.
• Post-incident review (PIR): After any significant security incident, conduct and document a root cause analysis and corrective action plan. Auditors look for evidence that incidents drive improvements, not just remediation.

Evidence auditors test:

• Current IRP (with last-reviewed date)
• Annual tabletop exercise documentation (date, participants, scenario, findings)
• Sample incident tickets showing adherence to IRP procedures
• Post-incident review documentation (if any incidents occurred during the audit period)

CC7.5 — Identification of Security Breaches

What it requires: Breaches are identified, and response procedures are executed as appropriate.

This sub-criterion focuses on the output end of the incident pipeline — ensuring that when a genuine breach occurs, it is identified as such and the appropriate notification and remediation procedures are triggered.

Controls that satisfy it:

• Breach notification policy: A documented policy defining what constitutes a reportable breach under applicable regulations (GDPR, CCPA, HIPAA, state breach notification laws), the timeline for customer notification, and the process for regulatory notification. This policy should reference specific regulatory requirements.
• Legal and regulatory mapping: Maintain awareness of the breach notification obligations applicable to your customer base. If you serve EU customers, GDPR’s 72-hour supervisory authority notification window applies. Document how your IRP satisfies these timelines.
• Forensic investigation procedures: Documented procedures for determining the scope of a breach — what data was accessed, by whom, for how long. This includes log analysis procedures and evidence preservation requirements.
• Customer notification templates and triggers: Pre-approved language for customer notifications with defined trigger criteria. Auditors look for evidence that notification criteria exist and that the templates are reviewed.
• Regulatory incident log: A log of any security incidents that were evaluated against breach notification criteria, including the determination made (reportable or not) and the rationale.

Evidence auditors test:

• Breach notification policy (with regulatory references)
• Sample of incident tickets with documented breach/no-breach determination
• Customer notification templates
• Evidence of legal review of notification policy

---

What Are the Most Common Exceptions in CC6 and CC7?

This table shows where qualified opinions and management letter comments most frequently originate across CC6 and CC7.

Sub-Criterion	Most Common Exception	Root Cause
CC6.1	Overly permissive firewall rules; no annual rule review	Rules accumulate over time and are never cleaned up
CC6.2	Access provisioned before approval is documented; contractors with indefinite access	Provisioning driven by urgency, documentation added retroactively
CC6.3	Access reviews performed annually instead of quarterly; reviews lack sufficient detail	Teams treat review as a formality rather than a genuine evaluation
CC6.4	No visitor log; no evidence of cloud provider SOC 2 report reviewed	Physical controls deprioritized; vendor management treated as procurement issue
CC6.5	MFA not enforced (advisory mode); API keys in code repositories	MFA enabled but enforcement not configured; developers bypass secrets management for speed
CC6.6	Departed contractor accounts not revoked; vendor access broader than necessary	No offboarding workflow for non-employees; vendor onboarding lacks scope definition
CC6.7	TLS 1.0/1.1 still enabled on legacy endpoints; no data transfer policy	Legacy systems not upgraded; policy documentation not kept current
CC6.8	EDR not deployed on all endpoints; patches outside SLA	BYOD or unmanaged endpoints excluded from EDR; patch SLA not tracked systematically
CC7.1	Not all log sources ingested into SIEM; log retention below 90 days	SIEM configured for key sources only; cost-driven retention cuts
CC7.2	Alerts configured but no documented on-call; alert fatigue with no tuning evidence	Alerting stood up for compliance but not operationalized
CC7.3	No incident classification criteria; incidents tracked informally in Slack	Response ad-hoc; no documented triage standard
CC7.4	No annual tabletop exercise; IRP not updated in 2+ years	Tabletop deprioritized; IRP treated as a one-time document
CC7.5	No breach determination log; breach notification policy lacks regulatory specifics	Policy exists but regulatory mapping incomplete; determinations not documented

---

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 must be grounded in a formal risk assessment. CC3 requires that you identify threats to achieving your security objectives, assess their likelihood and impact, and use that analysis to design your controls. Auditors will 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: CC9 covers vendor management and business disruption risk mitigation. CC6.6 (managing third-party access) and CC7.4 (incident response for vendor-caused incidents) connect directly to CC9. When a vendor causes a data exposure, CC9 asks whether you had appropriate contractual protections and due diligence; CC7.5 asks whether you identified the breach and notified affected parties. Both criteria are tested in the same fact pattern.

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

---

FAQ

Implementation typically takes 2–4 months for a company starting from scratch. The longest lead items are MDM rollout (requires endpoint agent deployment), SIEM configuration (requires log source onboarding from every system), and establishing quarterly access review cadence (requires process design, tool setup, and three completed review cycles to demonstrate consistency during a 12-month audit period). Plan for 3–6 months before beginning a Type 2 observation period if CC6/CC7 are new.

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.1 (log monitoring). But they do not replace the controls themselves — you still need MFA enforced, EDR deployed, an IRP written, and a tabletop conducted. The tool collects evidence; the controls must actually exist and operate. See our SOC 2 evidence collection guide for detail on what evidence to prepare.

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

CC6.1 covers threats from outside the system boundary — unauthorized external actors trying to get in. CC6.6 covers access by legitimate outside parties who have been granted access — vendors, contractors, and third-party integrations. CC6.1 is about perimeter defense; CC6.6 is about managing who you let through the perimeter.

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

A Type 1 report only requires that your IRP be designed (the plan exists and is reasonable). A Type 2 report requires evidence that you actually followed the IRP when incidents occurred during the observation period, or — if no incidents occurred — that you conducted a tabletop exercise to demonstrate the plan is operationally known to the team. The tabletop exercise is the minimum bar for Type 2 CC7.4 in a period with no real incidents.

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

Auditors look for at least three or four completed review cycles within a 12-month audit period, spaced approximately 90 days apart. A review conducted in January and then not again until December is not quarterly — it is annual with a gap. Start your review cadence before your observation period begins so you have a full four cycles to show.

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

Sufficient to make the classification criteria objective and consistently applied. A three-tier severity matrix (Critical / High / Medium) with explicit definitions for each tier — what data types are involved, what systems, what estimated impact — and a worked example for each tier is typically sufficient. The goal is that two different analysts evaluating the same event would classify it the same way.

Is vulnerability scanning required for SOC 2?

Explicitly under CC7.1 and implicitly under CC6.8. CC7.1 requires detection of susceptibilities to newly discovered vulnerabilities, which requires a scanning cadence. CC6.8 requires management of malicious software threats, which overlaps with patch management driven by vulnerability scan findings. Auditors consistently test for both a scanning tool and evidence that scan findings are tracked to remediation within documented SLAs.

---

Navigating the audit firm selection process for a CC6/CC7-heavy audit is complex. SOC2Auditors provides transparent, data-driven comparisons of over 90 verified audit firms, matched to your tech stack, timeline, and budget — without the sales calls. Visit https://soc2auditors.org to find your auditor with confidence.