CC6.6 Boundary protection: requirements and evidence

CC6.6 boundary protection: what SOC 2 asks for at the system edge

CC6.6 requires the organization to apply logical access security measures that protect its system against threats originating outside the system boundary. If a customer or contract asks for SOC 2 and your service is reachable from the internet, from partner networks or from remote staff laptops, an assessor will expect to see where that edge is, what can cross it, and what proves the controls at the edge work. The criterion has four points of focus: restricting access from outside the system, protecting identification and authentication credentials, requiring additional authentication or credentials for remote or external access, and implementing boundary protection systems such as firewalls. The points of focus are guidance for designing and evaluating controls, not a checklist, so your job is to show a coherent design that addresses the risks you have actually identified under CC3.

The hard part is usually agreeing on where the boundary is. A product team may think of the boundary as the production Kubernetes cluster, while the auditor sees the cloud account, the CI pipeline that deploys into it, the SaaS support console with a database export button, and the contractor VPN that reaches the admin network. Each of those paths is an entry route for threats from outside your control. Before you write any control narrative, draw the system boundary as a diagram that lists every ingress path, including vendor access and break-glass accounts, and confirm the list with the engineers who run it. A boundary that is written down in one place but operated differently in another is the most common source of exceptions in a CC6.6 test.

Once the boundary is agreed, ask three questions for each path: who or what can reach it, which credentials or second factors gate it, and which boundary control records or blocks the traffic. Self-hosted platforms can answer these questions with inspectable configuration. For example, a firewall rule set in OPNsense can be exported and reviewed, and its live log view can show matches for a given rule, while a web application firewall such as Coraza can sit in front of an application proxy. Identity providers such as authentik can enforce a second factor at login for remote access. Confirm with the vendors and with your own environment which logs are retained, for how long, and who reviews them, because the assessor will ask for samples across the observation period in a Type 2 examination.

Which systems, paths and parties fall inside the CC6.6 boundary

CC6.6 covers threats that originate outside the system boundary, so the first decision is where that boundary sits. The cards below cover the scoping choices that most change the work, and each one names what to settle with the auditor before fieldwork begins.

Public-facing applications and APIs

Every internet-reachable web application, API gateway and customer portal is a boundary entry point. Decide whether each hostname, path and API version is in scope, and whether test, staging or legacy endpoints that still resolve publicly are included. Confirm with the auditor how they expect you to show that application traffic passes through a web application firewall or equivalent control, and which rule sets and logs will serve as evidence. The unlisted endpoint is the most common gap in this area.

Administrative and management interfaces

Consoles, database admin tools, Kubernetes dashboards, out-of-band management ports and cloud control planes often sit outside the application boundary yet carry the most privilege. Decide whether they are inside the CC6.6 boundary, or whether they are treated as internal paths reached only through a controlled entry point. Confirm with the auditor how credentials for these interfaces are protected and whether they require additional authentication when reached from outside the network.

Remote and VPN access for staff

Staff working from home, travelling or supporting customers reach internal systems through VPN concentrators, identity-aware proxies or bastion hosts. Decide which access paths count as external, and whether every path requires a second factor before a session opens. Confirm with the auditor which login events and firewall rule matches they expect to sample, and how departed staff lose these paths. Your identity provider logs usually become the primary evidence here.

Vendor and partner connections

Site-to-site tunnels, API integrations and file transfer links to customers, suppliers and service providers cross the boundary in both directions. Decide whether each connection is in scope, who owns its credentials, and whether traffic is restricted to named addresses and ports. Confirm with the auditor whether partner access is governed under CC6.6 or under the logical access and third-party criteria, so the same connection is not tested twice or missed.

Cloud network perimeters

Virtual networks, security groups, load balancers and managed firewall services define the perimeter when the system runs in a public cloud or a hosted data center. Decide which network segments hold in-scope data and which rules are considered boundary controls. Confirm with the auditor how rule change history will be shown, since a point-in-time export of rules rarely satisfies a Type 2 observation period. Infrastructure as code repositories often provide that history.

Subservice organizations covering part of the boundary

