SC-7 Boundary protection: requirements and evidence

What SC-7 boundary protection requires and why it is hard to evidence

When an assessor or customer asks for SC-7 evidence, they want proof that the system monitors and controls communications at its external boundary and at key internal boundaries, that publicly accessible components sit in separated subnetworks, and that connections to outside networks pass only through managed interfaces arranged according to the organization's security and privacy architecture. In plain terms, every door between your system and the rest of the world, and between the sensitive parts of your own environment, has to be known, controlled and watched. The control is not satisfied by having a firewall. It is satisfied when you can show which doors exist, what each one lets through, who approved that rule, and what happens to traffic that does not match it.

The risk behind the control is easy to describe. In a flat network, a compromised web server, a forgotten test host or a vendor VPN can reach the database, the directory and the backup system without anyone deciding that it should. Unmanaged paths, such as a second internet connection, a dual-homed server or a remote access tool installed outside the approved design, let traffic bypass the inspection point altogether. Attackers depend on this kind of lateral movement, so an assessor will look for evidence that the organization has decided where traffic may flow and has tested whether it actually does.

SC-7 is hard to evidence because it draws on several sources that rarely live in one place. The firewall or policy engine holds the rules, the segmentation design lives in network diagrams and the security architecture document, and the traffic monitoring layer shows whether anything was denied, allowed or missed. Each source can be correct on its own and still disagree with the others. Before any engagement, confirm with your assessor which artifacts they will sample, whether they expect the list of key internal boundaries to match the live rule base, and how they will test that the boundary protection hardware and software enforce the documented design. Those answers determine how much of the evidence must be generated automatically and how much can be written by hand.

Which interfaces, zones and third parties SC-7 covers in your system

SC-7 applies wherever your system meets another network, and the boundary decisions you make in scoping determine which enhancements your assessor tests. Start by listing every managed interface, then match each one to the SP 800-53B baseline or FedRAMP class that governs your system. The organization owns these decisions even when an implementation partner builds the boundary.

External internet edges

Every point where your system accepts traffic from the public internet is a managed interface under SC-7. Inventory each one, including load balancers, reverse proxies, public API gateways and remote management endpoints that were opened for a single project and never removed. For each edge, record which traffic is permitted, which component inspects it and who approved the rule. Assessors commonly start here because a forgotten public address is the fastest way to find a gap.

Key internal boundaries

SC-7 asks you to monitor and control communications at key internal boundaries, not only at the internet edge. Typical examples include the line between production and corporate networks, between development and production, and between environments that hold different data classifications. Document each boundary as a named item in your system design documentation, because the assessment procedure for SC-7 expects a list of key internal boundaries to examine. Missing items here are a frequent source of findings.

DMZs and publicly accessible components

Components that must be reachable from outside, such as web front ends, mail relays or public DNS servers, belong in a physically or logically separated subnetwork. Confirm that these components cannot initiate connections into internal zones except through named, inspected paths. Record the DMZ design in your architecture documentation and test it with a scan from outside and from the DMZ toward the internal network, keeping the results as evidence.

Cloud VPC and VNet edges

In cloud deployments, the boundary is usually a virtual network, its routing tables, security groups, network access control lists and gateways. Each of these is a place where traffic is allowed or denied, so each must be in scope and documented. Ask your cloud team to export the rule sets as configuration evidence and confirm that no rule permits all sources and all ports. Cloud-native rules change frequently, so assessors will expect a process that keeps the documentation current.

VPN and remote access entry points

Remote access gateways, VPN concentrators and jump hosts create inbound paths into internal networks, and they are often overlooked because they are treated as user tools rather than boundary devices. Include them in the boundary inventory, define which user groups and source networks may connect, and log each session. Confirm with your assessor how they will test deny-by-default behavior on these entry points, since they are a common path for lateral movement.

Third-party and external network connections

