TSC-CC6.6 Guidance

TSC-CC6.6 is one of the SOC 2 Common Criteria requirements that auditors frequently translate into a simple question: “What stops an external attacker from getting into your systems, and how do you know it keeps working?” The requirement is concise, but the audit work is not. It cuts across identity and access management (IAM), network security, endpoint controls, application controls, and security monitoring.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn TSC-CC6.6 into a control story that is easy to test: (1) define the system boundary and external threat sources, (2) list every authorized external access method, (3) implement technical controls for each method, (4) monitor and review the controls, and (5) preserve evidence for the audit period.

This page gives requirement-level implementation guidance you can assign to control owners immediately, plus the evidence list auditors typically expect for a SOC 2 Type 1 or Type 2. All regulatory text references below map to the AICPA Trust Services Criteria 2017, TSC-CC6.6 ¹.

Regulatory text

Requirement (TSC-CC6.6): “The entity implements logical access security measures to protect against threats from sources outside its system boundaries.” ¹

What the operator must do:
You must design and run technical access controls that protect in-scope systems from external compromise. Auditors will expect you to (a) identify the system boundary, (b) control all external entry points, (c) monitor for external threats, and (d) prove controls operated during the audit period with retained evidence ¹.

Plain-English interpretation (what CC6.6 really means)

“Outside the boundary” is anything not under your direct system control: the public internet, remote users, third parties, unmanaged networks, and external services connecting into your environment. CC6.6 expects a layered set of logical controls that reduce the chance of unauthorized access and increase your ability to detect and respond.

In practice, most SOC 2 teams pass CC6.6 when they can show:

• A clear diagram or written boundary definition for what is “in scope.”
• Standard, approved ways to access in-scope systems from outside (for example: SSO, VPN, bastion hosts, managed admin paths).
• Preventive controls (authentication, authorization, segmentation, secure configuration).
• Detective controls (logging, alerting, monitoring).
• A repeatable review and testing rhythm with evidence.

Who it applies to (entity and operational context)

Applies to: Organizations undergoing a SOC 2 audit that include the Security category and rely on the SOC 2 Common Criteria ¹.

Operational context where it shows up:

• SaaS products exposed to the internet (public app, admin consoles, APIs).
• Corporate access into production (engineers, SREs, support).
• Remote access for employees and contractors.
• Third-party connections (managed service providers, payment processors, customer SSO integrations, outbound-to-inbound tunnels).
• Cloud environments (IaaS/PaaS control planes, security groups, IAM policies).

If you cannot name every external path into your systems, you are not ready to claim CC6.6 is implemented.

What you actually need to do (step-by-step)

Use this as an execution checklist. Assign each step to an owner (Security, IT, Cloud Ops, AppSec), and keep GRC accountable for evidence completeness.

Step 1: Define the “system boundary” and external threat sources

1. Write the boundary definition in your SOC 2 system description terms (in-scope apps, infra, cloud accounts, networks, endpoints used for administration).
2. Create/refresh a network and data flow diagram that marks:
   • Internet-facing components
   • Admin access paths
   • Third-party connections
3. List external threat sources relevant to your environment: internet attackers, credential stuffing, phishing-driven account takeover, misconfigured cloud access, compromised third-party credentials.

Deliverable: Boundary statement + diagram package suitable for an auditor walkthrough.

Step 2: Inventory and standardize all external entry points

Build a single register of “ways in,” including:

• Public application endpoints (web, API)
• Remote access (VPN/ZTNA)
• Administrative access (bastion, privileged access workstations, cloud console)
• CI/CD access paths that can change production
• Support tooling that can access customer data
• Third-party inbound connections

Rule: Anything not in the register is unauthorized by default until reviewed.

Step 3: Implement preventive controls for each entry point (minimum control set)

Map each entry point to technical controls. Typical expectations for CC6.6 include:

Identity and authentication

• Centralized identity (SSO/IdP) for workforce access.
• Strong authentication for external access paths (for example, MFA for admin and remote access).
• Conditional access where available (device posture, geo/IP restrictions) for higher-risk roles.

Authorization and privilege

• Role-based access control and least privilege for admin tools and cloud consoles.
• Separate admin roles from standard user roles; restrict break-glass access with approvals and logging.

Network and perimeter controls

• Firewalls/security groups with deny-by-default inbound rules.
• Segmentation between public services and internal/admin networks.
• Controlled egress where appropriate for admin and production systems.

Application-layer protections

• Secure session management and hardened authentication endpoints.
• Rate limiting and protections for public APIs where feasible.
• Administrative interfaces not exposed publicly unless required, and then strongly protected.

Your control design should show layered defenses. Auditors do not want a single point of failure for external access.

Step 4: Implement detective controls (monitoring, alerting, and review)

CC6.6 is not satisfied by configuration alone. You need monitoring that can identify external threats and misuse:

1. Centralize logs for authentication events, privileged actions, network events, and cloud control plane activity.
2. Alert on high-risk signals (examples: repeated failed logins, impossible travel, privileged role changes, new access keys, firewall rule changes opening inbound access).
3. Establish a review process:
   • Regular review of security alerts and relevant dashboards
   • Review of perimeter rule changes and exceptions
   • Review of privileged access usage (who used admin, why, and whether it matched a ticket)

Step 5: Maintain audit trail and prove operation (evidence-ready)

For Type 2, your auditor will sample across the audit period. For Type 1, they will validate design and implementation as of a point in time. Plan for both by retaining:

• Configuration exports (IdP policies, firewall/security group rules, cloud IAM policies)
• Log samples and alert records
• Review meeting notes or tickets showing follow-up and closure
• Change management records for perimeter and IAM changes

Step 6: Test control effectiveness and fix gaps