Hosting providers, managed firewall operators and content delivery networks may operate controls that protect the perimeter on your behalf. Decide whether to use the carve-out method, which excludes their controls from your examination, or the inclusive method, which tests them alongside yours. Confirm with the auditor which subservice organization reports you must collect, what complementary user entity controls you must operate on your side, and how gaps in their coverage will be disclosed.

How an assessor tests CC6.6 boundary protection

This table compares what an assessor inspects, what evidence they request, how they select samples, and where findings usually appear for each point of focus under CC6.6. Read it as a preparation checklist: the evidence column is what your team should be able to produce on request, and the findings column shows where examinations most often raise exceptions.

Point of focus	What the assessor inspects	Evidence requested and sample	Common findings
Restricting external access	Firewall and packet filter rule sets, default deny posture, and whether inbound rules match the approved system description	Current rule export and change history for the audit period; assessor selects a sample of rule changes and traces each to an approved ticket	Broad source ranges such as any-to-any rules left from setup, or rules with no documented business owner
Exposed port inventory	Which ports and services are reachable from outside the boundary, compared with what the organization says should be exposed	External scan or inventory output dated within the period, with reconciliation to the rule set; assessor may run an independent scan	Services reachable externally that are missing from the system description, such as management interfaces or old test endpoints
Protecting authentication credentials	How credentials for external-facing services are stored, rotated and kept out of configuration files and code	Secrets management configuration, rotation records and access lists for credential stores; sample of rotated credentials	Shared or default credentials on boundary devices, or service accounts with no rotation record
Additional authentication for remote and external access	Whether remote and external sessions require a second factor, and whether enrolled factors are actually enforced at login	Authentication policy export, enrollment report showing factor coverage, and login logs for a sample of remote sessions	Exceptions for legacy VPN groups or service accounts, and factors enrolled but not enforced in the login flow
Boundary protection systems	Presence and configuration of firewalls, web application firewalls and other inspection points, plus logging of blocked and allowed traffic	Configuration baselines, rule match logs or alerts reviewed in the period, and evidence of review by a named person; sample of blocked events	Logs enabled but never reviewed, or no evidence that rule changes were tested before deployment
Change control on boundary rules	Whether boundary rule and policy changes follow the same authorization path as other production changes	Change tickets, approvals and deployment records for a sample of boundary changes across the period	Emergency changes made directly on the device with no after-the-fact approval

How to implement boundary protection in six steps

This sequence moves from knowing every way traffic can reach the system to proving that each path is deliberately allowed, protected by stronger authentication, filtered at the edge, and reviewed on a schedule the auditor can test.

Inventory every external entry point
The infrastructure or security lead lists every path from outside the system boundary into production: public endpoints, administrative consoles, VPN and remote access, API gateways, third-party integrations, vendor support channels, and any inbound connection from a partner network. Each entry is recorded with its owner, protocol, port, business purpose and the systems it reaches. The step is done when the inventory is reviewed against cloud network configuration and firewall exports, and every gap between the list and the configuration has been explained or closed. The auditor will ask for this inventory and for the diagram that shows where the trust boundaries sit.
Define a default-deny rule set
The network or security engineer writes the rules that permit only the traffic the inventory justifies, with all other inbound traffic denied. Rules are grouped with aliases for address ranges and services so they stay readable, and each allowed path has a documented reason and an approver. Firewall platforms such as OPNsense let teams express pass, block and reject rules by source, destination, port and protocol, so the rule set can be written as configuration and kept under change control. The step is complete when each allowed path maps to an inventory entry and the default deny rule is in place. The auditor will ask for the rule export and the approval record for each path.
Enforce second-factor authentication for external access
The identity owner requires an additional factor for every remote, administrative or external login that crosses the boundary, so a stolen password alone does not grant access. Options include authenticator-app one-time codes, hardware security keys and passkeys, depending on the identity provider chosen. Platforms such as authentik can validate enrolled second factors during login, and FreeIPA supports TOTP and HOTP tokens, including hardware tokens. The step is done when a test login without the second factor is refused for each external path in scope, and the result is recorded. The auditor will ask for the policy setting and test evidence showing the refusal.
Deploy web and packet filtering at the edge
The platform engineer places packet filtering at the network edge and web application filtering in front of public web services. A web application firewall such as Coraza, which is compatible with ModSecurity SecLang rules and the OWASP Core Rule Set, inspects requests for injection and cross-site scripting attacks and can be integrated with common reverse proxies. Blocking and logging modes are tuned against the application so legitimate traffic is not disrupted. The step is complete when filtering is active on every public entry point from the inventory and a controlled test request is blocked and logged. The auditor will ask for the active rule configuration and a sample of logged blocks.
Protect credentials used across the boundary
The security engineer identifies every secret that crosses the boundary, including service account passwords, API keys, OAuth client secrets, VPN pre-shared keys and integration tokens. Each is moved into a managed secret store, given a named owner, rotated on a defined schedule, and removed from configuration files and source repositories. Access to the secret store is itself restricted and logged. The step is done when a scan of repositories and configuration finds no hard-coded credentials for boundary systems, and a rotation has been performed and recorded. The auditor will ask for the secret inventory, rotation records and the scan results.
Set up periodic rule and log reviews
The control owner schedules recurring reviews of firewall rules, edge filtering rules and boundary logs, comparing the live configuration with the approved inventory and investigating unexpected allowed paths or repeated blocked attempts. Logging for each rule match is enabled where the platform supports it, and logs are forwarded to a location where they cannot be altered by the team operating the system. Each review produces a dated record with findings and the actions taken. The step is complete when at least one review cycle has run and its findings are tracked to closure. The auditor will ask for review records, the change tickets linked to rule changes and the log samples supporting the review.