Connections to vendors, partners, payment processors or government networks cross your boundary even when no one on your side calls them an interface. List each one with its owner, the traffic it carries, the allowed direction and the approved rule. Where an agreement governs the connection, the agreement and its technical rules should match. Confirm the scope with your assessor before work starts, because third-party links often change which zones count as part of the system.

Baseline and FedRAMP class decisions

The SP 800-53B baseline sets the minimum: SC-7 is in the low, moderate and high baselines, and the moderate baseline adds enhancements such as SC-7(3), (4), (5), (7) and (8). For cloud services assessed under FedRAMP Rev5, the class adds more enhancements, including SC-7(12) and (18) at Class C and (20) and (21) at Class D. Confirm your baseline and class in writing before designing rules, because the enhancement list determines how much evidence you must produce each year.

How the SC-7 enhancements layer on the base control

Most of the SC-7 work sits in its enhancements, not the base control. In Release 5.2.0, SC-7 has one organization-defined parameter and 29 control enhancements, of which 26 are active and 3 are withdrawn. The base control requires monitoring and controlling communications at external and key internal managed interfaces, placing publicly accessible components in separated subnetworks, and connecting to external networks only through managed interfaces. Each enhancement narrows that requirement, for example by restricting how traffic is split, how connections are denied by default, or how interfaces are managed. An assessor will test the base control and whichever enhancements your baseline or class selects, so the first decision is which set applies to the system.

The SP 800-53B moderate baseline selects SC-7(3), (4), (5), (7) and (8). The high baseline adds SC-7(18) and SC-7(21), and the privacy baseline selects SC-7(24). Enhancement (3) concerns limiting access points to the managed interfaces, (5) concerns denying network traffic by default and allowing it by exception, and (7) concerns preventing split tunneling for remote devices. Enhancement (24) is the privacy baseline's addition for personally identifiable information. Because these selections come from the baseline, a system categorized at moderate impact should expect at least five enhancements in its boundary evidence, and the system security and privacy plan should show how each one is met.

FedRAMP Rev5 adds its own selections. The annual independent assessment rule lists SC-7 at Classes B, C and D, with SC-7(3), (4), (5), (7), (8), (12) and (18) at Class C, and SC-7(3), (4), (5), (7), (8), (12), (18), (20) and (21) at Class D. Confirm the baseline and class for your system against your own authorization package and the current FedRAMP rules, since a Class C or D assessment needs evidence for the longer list. Ask your assessor which enhancements they will test, and reconcile the FedRAMP list with the SP 800-53B selections before you assign owners to each one.

How an assessor tests SC-7: methods, evidence requested and common findings

This table groups the six SP 800-53A determination statements for SC-7 by what each one checks, the assessment method used, the evidence an assessor requests and the findings that appear most often. The examine objects are the list of key internal boundaries, boundary protection hardware and software, enterprise security architecture documentation and system design documentation. Confirm exact statement wording in SP 800-53A before building test scripts, because this table describes each check in plain terms.

Test element	Assessment method	Evidence the assessor asks for	Common findings
Monitoring and control at boundaries: communications watched and filtered at external and key internal managed interfaces	Examine, test	Boundary protection hardware and software configuration, rule exports, monitoring settings	Monitoring enabled but no enforcing rules; internal interfaces not covered
Key internal boundaries: identified, listed and kept current	Examine, interview	List of key internal boundaries, system design documentation, interviews with network owners	Internal boundaries undocumented; list not updated after network changes
Public components: publicly reachable services placed in separate subnetworks	Examine, test	System design documentation, network diagrams, subnet and VLAN assignments for public services	Public services on internal subnets; DMZ exists on paper only
Traffic between public and internal networks: restricted by default	Test	Rule set export, test results showing blocked inbound paths from public to internal networks	Allow-any rules between DMZ and internal networks; rule sets never tested
External connections: reached only through managed interfaces	Examine, interview	Enterprise security architecture documentation, inventory of external connections and their boundary devices	Vendor or direct links that bypass the firewall; connections missing from inventory
Boundary device arrangement: placed as the architecture describes	Examine, test	Enterprise security architecture documentation, device placement diagrams, routing path tests	Architecture shows one design while production routing differs

