SOC 2 CC6.6 — Protection against external threats

What SOC 2 CC6.6 requires

Protection against external threats is one of 8 criteria in the Logical and Physical Access Controls (CC6) series of the Security (Common Criteria) category. Logical access security measures are implemented to protect against threats from sources outside the system boundaries. CC6 is the heaviest-tested series in most SOC 2 reports and the one where exceptions most often appear — expect user access reviews, provisioning and deprovisioning tickets, and configuration exports to be sampled across the full period.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC6.6, gather artefacts such as:

Perimeter firewall and WAF configuration
MFA enforcement for remote and external access
VPN / zero-trust access configuration
Intrusion detection or prevention alerts and tuning records

Points of focus for CC6.6

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC6.6. They are not themselves requirements, but they shape the testing:

External access points to the system are identified and protected.
Additional authentication is required for access originating outside the system boundary.
Protective measures are implemented at the boundary and monitored for effectiveness.
Threats from outside the boundary are considered when designing those measures.

How to implement CC6.6

Enumerate the boundary before defending itThe external attack surface is usually larger than the architecture diagram suggests — forgotten subdomains, legacy VPN endpoints, management interfaces, third-party integrations. An external attack surface review at the start of the period is worth more than tuning what you already know about.
Enforce MFA everywhere external, with no standing exceptionsMFA with exceptions is the most common CC6.6 finding, and the exceptions are almost always service accounts, executives, or a legacy system. Each exception needs a documented compensating control and an expiry date, or it needs to be closed.
Prefer identity-aware access over flat network VPNA VPN that lands users on a flat internal network satisfies the letter of the criterion poorly. Per-application access control gives you both better security and much cleaner evidence.
Tune the perimeter tooling and keep the tuning recordsWAF and IPS running in monitor-only mode with a year of unreviewed alerts is a weak position. Evidence of tuning, and of blocking actually being enabled, is what demonstrates operation.
Include the administrative planesCloud consoles, CI/CD platforms and SaaS admin portals are external access points with high privilege. They are in scope for this criterion and are frequently omitted because they are not thought of as the system.

Common audit findings for CC6.6

What actually gets raised against CC6.6, in rough order of how often it comes up:

MFA enforced for staff but not for service accounts, contractors, or a named legacy application.
Management interfaces reachable from the internet, discovered during testing rather than declared.
WAF deployed in detection-only mode for the whole review period.
Cloud and SaaS administrative consoles excluded from the boundary definition.

Scoping CC6.6

CC6.6 is Common Criteria. It maps closely to ISO 27001 A.8.20 to A.8.22 and to NIST CSF PR.AA and PR.IR, so the evidence is highly reusable. Where a penetration test is already performed, its scope statement is useful corroboration that the boundary was independently enumerated.

ISO 27001 mapping

CC6.6 corresponds to the following ISO 27001:2022 Annex A control(s): A.6.7, A.8.20, A.8.21, A.8.22, A.8.23, A.8.27, A.8.31. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC6.6 rather than duplicating work.

Map CC6.6 to ISO 27001 & NIST CSF →

Crosswalk this criterion in the Control Mapper & Gap Assessment.

Document the risk →

Record treatment for gaps against CC6.6 in the Risk Register.

Other Logical and Physical Access Controls criteria

CC6.1 Logical access security architecture CC6.2 Provisioning and deprovisioning CC6.3 Role-based access and least privilege CC6.4 Physical access restriction CC6.5 Secure disposal CC6.7 Protection of data in transmission and movement CC6.8 Prevention and detection of malicious software

All CC6 Logical and Physical Access Controls criteria →

Frequently asked questions

Is CC6.6 required for a SOC 2 report?

Yes. CC6.6 sits in the Common Criteria, which apply to every SOC 2 engagement regardless of which additional categories you scope in — there is no SOC 2 report that omits them.

How does an auditor test CC6.6?

In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet CC6.6 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.

What happens if CC6.6 fails testing?

A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.

Does SOC 2 CC6.6 map to ISO 27001?

Yes — CC6.6 aligns with ISO 27001:2022 Annex A control(s) A.6.7, A.8.20, A.8.21, A.8.22, A.8.23, A.8.27, A.8.31. If you already run a certified ISMS, re-point that evidence rather than building a parallel set; the underlying control is the same and only the reporting format differs.

What are the most common audit findings for CC6.6?

MFA enforced for staff but not for service accounts, contractors, or a named legacy application. Management interfaces reachable from the internet, discovered during testing rather than declared.