Which open-source tools produce boundary protection evidence

OPNsense is the most direct source of evidence for the restriction side of CC6.6, because its stateful packet filter records how traffic crossing the boundary was handled. Each rule passes, blocks or rejects traffic by source, destination, port and protocol, so an assessor can read the rule base and see that external access is limited to named services. Aliases let the team group address ranges such as management networks or partner egress points, which keeps rules readable and makes a later review easier. Enabling per-rule logging matters here: a rule that is never logged produces no proof that it fired. Confirm in your own OPNsense version and configuration that logging is turned on for the rules you rely on, and that the live log view or your exported logs retain enough history to cover the whole audit period.

Coraza covers the application layer, where a packet filter cannot see whether a request to an exposed web service is an attack. It is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and its rules target attacks such as SQL injection, cross-site scripting and code injection. It integrates with Caddy, HAProxy, Traefik and Nginx, so the choice of reverse proxy or load balancer determines how it is deployed. The evidence is the rule configuration under version control, the audit logs of blocked requests and a record of how rule sets are reviewed and updated. Confirm which rule set version you run, how false positives are handled, and whether your proxy integration exposes the logs an assessor will ask for.

authentik and FreeIPA produce the evidence for additional authentication on remote and external access. The authentik authenticator validation stage checks enrolled second factors at login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Decide which factors are acceptable for external users, and remove weaker options such as SMS or email codes where your risk assessment says so. FreeIPA supports HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server during migration, which helps when remote access moves from an older system. Confirm the factor types and migration path against your version. Both tools are licensed as MIT (authentik) and GPL-3.0-or-later (FreeIPA), and OPNsense is BSD-2-Clause and Coraza is Apache-2.0; review those terms with your legal team before you redistribute or modify them.

Which evidence passes a CC6.6 test and how to keep it current

An auditor testing CC6.6 wants proof that external access is restricted, that remote entry requires stronger authentication, and that boundary controls are reviewed and changed under control. The cards below cover the artifacts that usually show this, how to keep each one current between audits, and the period a Type 2 examination typically samples across. Confirm the exact sample sizes and period with your auditor before fieldwork.

Exported firewall rule sets with change history

The current rule set, exported on a schedule, shows what the boundary permits, and the change history shows who altered each rule and why. Store exports in a versioned repository so every rule change has an approved ticket behind it. Check that rules are restricted by source, destination, port and protocol, and that aliases for address groups are documented. OPNsense can log each rule match, so confirm which logs you keep and for how long. An auditor will usually pick changes from the observation period and trace each one back to an approval.

Network diagrams showing trust boundaries

