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.

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

What it requires: Register and authorize internal and external users before issuing credentials, then remove access when it is no longer authorized. Role-based changes also connect to CC6.3.

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. 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; 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: 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 auditors test:

• A sample of new user provisioning tickets from the audit period (sample size is the auditor’s judgment call based on population size and risk; 10–25 is a commonly observed range)
• 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: Authorize, modify, and remove access according to roles and responsibilities, least privilege, and segregation of duties. This is the design and maintenance of your permission 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.
• Periodic access reviews: Define a review cadence from system risk, contractual commitments, and your policy. Quarterly reviews are common for privileged or production access. Keep the population, reviewer, decisions, date, and completed remediation as evidence.
• 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): 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 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)

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

What it requires: Physical access to facilities and protected information assets is restricted 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.

Controls that satisfy it:

• 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 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 — 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

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: 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: 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. Document how software restrictions, detection, and remediation cover the managed-device population; encryption and screen-lock evidence alone do not demonstrate malicious-software protection.
• 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?

Strong access controls do not compensate for missing monitoring and response evidence. The opinion impact depends on the nature, extent, and materiality of any exception.

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:

• Configuration management / drift detection: Infrastructure-as-code (Terraform, CloudFormation) with drift detection alerts when production configuration diverges from the approved baseline.
• Vulnerability scanning cadence: Scan production infrastructure on the cadence defined by risk and policy, and track findings through remediation. Monthly scanning is common, but not a universal TSC frequency.

Evidence auditors test:

• 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:

• 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. 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: 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 architecture diagram showing log sources
• Log retention policy documentation
• 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 covers triage and classification — 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 required. 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). If you include the Privacy category in scope, the 2022 revised points of focus require the IRP to define and execute breach response procedures specifically for confirmed privacy incidents — not just security incidents.
• Incident-response exercise: Test the IRP on the cadence your commitments and risk assessment support. An annual tabletop is common. 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: 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 — 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 March 2026 FAQ on software tools in SOC 2 examinations, the AICPA describes these tools as a way to improve efficiency — not a replacement for the examination.

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 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: 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.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 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, a documented exercise is one way to show that the response procedure operated; the auditor determines whether that evidence is sufficient for the control as written.

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?

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.

---

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.