How to implement SC-7 in order, and what each step produces

This sequence moves SC-7 from an unknown set of network paths to a documented, default-deny boundary that is monitored, tested and reviewed on a schedule an assessor can verify. Each step closes with a named artifact that the assessor will ask to see.

Inventory every external and key internal boundary
The organization's system owner and network engineers list every point where the system connects to outside networks, including internet links, partner connections, cloud VPC peerings, VPN concentrators, and administrative paths. They then identify the key internal boundaries, such as connections between production, development, corporate and management networks. Each boundary is recorded with its owner, the devices or services that enforce it, and the data classes that cross it. The step is complete when the list matches the network diagrams and a second engineer has walked the paths and confirmed nothing is missing. Assessors commonly start with the list of key internal boundaries, so its accuracy determines the rest of the assessment.
Design segmentation and DMZ placement in the architecture
The security architect decides which components are publicly accessible and places them in a separate subnetwork, such as a DMZ, with internal systems kept on networks that cannot be reached directly from outside. The architect records how traffic is permitted to move between zones and which managed interfaces enforce each boundary. This design is written into the enterprise security architecture and the system design documentation, so that the placement is traceable to a decision rather than to how the network happened to be built. The step is complete when the architecture document shows every boundary from the inventory mapped to a zone and an enforcing component.
Write default-deny rule sets with justifications
Network and platform engineers write the rule sets for each managed interface starting from a rule that denies all traffic, then add allow rules only for documented business or technical needs. Every allow rule carries a written justification that names the source, destination, port, protocol, owner and the requirement it supports. Rules are kept under version control so changes produce a history. Tools such as OPNsense can express rules by source, destination, port and protocol, and use aliases for address groups, which keeps large rule sets readable. The step is complete when every allow rule traces to a justification and the deny-all baseline is the last rule on each interface.
Deploy monitoring and validate rules and logs
Engineers enable logging of rule matches at each managed interface and deploy network and protocol monitoring where it adds visibility, such as Suricata's EVE JSON output for alerts and protocol transactions or Zeek connection and protocol logs. Coraza or a similar web application firewall can be placed in front of publicly accessible web services. The team then tests each boundary: it sends traffic that should be allowed, traffic that should be denied, and a sample of unexpected traffic, and confirms that the expected log entries appear with correlated identifiers. Test results and screenshots or exports are retained. The step is complete when each boundary has a test record showing that the rules and logs behave as the architecture describes.
Establish recurring review of rules and boundary changes
The organization sets a review cycle for rule sets, boundary inventory and monitoring coverage, and assigns an owner for each review. Changes to rules or new boundaries go through change control, with an impact review and a check against the justification record. Rules that no longer have a valid justification are removed, and log review findings feed into the risk and plan of action process. Organizations that use an independent assessment should confirm with their assessor how often the review and the test evidence must be refreshed. The step is complete when the review schedule, the signed review records and the change tickets for boundary changes can be produced for any period an assessor selects.

Evidence that passes an SC-7 assessment and how to keep it current

An assessor testing SC-7 wants to see that every managed interface is known, documented, governed by justified rules and monitored over time. The six artifacts below connect those points, and each one goes stale unless its refresh is tied to a routine or to a change record.

Boundary inventory

A current list of every external and key internal managed interface, with the device or service that enforces it, its owner and the networks it separates. Assessors compare this list against the examine object for key internal boundaries, so any boundary missing here becomes a finding. Keep it current by reconciling it with the network inventory on a fixed schedule and by adding an entry whenever a new gateway, VPN concentrator, cloud peering link or DMZ segment is approved. Confirm who signs off each change.

Architecture and system design diagrams

