SOC 2 CC6.6: Protecting Against Threats From Outside System Boundaries

SOC 2 CC6.6 requires logical access security measures that protect the system against threats originating outside its boundaries. It sits in the CC6 series (Logical and Physical Access Controls), and a frequent finding under it is a firewall or security group that was configured correctly once and never reviewed again, leaving the company with no evidence the rules still match the environment.

What does SOC 2 CC6.6 require?

In plain terms, CC6.6 is about the edge of the system. It asks what stops an unauthorized party on the internet, or on any network the company does not control, from reaching in. The controls it names are the familiar perimeter set: firewalls, network segmentation, restricted communication channels, protection of credentials in transit, and stronger authentication for access that comes from outside.

The word boundary carries weight here. In a cloud environment the boundary is defined by security groups, load balancers, and identity-aware proxies rather than a physical network edge, but the intent is the same. Anything that crosses from an untrusted network into the system passes through a control that decides whether it is allowed.

CC6.6 overlaps with the access criteria on either side of it. CC6.1 covers logical access architecture broadly, and CC6.6 narrows to the external-facing part of it. It carries four points of focus that together describe a defended boundary.

What are the CC6.6 points of focus?

The AICPA defines 4 points of focus for CC6.6. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Restricts communication channels. The activity permitted through any external communication channel, such as a specific port or protocol, is limited to what is needed, so unused paths into the system are closed.
• Protects credentials in transit. Identification and authentication credentials are protected while they cross the system boundary, so they cannot be captured in transit.
• Requires additional authentication from outside. Access originating from outside the boundary requires stronger authentication, which in practice means multi-factor authentication for remote and administrative access.
• Implements boundary protection systems. Firewalls, network segmentation, intrusion detection or prevention, and endpoint detection and response are configured, deployed, and maintained to protect external access points.

How do you meet CC6.6 in cloud environments?

Cloud environments define the boundary in software, which makes CC6.6 a matter of configuration and evidence rather than physical appliances:

• Security groups and network ACLs with default deny. Inbound access is closed by default, and each open port traces to a documented need. Public exposure is limited to load balancers and gateways, with application and data tiers in private subnets.
• MFA and identity-aware access for anything external. Administrative consoles, VPN or zero-trust access, and remote logins require multi-factor authentication. Where a system cannot support MFA, the exception is documented in the risk register with compensating controls, not left silent.
• TLS everywhere at the edge. Credentials and session data are protected in transit by enforced TLS on public endpoints, which addresses the credential-protection point of focus.
• Managed boundary services. A web application firewall, DDoS protection, and a cloud-native intrusion detection or endpoint detection and response service cover the boundary-protection point of focus, with their configurations exportable as evidence.

Multi-factor authentication does not have to be universal to satisfy CC6.6. When a system genuinely cannot support it, the accepted approach is a documented risk acceptance paired with compensating controls such as complex passwords and IP allowlisting, so the auditor sees a deliberate decision rather than a gap.

How do you meet CC6.6 on-prem?

On-prem environments own the perimeter hardware, so CC6.6 returns to physical and virtual network controls. The network security on-prem guide covers the detail; the shape is:

• Zone-based segmentation with default deny. The network is divided into zones with a default-deny firewall between them, so a compromise in one zone does not open the rest.
• Restricted management protocols. SSH and RDP are reachable only from internal VLANs or through a VPN, never exposed to the internet, and that restriction is documented as a control rather than an operational habit.
• VPN or bastion for remote access. External access reaches internal systems through a VPN or a bastion host that enforces multi-factor authentication.
• Intrusion detection and boundary monitoring. An IDS or IPS at the perimeter, with alerts feeding the monitoring covered under CC7.2.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC6.6?

How does CC6.6 map to ISO 27001:2022?

Organizations pursuing both frameworks can reuse CC6.6 evidence directly for these Annex A network controls. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC6.6 defends the boundary that the rest of the CC6 series operates behind. CC6.1 sets the logical access architecture, and CC6.6 is the external-facing slice of it. The previous criterion, CC6.5, covers disposing of assets once they leave the boundary, and the next, CC6.7, covers protecting information as it crosses that boundary in transit. Alerts from boundary protection systems feed the anomaly detection covered under CC7.2.

Frequently Asked Questions

What does SOC 2 CC6.6 mean?

SOC 2 CC6.6 requires logical access security measures that protect the system from threats coming from outside its boundaries. In practice it covers firewalls and security groups, network segmentation, protection of credentials in transit, and stronger authentication such as MFA for any access that originates outside the system.

What evidence satisfies CC6.6?

The core evidence is the firewall or security group rule set with default deny, records of periodic firewall rule reviews, MFA configuration and enrollment reports, TLS configurations that protect credentials in transit, and the configuration and alerts from boundary protection systems such as a WAF, IDS, or EDR.

Does CC6.6 require MFA?

CC6.6 requires stronger authentication for access from outside the boundary, and MFA is the usual way to meet it. It does not have to be on every system. When a system cannot support MFA, the accepted approach is a documented risk acceptance with compensating controls such as complex passwords and IP allowlisting, rather than an undocumented gap.

How often should firewall rules be reviewed for CC6.6?

Quarterly is the common cadence. A short checklist confirms default deny is still in place, that each allow rule still has a business justification, that temporary rules have been removed, and that management protocols remain restricted. Each quarterly review produces an evidence artifact that shows the boundary controls are maintained rather than set once and forgotten.

How is CC6.6 different from CC6.1?

CC6.1 covers logical access security across the whole system, including internal access. CC6.6 narrows to the external boundary: the controls that protect the system from threats originating outside it. A firewall rule set and MFA on remote access support both, but CC6.6 is specifically about what crosses the perimeter.