polara labs

SOC 2 · Trust Services Criteria · 2 min read

SOC 2 CC6.6: network boundaries, explained for startups

What CC6.6 asks you to show about network boundaries, and what proves it.

You control what can reach your systems from outside. Firewalls or security groups, a web application firewall where it fits, and multi-factor authentication on remote access. Only the ports and services you meant to expose are open.1

CC6.6 is a common criterion, so it is part of every SOC 2 report.

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC6.6, the usual records are these.

  • Security group or firewall rule exports
  • Web application firewall configuration
  • Multi-factor authentication settings for remote and console access

What Polara asks about it

The free readiness assessment asks 4 questions that bear on CC6.6. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

  • MFA required for cloud console access? If yes, show it: Okta multi-factor authentication (MFA) policy screenshot, AWS identity and access management (IAM) policy requiring MFA, Google Workspace 2-step verification settings, or Azure Active Directory MFA policy. If no, the fix: enforce multi-factor authentication (MFA) for every cloud console identity and export the enforcement setting as evidence.
  • WAF or equivalent in place? If yes, show it: Cloudflare web application firewall (WAF) rules dashboard, AWS WAF rule groups, WAF policy export, or security event logs. If no, the fix: place a web application firewall or equivalent in front of public endpoints and export its configuration.
  • Security groups or firewall rules restrict production ingress? If yes, show it: AWS Security Groups screenshot, GCP Firewall rules, network ACLs export, or VPC segmentation diagram. If no, the fix: restrict production ingress to required ports and sources and export the security group or firewall rules.
  • Direct SSH/console access limited to named admins? If yes, show it: AWS SSM Session Manager config, bastion host access logs, VPN access policy, or jump host audit logs. If no, the fix: limit SSH and console access to named administrators and export the access list.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Access Control Policy and Operations Security Policy cover CC6.6.

Free templates that help, printed in full with Word, PDF or Excel downloads:

Connected systems that pull evidence for it:

  • Amazon Web Services, IAM account summary: account-wide counts, including users and whether root multi-factor authentication is on.
  • Google Cloud, Organization policies: organization policy constraints in effect on each project.
  • Okta, Multi-factor enrollment: how many active users have at least one active multi-factor authentication factor.
  • Okta, Sign-on policies: sign-on and authentication policies, and whether their rules require multi-factor authentication.
  • Microsoft Entra ID, Multi-factor registration: how many users have registered a multi-factor authentication method.
  • Microsoft Entra ID, Conditional access policies: enabled conditional access policies that require multi-factor authentication.

If you also run ISO 27001, the Annex A controls A.8.20, network security, A.8.21, network services and A.8.22, network segregation ask for overlapping evidence. One record can serve both when it names what it proves.

Is it in your scope?

Yes, always. CC6.6 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Logical and physical access: the criteria around it

CC6.6 is one of 8 criteria in logical and physical access, CC6.1 to CC6.8. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

Before it: CC6.5, data and device disposal. After it: CC6.7, data in transit. All the criteria are on the Trust Services Criteria page, grouped by category.

Questions

What does SOC 2 CC6.6 ask a startup to show?
You control what can reach your systems from outside. Firewalls or security groups, a web application firewall where it fits, and multi-factor authentication on remote access. Only the ports and services you meant to expose are open.
What evidence proves CC6.6?
The usual evidence is security group or firewall rule exports, web application firewall configuration and multi-factor authentication settings for remote and console access. An auditor tests it across the report period, so dated records matter more than a written promise.

Sources

  1. TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers.

Related

Get audit-ready without a compliance team.

The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.

Take the free assessment

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.