Diagrams showing where publicly accessible components sit, how subnetworks are separated and where traffic enters and leaves. They must match the enterprise security architecture and system design documentation an assessor examines. Keep them current by version-controlling the diagrams next to the configuration and requiring an update in the same change ticket that adds or moves a boundary. A diagram that disagrees with the live rules is often the first defect an assessor finds.

Firewall and policy configuration exports

Exported rule sets from each boundary device, including default deny behavior, aliases, interface assignments and logging settings, with the change history that shows who altered each rule and when. For example, an OPNsense configuration backup can be exported on a schedule and stored under version control. Check that the export captures the live state, not a staged copy, and that a restore from it reproduces the same boundary behavior.

Rule justification records

A short record for each allow rule stating the business purpose, the source and destination, the ports and protocols, the owner, the approver and a review date. Assessors sample rules and ask why a path is open, so an unexplained rule reads as an unmanaged exception. Keep these records current by making a justification a required field in the change ticket, and by flagging rules that have not been reviewed within the agreed period or that point at decommissioned hosts.

Flow and connection logs at managed interfaces

Records of traffic crossing each boundary, such as Zeek connection logs or Suricata EVE flow and alert records, showing who connected, over which protocol and whether the connection was permitted. These show that monitoring operates at managed interfaces and that denied traffic is visible. Confirm with your own retention policy how long records are kept, forward them to a central store, and test periodically that a sampled connection can be traced from the boundary device to the monitoring record.

Boundary test results

Results from testing that the boundary blocks what the rule set says it blocks, including external scans, attempts to reach internal subnetworks from the DMZ and checks that publicly accessible components cannot initiate inbound paths into internal networks. Record the test scope, date, tester, findings and remediation tickets. Repeat tests after each significant boundary change and at the cadence the assessment plan sets, and keep the results alongside the rule justification records they validate.

What meeting SC-7 costs in money and effort

This table compares the main cost components of meeting SC-7, who is paid for each, whether it recurs, what pushes it up and how to reduce it. Costs scale with the number of boundaries, the enhancement scope and how often rules change, so request an itemized quote from a written scope before comparing options.

Cost component	One-time or recurring	What drives it up	How to bring it down
Firewall and boundary licenses or subscriptions	Recurring (annual or term renewal, plus hardware refresh if appliances are used)	Number of boundary points, throughput needs, and commercial add-ons such as threat signatures or managed rule sets	Use open-source enforcement such as OPNsense, Suricata and Coraza to remove license spend, then budget for the staff and support time they still need
Architecture and engineering time	One-time for the initial boundary design, then recurring for each new interface or zone	Undocumented legacy paths, many external connections, and unclear ownership of the security architecture	Define a boundary inventory and reference architecture early so new connections follow a repeatable pattern
Rule and documentation upkeep	Recurring, tied to every rule change, review cycle and ruleset update	High rule churn, rules without business justification, and rule sets kept only in appliance consoles	Keep rules in version control with owner, purpose and review date, and enforce deny-by-default so exceptions are explicit
Log collection and review	Recurring for storage, log pipeline operation and analyst time	Verbose logging on every rule, full packet or protocol capture, and no retention plan	Log only what supports SC-7 monitoring, set retention by policy, and route alerts to one review queue
External penetration testing or architecture review	Recurring, usually tied to assessment cycles and significant changes	Large external attack surface, many public-facing components, and multiple environments in scope	Scope tests to the boundary inventory, share current diagrams and rule exports beforehand, and fix known findings before the test
Assessor and auditor sampling time	Recurring, with the assessment cycle	Missing or inconsistent evidence, manual screenshots, and rules that cannot be traced to an approved requirement	Produce repeatable exports of rules, diagrams and logs, and keep an evidence index mapped to each SC-7 part
Internal control owner time	Recurring	Ownership split across network, security and application teams	Assign one accountable owner for each boundary and a named reviewer for changes

Which open-source tools produce SC-7 evidence