At least once per audit cycle (and also after major changes), run targeted testing:

• Attempted access checks (for example: verify MFA enforced for admin access, verify closed ports stay closed, verify privileged actions generate logs).
• Configuration drift checks (for example: detect new internet-facing assets or newly opened inbound rules).
• Tabletop or incident response checks tied to “external unauthorized access” scenarios.

Record the test plan, results, exceptions, and remediation actions ¹.

Required evidence and artifacts to retain (auditor-ready)

Keep evidence in a single SOC 2 evidence folder with clear naming and dates. A clean evidence pack is often the difference between a smooth audit and weeks of back-and-forth.

Core artifacts (expected for CC6.6):

• Logical Access / Access Control Policy covering external access protection ¹
• System boundary definition and network/data flow diagrams
• External entry point register (“ways in” inventory)
• IdP/SSO configuration screenshots/exports showing authentication rules for external access
• MFA enforcement evidence for privileged and remote access paths
• Firewall/security group configuration exports and change history
• Central logging/SIEM configuration and sample logs for auth and privileged actions
• Alerting rules and sample alerts with incident/ticket follow-up
• Periodic review records (access reviews for privileged roles; perimeter exception reviews)
• Control testing evidence (internal assessments, scan results, validation scripts) ¹

Tip for serious operators: Evidence should show “before/after” for exceptions. If you allow a temporary inbound rule, retain the approval, the reason, the time box, and proof it was removed.

Common exam/audit questions and hangups

Auditors often probe CC6.6 through a small set of repeatable questions:

1. “Define your system boundary.”
   Hangup: boundary is vague, outdated, or missing third-party connections.

2. “What are all the external entry points?”
   Hangup: teams forget support tools, CI/CD, or contractor access methods.

3. “Show MFA is enforced for privileged access.”
   Hangup: MFA exists but isn’t required for all admin paths or break-glass accounts.

4. “How do you detect external attacks or unauthorized access attempts?”
   Hangup: logs exist but are not reviewed, alerts are noisy, or nobody owns triage.

5. “Show this worked during the audit period.”
   Hangup: controls are real, but evidence retention is inconsistent.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in audit	Fix
Policy-only compliance	CC6.6 expects implemented measures, not statements	Pair policy with configs, logs, and reviews 1
Unknown “shadow” entry points	External access exists outside standard controls	Maintain an entry-point register and reconcile it with cloud asset inventories
MFA exceptions without governance	Exceptions become permanent and untracked	Require time-bound approvals and monthly exception review
Logging without action	Auditors look for response, not just collection	Tie alerts to tickets and document closures
No periodic assessment	Controls drift as infra changes	Schedule recurring checks and keep test results 1

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime ¹. Your risk is commercial and operational: failing CC6.6 can produce SOC 2 report exceptions, delay sales cycles, trigger customer contract issues, and expose you to higher likelihood of externally driven incidents such as account takeover or cloud console compromise.

Practical 30/60/90-day execution plan

This plan assumes you are standing up or tightening CC6.6 controls for an upcoming SOC 2.

Days 1–30: Scope, inventory, and minimum protections

• Confirm in-scope systems and write the system boundary definition.
• Build the external entry point register.
• Enforce MFA for privileged access and remote access paths you control.
• Lock down inbound network rules to deny-by-default and document exceptions.
• Turn on centralized logging for auth events and privileged actions.
• Start an evidence folder and naming convention.

Daydream fit: If you track controls in Daydream, set up CC6.6 as a control objective with linked evidence tasks per entry point (policy, config export, log sample, review record). This prevents evidence gaps.

Days 31–60: Monitoring, review workflows, and audit trail

• Define alerting use cases tied to external threats (failed logins, privilege changes, perimeter changes).
• Establish a documented monitoring and review process with ownership and escalation.
• Implement change control expectations for perimeter and IAM changes (ticketing, approvals, and logs).
• Run an internal “audit-style” evidence review: can you prove operation for each control?

Days 61–90: Testing, hardening, and auditor-readiness

• Perform a periodic assessment of external access controls and document results ¹.
• Validate that every entry point has both preventive and detective controls.
• Close gaps found in reviews (MFA coverage holes, missing logs, noisy alerts).
• Prepare an auditor walkthrough pack: boundary diagram, entry point register, control narrative, and a curated evidence set.

Frequently Asked Questions

What counts as “sources outside its system boundaries” for CC6.6?

The public internet, remote users on unmanaged networks, third-party connections, and any external service that can authenticate into or reach in-scope systems qualify ¹. Define your boundary explicitly so “outside” is unambiguous in audit.

Does CC6.6 require MFA everywhere?

The text does not prescribe MFA explicitly ¹. Auditors commonly expect strong authentication for external and privileged access because it is a straightforward logical access security measure you can evidence.

How do we prove the controls “operate” for a SOC 2 Type 2 period?

Retain dated configuration evidence, log samples, alert/ticket records, and review sign-offs that span the audit period. A control that exists but has no time-bound evidence often gets written up.

Are WAF and DDoS protections required for CC6.6?

CC6.6 requires logical access security measures against external threats ¹. Whether WAF/DDoS is necessary depends on your architecture and threat model; if you have public endpoints, document what you use and why it’s sufficient.

How should we handle third-party access (MSPs, contractors, support vendors)?

Put every third-party access path into the same entry point register and require standardized access methods (SSO where possible), least privilege, logging, and periodic review. Treat third-party accounts as higher risk and govern exceptions tightly.

What’s the fastest way to reduce audit friction for CC6.6?

Write a short control narrative that maps each external entry point to its preventive and detective controls, then attach direct evidence links. Daydream helps by keeping the narrative, tasks, and artifacts in one place so sampling requests don’t turn into a scramble.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA Trust Services Criteria 2017