A current diagram marks where the system boundary sits, which zones are exposed to the internet, and where the firewalls, load balancers and reverse proxies sit between them. Without it, an auditor cannot confirm that the rules they sampled cover every path into production. Update the diagram whenever a new ingress point, VPN, or third-party integration is added, and date each version. Tie each change to the corresponding change record so the diagram and the rule history tell the same story.

Authentication policy and enrolled-factor records

For remote and external access, the auditor looks for a written policy requiring additional authentication and records showing which second factors each user has enrolled. In authentik, the authenticator validation stage checks enrolled factors at login, including TOTP, WebAuthn and passkeys. FreeIPA supports OTP tokens for the same purpose. Export enrollment lists monthly, and remove factors for leavers during offboarding. Compare enrollments against the access list to find accounts that can reach remote entry points without a second factor.

WAF rule configuration and blocked-event logs

Coraza, with the OWASP Core Rule Set, sits in front of web applications and defends against injection and cross-site scripting. Evidence includes the deployed rule configuration, the version of the ruleset, and logs of blocked requests. Review blocked events on a regular cadence and record which ones were false positives, which led to tuning, and which required incident handling. Auditors often ask whether rule changes were approved, so keep tuning changes in the same change process as firewall rules.

External exposure scan results with remediation tickets

Periodic external scans show which ports and services answer from outside the boundary. Each unexpected exposure should map to a ticket with an owner, a decision (close, accept with reason, or document as intended), and a closure date. Scans matter only when the findings are acted on, so keep the tickets alongside the scan reports. Confirm scan scope and frequency with your auditor, and include cloud load balancers and DNS records in the scope, not just the on-premises perimeter.

Periodic rule review sign-offs

A recurring review confirms that each boundary rule and exception is still needed and still correctly scoped. Record the reviewer, the date, the rules reviewed, and any removed or changed rules. Reviews performed by someone other than the rule author give the strongest evidence. Set the review cadence in your written policy and hold to it, because an auditor will check that reviews happened on schedule across the whole observation period rather than only once before fieldwork.

What meeting CC6.6 boundary protection costs

This table separates the cost components of meeting CC6.6 into one-time and recurring items, showing who is paid for each and what moves the price. Use it to see where open-source tools remove license spend and where engineering, review and assessment effort remains, then use the last column to shape a written quote.

Cost component	One-time or recurring	What drives the cost up or down	What to ask for in a quote
Tooling and licenses	Recurring where commercial	Number of boundary points, user count and vendor licensing model. Self-hosted open-source firewalls, WAFs and identity tools such as OPNsense, Coraza and authentik carry no license fee, though support contracts may apply.	Itemized list of each product, its license terms, and any support or subscription fees separate from the implementation price
Engineering time to configure rules and authentication	One-time, with later changes recurring	Complexity of the network layout, number of exposed services, WAF rule tuning to reduce false positives, and how many identity sources must integrate with the second factor flow	Named tasks for ruleset design, alias and policy setup, MFA enrollment flows and documented change steps, with the deliverables each task produces
Evidence upkeep such as rule reviews and log exports	Recurring	How often the organization reviews firewall rules and WAF exceptions, whether log exports are automated, and how many audit periods the evidence must cover	Who performs each periodic review, the schedule, and the format of exported logs and review sign-offs the auditor will receive
External penetration testing or configuration review	Recurring, usually annually or on significant change	Scope of external addresses, number of applications behind the boundary, and whether the test covers the WAF and authentication endpoints	Defined scope list, testing method, retest terms and whether the report is shared with the independent auditor
Auditor sampling effort	Recurring with each examination period	Number of boundary devices and rule changes in the period, the sample sizes the auditor selects, and how cleanly change tickets and review records are kept	The auditor's fee basis and assumed sample sizes, plus which items the organization must prepare before fieldwork starts

Who owns boundary protection: your team, a partner and the auditor

Your organization owns the boundary controls and everything SOC 2 asks you to prove about them. The people who run the system stay accountable for what the firewall, web application firewall and authentication stack actually allow, even when a partner built them. Management also decides what risk remains after the controls are in place and records that decision.