SC-7 is tested by showing that traffic crossing a boundary is controlled, inspected and recorded. The four tools below each cover a different part of that picture: the rule set at the edge, the network records behind it, and the web layer in front of applications. Your assessor will decide whether the combination meets your own boundary design.

OPNsense packet filtering

OPNsense is a stateful packet filter, so it is a natural place to show deny-by-default rules at the managed interface. Rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so the rule set stays readable. Enable per-rule logging on the rules an assessor will examine, then check that the live log view shows the matches you expect. Confirm with your assessor that the exported rule configuration satisfies their request for boundary documentation.

Suricata traffic and alert records

Suricata inspects traffic at the boundary and writes its output in EVE JSON, covering rule alerts, flows and protocol transactions such as HTTP, DNS and TLS. Evidence of monitoring at managed interfaces depends on keeping those records, so plan where the EVE file goes and how long it is retained. Splitting the output into separate files can make it simpler to route each record type into a log management tool. Confirm the license terms with your legal or procurement team before distribution.

Zeek connection and protocol logs

Zeek records network activity as structured logs, and conn.log shows which hosts communicated, for how long, how much data moved and over which protocol. Its dns.log, http.log and weird.log are linked through a unique connection identifier, which helps an assessor trace a single session across records. This is useful evidence for internal segmentation, where you need to show that traffic between zones follows the documented rules. Confirm with your assessor whether passive logs of this kind satisfy their sampling expectations.

Coraza web application firewall

Coraza protects web applications at the layer in front of them, and it is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It targets attacks such as SQL injection, cross-site scripting and code injection, which matter when a DMZ publishes an application to untrusted users. Integrations exist for Caddy, HAProxy, Traefik and Nginx, so the choice of reverse proxy shapes how the evidence is produced. Confirm the rule set version and tuning decisions with your assessor before relying on blocking results.

Who does what for SC-7: your team, a partner and the auditor

Your organization owns SC-7. The boundary is a statement about your risk, so the decisions about what sits outside the boundary, which services may cross it and which exceptions are acceptable belong to people who are accountable for the system. A partner can propose options, but the rule set only means something when your security owners have reviewed each allow rule, written down why it exists and approved changes to it.

Boundary decisions: Confirm which interfaces are managed, which components are publicly accessible and which internal boundaries need enforcement.
Rule justifications: Keep a recorded business or technical reason for every allow rule, with an owner and a review date.
Change approval: Approve changes to firewall policy, aliases and logging settings through your normal change process.
Risk acceptance: Decide in writing which residual exposures you accept, and who signs for them.
Architecture ownership: Maintain the network and security architecture documents that describe the boundary.

Before relying on the boundary in an assessment, check that someone in your team can explain every rule without consulting the vendor or partner.

How long SC-7 takes, what it costs and whether to hire help

How much effort does SC-7 boundary protection take to implement?

The effort depends mostly on how many external and internal boundaries the system has, how much of the network is already segmented, and which SC-7 enhancements your baseline or FedRAMP class selects. A single internet-facing application in one cloud account is a very different job from a multi-site environment with several DMZs, partner connections and legacy flat networks. The main drivers are: the number of managed interfaces to document and control, the state of the current firewall and routing configuration, the volume of traffic rules that must be justified case by case, and the logging needed to show that rules are enforced. Ask any provider to break the work into architecture review, rule set rebuild, logging and monitoring setup, and evidence capture, with the systems in scope named for each.

Can our own team implement SC-7 without an outside partner?

Yes, if your team has network engineers who can map boundaries, write deny-by-default rules and produce evidence an assessor can follow. Many organizations do the design and rule work internally and bring in help only for specific gaps, such as logging pipelines or an independent review of the rule base. The questions to answer honestly are whether anyone owns the security and privacy architecture documentation that SC-7 relies on, whether rule changes go through a documented approval process, and whether someone can reproduce the evidence on request. If those are weak, a partner may be cheaper than the rework that follows an assessment finding.

What does SC-7 require from our internal staff?