Control ownership: Name an owner for each boundary control, such as the firewall ruleset, the WAF policy and the remote access gateway, and record that owner in your control matrix.
Rule change approval: Require a documented request, a reviewer who is not the requester, and a record of the approval for every firewall or WAF rule change.
Log review: Set who reviews boundary logs, how often, and what they look for, then keep dated records of the reviews.
Residual risk acceptance: Management decides which boundary risks remain and signs off on them in writing.
Access to external paths: Decide which external sources may reach which systems, and review that list on a schedule.

Before the audit, confirm that each control has a named owner who can explain it without the partner present.

Where boundary protection usually fails an examination

Assessors testing CC6.6 tend to find the same handful of gaps: firewall and WAF rules nobody can justify, test rules that were never removed, administrative access without a second factor, and exposed services that no one owns. Each card below names a gap, how to close it, and the record that shows it is closed.

Rule sets with no documented reason

Firewall rules that allow traffic without a recorded business purpose are the most common finding in boundary testing. Assessors pick rules at random and ask who requested them and why. Close the gap by giving every rule or alias a description, an owner and a ticket reference, then reviewing the rule set on a schedule. Evidence is the exported rule set with descriptions, the change tickets behind each rule, and the review record showing that someone removed or confirmed each one. OPNsense aliases can group addresses so that each group has one documented purpose.

Allow-any rules left from testing

Broad rules added to troubleshoot a connection or a vendor integration often stay in place after the work ends. A rule that passes all sources to all ports on a production segment is hard to justify to an assessor. Close the gap by tagging temporary rules with an expiry date and reviewing them at each change window. Evidence is the list of temporary rules with expiry dates, the change record that removed them, and firewall logs showing that the rule no longer matches traffic.

Administrative remote access without second factors

Administrators who reach internal systems through VPN, SSH or a web console from outside the network are the access path attackers target first. CC6.6 expects additional authentication for remote and external access, so a password alone is a weak point. Close the gap by requiring a second factor for every administrative remote login, using a TOTP app, WebAuthn passkey or hardware token, and blocking accounts that have not enrolled. Evidence is the policy configuration, enrollment reports for administrator accounts, and failed-login logs showing the second factor was checked.

WAF in detection mode with no review

A web application firewall that logs attacks but never blocks them meets neither the protection nor the monitoring expectation. The opposite failure is equally common: blocking is turned on, but nobody reviews the blocked events, so false positives and real attacks go unexamined. Close the gap by setting rules to block for the high-confidence sets, documenting exceptions, and reviewing blocked events on a set cadence. Evidence is the rule configuration showing the blocking mode, the review log with reviewer and date, and tickets for tuned exceptions.

Unmanaged exposed services in cloud accounts

Cloud accounts accumulate public IP addresses, load balancers, storage endpoints and test instances that were created outside the normal deployment path. An assessor who asks for the list of internet-facing resources often receives an incomplete answer. Close the gap by inventorying every externally reachable resource from the cloud provider's API, assigning an owner to each, and alerting when a new public endpoint appears. Evidence is the exported inventory with owners, the alert configuration, and the records of approved public endpoints.

Vendor access paths missing from the inventory

Vendor support tunnels, managed service jump hosts and partner VPNs are boundary crossings that many organizations never list alongside their firewall rules. When the boundary inventory omits them, the assessor cannot test them. Close the gap by recording every third-party access path with its owner, approver, allowed systems and expiry, and by requiring the same second factor used for administrators. Evidence is the boundary inventory showing vendor paths, the signed access approvals, and logs of vendor sessions tied to named accounts.

CC6.6 boundary protection questions buyers ask before hiring help

How much effort does CC6.6 take for a small SaaS team?

For a small team, the effort is mostly in defining the boundary, writing down how external access is restricted, and producing evidence that the rules are in place and reviewed. The criterion does not ask for a particular product, so the work scales with how many entry points your system has: public web endpoints, APIs, administrative consoles, VPN or bastion access, and any third-party connections. A single-application SaaS with one cloud account and a managed load balancer has far fewer boundary decisions than a platform with several environments. Ask a prospective partner to list the entry points they would cover and the evidence each one produces before you agree on effort.

Do open-source firewall and WAF tools satisfy the boundary protection control?

Open-source tools can produce much of the evidence for CC6.6, but no tool satisfies a SOC 2 criterion on its own. The auditor tests whether your organization restricts external access, protects credentials, requires additional authentication for remote access, and operates boundary systems that are configured and monitored. Coraza, a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and OPNsense, a stateful packet filter with rule logging, can each support part of that story. Your own policies, change records and review of rule match logs are what turn configuration into controlled operation. Confirm with your auditor which artifacts they expect before you choose tools.

How long does the boundary work take, and what drives the timeline?

The timeline depends on how much of the boundary is undocumented today and how many systems sit behind it. The main drivers are the number of external entry points, whether firewall and WAF rules already exist as code or only as console settings, how mature your MFA rollout is for remote and administrative access, and how quickly your team can review rule logs and approve changes. Work that is already in place mostly needs documentation and evidence capture. Work that requires new rule sets, new identity flows or migrating credentials usually takes longer and should be agreed as a fixed scope with written deliverables before work starts. Ask for a timeline that lists each dependency separately.

What does the work need from our internal team?

Three internal roles matter most. An engineer who knows your network paths and cloud security groups must confirm the boundary map. A security or IT owner must approve the rule set, the exception process and the review cadence. A system owner must accept the change records that show how rules are modified. Your team also needs access to logs and change tools so evidence can be pulled during the observation period. Without these people available, the implementation partner can prepare configurations, but the organization still owns the controls and their operation. Confirm the time commitment for each role in the written scope.

Can our auditor help configure the boundary?

Generally no. An independent CPA firm performing the SOC 2 examination tests your controls and issues the report, and it should not design or operate the controls it later tests, because that would compromise its independence. An auditor can explain the evidence it expects and review your description of the system. Configuration, hardening and evidence preparation are normally done by your team or an implementation partner. Confirm with your chosen CPA firm which preparation services it can offer without affecting independence before you assign that work.

Is penetration testing required for CC6.6?

The criterion does not name penetration testing as a required activity, so the answer depends on how you demonstrate that boundary protections work. Auditors commonly look for evidence that external access is restricted and that boundary systems are monitored and reviewed, and a periodic external test of the boundary can support that evidence. Application and API security testing can also show whether a WAF rule set blocks the attacks it is meant to block. Ask your auditor whether it expects a test report for this criterion and what scope it considers adequate. A testing partner can scope and run that work separately from the examination, and the findings remain yours to track and remediate.

How DeployOpen scopes and prepares CC6.6 evidence

DeployOpen works on CC6.6 Boundary protection by agreeing a written scope for the external access paths, firewalls and remote authentication in your environment, then building and documenting those controls inside your own infrastructure. We prepare the systems and evidence an assessor will request, but the organization owns its controls and only an independent CPA firm issues the SOC 2 report.

How we scope

Map every route from outside the system boundary, including public endpoints, VPN entry points, admin consoles and third-party integrations.
Record which boundary systems, such as firewalls and web application firewalls, are in scope and which cloud or hosting provider controls they depend on.
Agree deliverables, timelines and responsibilities in writing before work starts, since engagements are fixed-scope.

How we build

Configure firewall rule sets with documented source, destination, port and protocol logic, using aliases for address groups and logging enabled for review.
Deploy self-hosted identity controls that require additional authentication for remote and external access, such as TOTP, WebAuthn or passkeys.
Harden credential storage and session handling for administrative and external logins so that protected credentials are not exposed at the boundary.

How we hand over

Document each boundary control with its configuration, owner and the criterion points of focus it supports, so an assessor can trace design to implementation.
Provide exported rule sets, authentication policy settings, change records and sample log extracts that show the controls operated during the period.
Walk your team through the evidence index and the open items to confirm with your auditor before fieldwork begins.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, so boundary rules and authentication settings stay current between audits.
Review rule changes and new external exposures on a schedule agreed in the retainer, and update the documentation when the system changes.
Confirm with your CPA firm which evidence samples and time periods they need, since the auditor sets the testing approach for a Type 2 report.