SC-7 needs staff who understand the system's traffic flows, not just its firewall vendor interface. You will typically need people who can name each external and key internal boundary, explain why each public-facing component sits in a separated subnetwork, and say who approves changes to the rule base. Your architecture documentation, system security and privacy plan and change records must match what is actually deployed. Plan time for interviews during assessment, because assessors test SC-7 partly by asking staff how the boundaries work. Named owners for firewalls, proxies, DNS and monitoring tools reduce delays when evidence is requested.

How does an assessor sample boundary protection evidence?

An assessor works from the documented boundaries and tests whether the deployed controls match them. Under SP 800-53A, SC-7 is assessed through six determination statements using examine, interview and test methods. Typical examine objects include the list of key internal boundaries, the boundary protection hardware and software, the enterprise security architecture documentation and the system design documentation. For sampling, expect the assessor to choose several boundaries, pull the rule sets and logs for each, and check that a sample of denied traffic is blocked and logged. Keep exports of rule sets with change history, architecture diagrams dated to match them and log samples that show rule matches. The exact sample sizes are set by the assessor and your assessment plan, so confirm them before fieldwork starts.

What does a fixed-scope SC-7 engagement with a partner cover?

A fixed-scope engagement covers only the deliverables written into the agreed scope before work starts. For SC-7, a typical scope names the systems and boundaries in scope, the baseline or FedRAMP class being targeted, the enhancements to implement, and the artifacts produced, such as a boundary inventory, rule set documentation, DMZ and segmentation design, logging configuration and an evidence package. The partner prepares systems and evidence. It does not decide whether your controls pass, and it does not issue an assessment report, which only an independent assessor or authorizing body can do. Ask the provider to list what is excluded, including staff interviews, remediation after assessment findings and ongoing rule review, and to state how change requests are priced and approved.

How do we keep SC-7 rules current after the initial work?

SC-7 is not a one-time configuration. Rules drift as applications are added, vendors change addresses and emergency changes are made under pressure. Keeping the boundary current requires a recurring review cycle tied to change management: each new rule needs a documented business reason, an owner, an expiry or review date and a link to the boundary it serves. Log review should check for denied traffic patterns and rules that never match. Recurring costs usually include staff time for reviews, tool maintenance, log storage and an annual independent assessment for FedRAMP-related work. Ask any provider whether ongoing rule review, upgrades and testing are offered as a retainer, and what they include in each review.

How DeployOpen scopes, builds and prepares SC-7 evidence

DeployOpen plans, implements and documents the boundary protection layer of self-hosted open-source platforms inside the client's own infrastructure. We prepare the systems, rules and evidence for SC-7, while the organization owns its controls and an independent assessor decides whether they meet the requirement.

How we scope

Engagements are fixed-scope, with the boundary interfaces, zones and platforms covered agreed in writing before work starts.
The written scope names the external and key internal managed interfaces in the system that SC-7 covers, and the assessment baseline or FedRAMP class targeted.
Scope also records which SC-7 enhancements the client selects, so the deliverables match the assessment obligations the organization must meet.

How we build

We design the public, DMZ and internal subnetwork layout so publicly accessible components are separated from internal networks.
We configure deny-by-default rules on firewalls and managed interfaces, with aliases for address groups and logging enabled for each rule match.
We add inspection sensors and web application filtering where the scope calls for them, then test that blocked traffic is actually dropped and logged.

How we hand over

Deliverables include the boundary architecture diagram, the rule set with its justification, and the list of managed interfaces.
We provide evidence packs that show configuration exports, sample log records and test results mapped to each SC-7 item in the scope.
Handover includes runbooks for rule changes, so the client can show who approved each change and when it was made.

How we support

Ongoing support, upgrades and continuous testing of the boundary are available as retainers, agreed separately from the initial scope.
Retainers can cover periodic rule reviews, log review support and retesting after changes to architecture or platform versions.
The client remains responsible for control ownership, and any assessment report or certification comes only from an independent assessor.

SC-7 Boundary protection