SC-32 System partitioning: requirements and evidence

What SC-32 system partitioning requires and why teams stall on it

SC-32 is a control your organization has to choose on purpose. It sits in no SP 800-53B baseline, so it reaches your system only when you select it through tailoring or an overlay, and the first real task is deciding whether your authorizing official expects it. Once selected, the control asks you to divide the system into defined components and place each one in a separate physical or logical domain or environment, based on circumstances you define. In plain terms, a flat system where a web tier, a payment service, a logging store and an administrative console all share one network and one trust level is the situation this control exists to prevent. A single compromise in that flat design can reach everything.

The work stalls for two reasons. First, the control has three organization-defined parameters that you must fill in: which components are partitioned, which domains or environments they sit in, and which circumstances trigger the partitioning. Teams often skip this step and write vague text, which an assessor will reject. Second, the one enhancement and the single determination statement in SP 800-53A turn the requirement into evidence. The assessor will examine a list of system physical domains or environments, facility diagrams, network diagrams and design documentation, so every component you name must appear in those artifacts and match what is actually deployed. Confirm the current parameter values and enhancement wording in the OSCAL catalog before you draft anything, since the SC-32 text is the authoritative source for what must be defined.

Which systems and third parties fall under SC-32 partitioning

SC-32 is not in any SP 800-53B baseline, so the first scoping decision is whether the organization selected it at all. Once selected, the work depends on which components are partitioned, which domains they sit in, and which shared services cross those domains.

Confirm the control was selected

SC-32 applies only when the organization selects it through tailoring or an overlay, because SP 800-53B does not assign it to the low, moderate, high or privacy baseline. Record the selection and its rationale in the system security and privacy plan, and confirm whether the authorizing body or contract requires it. FedRAMP's Rev5 baselines do not require SC-32 at Class B, C or D, so a FedRAMP scope will not pull it in by default. Ask the assessor to confirm this before planning evidence.

Define the partitioned components

The control asks the organization to name the components of the system that are placed in separate domains and the circumstances that trigger that placement. Build an inventory of applications, databases, management consoles, logging and backup services, and mark which ones have distinct security needs. Components with different impact levels or data classes are the usual candidates for separation, but the decision is the organization's to document.

Map physical and logical domains

Decide which physical sites, data halls, networks, VLANs, Kubernetes namespaces or hypervisor clusters count as separate domains, and where each component sits. Assessors examine the list of system physical domains or environments, facility diagrams and network diagrams, so these documents must match the running system. Where a logical domain relies on shared hardware, state that dependency clearly, since the separation then rests on software controls.

Cloud accounts and VPCs

In cloud deployments, separate accounts, subscriptions, projects and VPCs are often the most visible domain boundaries. Check which accounts hold production, management, logging and development workloads, and whether cross-account roles, peering or transit routes bridge them. Each bridge is a point where the partition can be weakened, so list it in the design documentation and tie it to the boundary rules that SC-7 covers.

Hosted and third-party components

Managed databases, SaaS identity providers, hosted CI runners and vendor monitoring services may sit outside the organization's own domains. Decide whether each one is part of the system boundary and, if so, which domain it occupies. Where a vendor operates the component, request its architecture and tenancy documentation and confirm that the organization can still evidence the separation it claims.

Shared services that cross domains

Directory services, DNS, time sources, backup targets, container registries and centralized logging often serve several domains at once. These shared services are where separation is most likely to fail, because a single compromised component can reach every domain it serves. Document which shared services cross domains, what traffic they carry, and which controls, such as the boundary rules, access enforcement and audit logging, limit their reach.

How an assessor tests SC-32 partitioning

This table walks through how an SP 800-53A assessment of SC-32 moves from its single determination statement to examine, interview and test activities. Read each row as one step the assessor takes and the artifact or observation that closes it. The main takeaway is that domain lists and diagrams must match the running system, because assessors compare documents against live configuration.

Assessment step	What the assessor does	Evidence or finding to expect
Determination statement	Confirms the organization defined the domains and partitions components based on its security needs	Defined domain list and a partitioning decision tied to security categorization
Examine: domain list	Reviews the list of system physical domains or environments	Named domains with owners, purposes and assigned components
Examine: facility diagrams	Checks facility diagrams for the physical separation the domain list claims	Facility drawings showing where each domain sits and how it is secured
Examine: network diagrams	Compares network diagrams against the domain list and the stated boundaries	Diagrams showing each domain, its gateways and approved connections
Examine: design documentation	Reads design documents for why each component is placed in its domain	Design rationale linked to defined circumstances and impact level
Interview	Talks with system owners, network engineers and facility staff about how domains are created and changed	Answers that match the documents and recent change records
Test	Verifies that components in one domain cannot reach another except through approved paths	Firewall rule exports, routing or VLAN settings and traffic test results
Common finding: undocumented domain	Finds a segment or environment in production that appears in no list or diagram	Inventory reconciliation against discovered networks, hypervisors and cloud accounts
Common finding: stale diagrams	Finds diagrams that show a design the running configuration no longer matches	Diagrams regenerated from configuration, with change records explaining each difference

Implementing SC-32 in seven steps

This sequence takes an organization from deciding whether SC-32 applies to its system through to a reviewed, tested partition with records an assessor can follow. Each step names the output that lets the next one start.

Decide whether SC-32 applies through tailoring
SC-32 is not in any SP 800-53B baseline, so the first decision is whether your authorizing official or control owner selects it during baseline tailoring. Record the selection and the reason in the system security and privacy plan, whether the reason is a risk finding, a contract clause or a design choice. Ask your assessor or authorizing body whether they expect the control for your impact level. The step is done when the selection and its rationale are written down and approved by the person who owns the risk.
Define the components and separation triggers
SC-32 leaves the components and the circumstances to the organization through its organization-defined parameters, so you must set both. List the components that hold different sensitivity levels, such as production data stores, administrative tooling, build systems and public-facing services. Then write down the defined circumstances that call for separation, such as a change in data classification, a regulatory boundary or a shared-trust risk. The output is a short parameter table that an assessor can compare against the system design.
Map each component to a domain
For every component in the parameter table, state the physical or logical domain it sits in, such as a separate network segment, a hypervisor cluster, a Kubernetes namespace or a separate cloud account. Note which domain boundary controls cross-domain traffic, which is usually handled through the boundary protection controls in the SC family. The output is a component-to-domain register that matches the actual inventory. Check it against the configuration management records so that no component appears in two domains without a reason.
Implement the separation in the infrastructure
Build each domain using the mechanisms your environment supports, such as VLANs or VRFs for logical networks, separate hosts or hypervisor clusters for physical separation, and firewall rules that permit only the flows you have documented. Open-source options such as OPNsense can enforce rules between segments with aliases for each domain, and Falco can detect unexpected network connections between workloads at runtime. Confirm each mechanism with your platform team before you rely on it. The step is done when each component is provisioned in its assigned domain and the blocked paths fail in testing.
Document diagrams and design records
Assessors examine the list of physical domains or environments, the facility diagrams, the network diagrams and the design documentation, so these must agree with each other and with the running system. Produce a current network diagram, a domain list and a short design note that explains why each separation exists and how traffic crosses between domains. Store them under change control so every change updates the records. The output is a document set that a reviewer can use to trace a component from its requirement to its domain.
Verify separation with tests and evidence
Test the separation the way an assessor will: examine the documents, interview the people who run the domains, and test that a component in one domain cannot reach a component in another except through documented paths. Run connectivity tests from each domain, review firewall rule logs, and check that any gateway between domains enforces the rules you wrote. Record the test date, the tester, the result and any gap. Gaps go into the plan of action and milestones with an owner. The step is done when every test result is filed and every failed test has a tracked remediation.
Set a review cycle for the partition
Partitions drift as systems are added, merged or retired, so set a review cycle that your organization's policy and procedures define under the SC-1 policy controls. At each review, compare the component register against the current inventory, rerun the separation tests, and confirm that the defined circumstances still justify each domain. Trigger an out-of-cycle review after any significant architecture change. The output is a dated review record that shows the partition was checked and what changed.

How diagrams and configuration prove partitions to an assessor

An assessor does not accept a partition because the organization says one exists. A documented domain is a statement on paper: a list of physical domains or environments, a facility diagram, a network diagram and design documentation. An enforced domain is one where the configuration actually stops traffic, access and processes from crossing the boundary. SC-32 asks for both to agree. The assessment procedure for SC-32 in SP 800-53A Release 5.2.0 uses examine, interview and test methods, and its examine objects include the list of system physical domains or environments, the facility diagrams, the network diagrams and the design documentation. The reader's job is to trace one domain from the list to the diagram to the device that enforces it, and to confirm each link holds.

A practical walk-through starts with the domain list and picks one domain, for example a management enclave. The assessor then checks that the network diagram shows the same subnets, VLANs or clusters, and that the firewall rule export from a tool such as OPNsense shows deny-by-default rules between that domain and its neighbors, with aliases matching the diagram's address groups. For container or Kubernetes partitions, the equivalent evidence is namespace, network policy and node pool configuration. The test method asks whether a host in one domain can reach a host in another on a path the diagram does not show. Diagrams are a starting point, and a single exported rule set or screenshot does not prove the whole partition. Confirm which configuration is authoritative and how the assessor will sample it.

Diagrams drift unless they move through change control. Each change that adds a subnet, moves a workload or opens a rule should update the diagram, the domain list and the affected configuration in the same ticket, and the review should check all three. Ask who owns each artifact, how often the diagrams are reconciled with live configuration and whether those reconciliations are retained. Open-source tools can help, since configuration exports can be committed to version control and compared over time, but no single tool proves that a partition holds. Runtime detection, such as Falco rules for unexpected network connections, shows behavior that the rules did not expect, which supports the enforcement claim without replacing it. Confirm with your assessor which mix of design documents, configuration exports and sampled tests they will accept before you build the evidence set.

Evidence that passes SC-32 and how to keep it current

An assessor testing SC-32 starts from documents that describe the partitions and checks that the running system matches them. The cards below cover the artifacts that carry that proof and the routine that keeps each one accurate between assessments and after major changes.

List of system physical domains

This is the primary artifact for the examine method. It names each physical domain or environment the system uses, such as a separate data center hall, a dedicated rack, or an isolated enclave, and states the security reason each one exists. Check that every component in the system inventory maps to exactly one domain and that the list matches the organization-defined circumstances used to justify partitioning. Illustrative: a list that names a production enclave but omits the backup site will fail review.

Facility and network diagrams

Facility diagrams show where each domain physically sits, while network diagrams show how logical segments, VLANs and subnets are bounded. Assessors compare these against the domain list to confirm nothing sits outside the documented partitions. Date each diagram, record its author and approval, and reconcile it against a current export of the network state rather than the design intent from the original build.

System design documentation

Design documents explain why the partitions exist and how components are placed into them, including the trust assumptions behind each domain. Keep the rationale tied to the organization-defined parameters for SC-32 so the reasoning is traceable. Confirm the document names the control enhancement the organization selected, and record any tailoring decision that removed the control from scope.

Firewall rule exports and change records

Rule exports prove that the boundaries between domains are enforced, not just drawn. Export rules from each firewall on a fixed schedule and keep the export with a hash or timestamp so it can be compared later. Change records link each rule addition or removal to an approved request, showing that partition boundaries changed under control. Tools such as OPNsense can log rule matches, which supports the review evidence an assessor may request.

Refresh triggers between audits

Partition evidence goes stale when workloads move, a cloud account is added, or a new site comes online. Define triggers that force a refresh: any new domain, any change to placement of a component across domains, and any change to the boundary rules. Assign an owner and a review date to each artifact so the set is updated before the next assessment rather than reconstructed for it.

Reconciliation after major changes

After a major change, such as a platform migration or a merge of two environments, compare the new diagrams and rule exports against the domain list and record every difference. Each mismatch needs either a corrected artifact or a documented decision explaining why the partition changed. Confirm with your assessor which level of change they expect to see documented, since requirements for change scope come from the organization's own assessment plan.

What meeting SC-32 costs in money and effort

This table breaks down the cost and effort components of partitioning a system under SC-32, who is paid for each, and whether it is one-time or recurring. Use it to build a written scope and to ask each bidder for the same line items. No figures are given because none are supplied for this control.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Domain definition and enclave design	Internal architects, with optional outside design help	One-time, revisited on change	Number of defined domains and how many circumstances trigger partitioning
Network and cloud segmentation work	Platform engineers or an implementation partner, plus cloud or data center staff	One-time build, then recurring changes	Cloud or on-premises setting, number of subnets, accounts or VLANs, and interconnect rules
Firewall and filtering licenses or hardware	Vendor or open-source project; hardware or virtual appliance spend	License recurring if commercial, hardware one-time with refresh	Commercial versus self-hosted tooling such as OPNsense, and the number of enclave boundaries
Diagrams and system design documentation	Internal staff or implementation partner	Created once, updated on every topology change	Frequency of network change and whether diagrams are generated from configuration
Evidence upkeep and change review	Internal compliance and engineering staff	Recurring, usually tied to change cycles	Change frequency, logging of rule matches, and how many systems share each domain
External review and assessor sampling	Independent assessor or auditor, who issues any report	Recurring at each assessment cycle	Number of domains sampled, evidence quality, and how well diagrams match live configuration
Re-partitioning after incidents or growth	Internal teams or implementation partner under a new written scope	Occasional, scoped per change	Scale of rework, number of dependent services, and downtime windows

Open-source tools that support SC-32 evidence

OPNsense (BSD-2-Clause) is a stateful packet filter that can enforce separation between the network domains an organization defines. Its rules pass, block or reject traffic by source, destination, port and protocol, so a rule set can express which domain may talk to which, and in which direction. Aliases let the team group addresses for each domain, which keeps rules readable when a domain holds many hosts. Per-rule logging records each match, so the same rule set that enforces a boundary can also produce a record of what crossed it.

Domain-based aliases: Group the addresses of each defined domain into named aliases so rules refer to domains rather than individual hosts.
Default deny between domains: Write explicit pass rules for permitted flows and end with a block rule, so undefined paths between domains are refused.
Per-rule logging: Enable logging on rules that cross domain boundaries and retain those logs under the organization's retention settings.
Live log review: Use the live log view during testing to confirm that a blocked flow appears where the design says it should.
Exported configuration: Keep the rule configuration under version control so an assessor can compare it with the system design documentation.

Confirm with your own network team how the firewall is deployed, since a single firewall, a pair in high availability and a virtualized instance each change where the boundary sits. Check that the diagrams you give an assessor match the rules actually running on the device.

Common gaps that fail SC-32 and how to close them

Most SC-32 findings are not missing firewalls. They are partitions that exist in someone's head but not in the documentation, diagrams, rules or change process. The cards below cover the gaps assessors find most often and a fix for each.

Undocumented physical and logical domains

SC-32 asks for a defined list of the system's physical domains or environments, and SP 800-53A makes that list an examine object. Many systems have production, management, backup and development zones that were never written down as domains. Inventory every network segment, VLAN, Kubernetes namespace, VM host cluster and cloud account that holds system components, then record the purpose, the components inside, and the security reason each one is separate. Ask your assessor which level of detail they expect before you finish.

Diagrams that drift from the live network

Facility diagrams and network diagrams are examine objects for SC-32. A diagram drawn at deployment becomes wrong after the first firewall change, a new cloud subnet or a retired hypervisor. Assessors compare diagrams with configuration exports and will notice when a domain shown on paper has no matching rules, or when live hosts appear in no diagram. Tie diagram updates to the change process, and regenerate network views from exported firewall or cloud configuration where you can, so the drawing and the running system are checked against each other.

Partitions defined only in policy

A policy that says management traffic must be separated is not evidence of partitioning. Assessors test the mechanism, so they look for the VLAN, subnet, security group, firewall rule or hypervisor boundary that enforces the separation. Where a partition is claimed, trace it to an enforcing control: a rule set that denies traffic between domains by default, or a host placed in a separate cluster. OPNsense rules with aliases for each domain's address group, logged for review, give a concrete artifact to show the enforcement is in place and in use.

Shared services that cross domains unreviewed

Directory services, logging collectors, backup servers, DNS resolvers and CI runners often sit in one domain yet serve several others. Each shared service that crosses a boundary is a potential path between domains that the partition design did not account for. Maintain a register of shared services with the domains each one touches, the ports and protocols it uses across the boundary, and the reviewer who approved the crossing. Require that review again whenever a new consumer domain is connected to an existing service.

No defined trigger for partitioning

SC-32 requires partitioning based on defined circumstances, and an assessor will ask what those circumstances are. Without them, teams separate systems inconsistently and cannot explain why one workload sits in a shared network while another is isolated. Write the triggers down, for example a change in data classification, a new external connection, a new trust level for users, or a regulatory scope change. Then record each decision against the trigger that caused it, so the partition design can be shown to follow the organization's own rules.

Container and cluster boundaries left implicit

Containers that share a host kernel, namespaces that share a node pool and cloud accounts that share a network are often treated as separate domains without evidence. Document which runtime boundaries you rely on as partitions and which you do not, and state the enforcement for each. Falco can produce runtime evidence of unexpected network connections or privilege escalation across workloads, which helps show that a claimed boundary holds in operation. Confirm with your assessor whether runtime monitoring counts toward the partition evidence they will accept.

SC-32 questions buyers ask before hiring help

Is SC-32 system partitioning required by FedRAMP?

No. FedRAMP's Rev5 baselines do not require SC-32 at Class B, C or D, so a FedRAMP authorization does not by default bring SC-32 into scope. SP 800-53B also does not assign SC-32 to any security or privacy baseline. It applies when your organization selects it through tailoring or an overlay, or when a contract, regulator or internal risk decision names it. Confirm the selection against your system security plan and the FedRAMP control reference for your impact level before you budget for it.

What drives the cost of implementing SC-32?

The cost depends mainly on how many components need separate domains, how many domains already exist, and how much of the environment is documented. Each of these changes the amount of network and identity work, the number of firewall and routing changes, and the evidence to prepare. Your organization pays for its own staff time, licenses and any hardware or cloud accounts. An implementation partner is paid for the scoped work, such as designing the domain model, configuring the boundaries and preparing evidence. Ask any partner for a quote that lists each domain, each system placed in it, the diagrams and documents to be produced, and which items are one-time and which recur, such as annual reviews or diagram updates. DeployOpen does not publish prices. A quote follows from the written scope.

How long does SC-32 partitioning work usually take?

Duration depends on the number of systems being separated, how much of the current architecture is already mapped, and whether separation requires physical changes or only logical ones. A single application with clear network boundaries can be scoped far more quickly than a multi-system estate with shared identity services and legacy flows. Because the work usually involves change windows and testing, plan for the design and evidence work to run alongside production constraints. Your partner should state a timeline in the written scope, with the dependencies that could move it, such as access to diagrams, approvals for network changes and testing windows.

What does the client team need to provide for partitioning?

The work needs accurate knowledge of your system. Expect to provide current network and system design documentation, an inventory of components with their security needs, the data flows between them, and the people who approve changes to firewalls, routing and identity services. Your team must also decide which components belong in which domain, since that is a risk decision the organization owns. Without this input, any partner will be guessing, and assessors will test the gap between the documents and the running environment. Confirm early who in your organization signs off the domain model and who can authorize production changes.

Can we implement SC-32 ourselves without an outside partner?

Yes, if your team already has network architecture skills, change control discipline and the capacity to produce evidence. SC-32 asks you to define the components, place them in separate physical or logical domains based on their security needs, and keep the diagrams and design records that show it. Many organizations handle the design in-house and bring in help only for the parts they lack, such as configuring a self-hosted firewall, building test cases or organizing evidence for an assessor. Whichever path you take, the organization owns the control and its decisions.

Which open-source tools help produce SC-32 evidence?

Open-source tools support the enforcement and the evidence, but they do not decide the domain model. A self-hosted packet filter such as OPNsense can express pass, block and reject rules by source, destination, port and protocol, use aliases for address groups, and log rule matches for review. Falco can detect unexpected network connections and other runtime events in Linux environments, which helps show that domain boundaries hold in operation. Confirm with each vendor which capabilities your version provides and how they fit your architecture. Diagrams and design documentation remain the core artifacts an assessor examines for this control.

What can an implementation partner not do for SC-32?

An implementation partner cannot issue the assessment report, an attestation or a certification. Under the NIST model, your organization owns its controls and decides which domains are needed, and an independent assessor tests the implementation against the SP 800-53A procedures and issues the findings. DeployOpen plans, implements, configures and documents the environment and prepares the systems and evidence for that assessment. It does not issue audit reports, attestations or certifications. Ask any firm you consider to state in writing which deliverables it produces and which decisions remain yours.

Does SC-32 partitioning have to be tested by an assessor?

Yes, if you rely on it for an assessment or authorization. SP 800-53A gives SC-32 one determination statement and asks assessors to examine items such as the list of system physical domains or environments, facility diagrams, network diagrams and system design documentation. Interviews and tests may also apply. Your evidence should therefore show the domains you defined, the reasons for them, and how the running environment matches the documents. Confirm the assessment procedure and expected evidence with your assessor before the work begins so the design records are built to match what they will examine.

How DeployOpen scopes and prepares SC-32 partitioning

DeployOpen plans, implements and documents the separation of your system into defined components and domains for SC-32 System partitioning, inside your own infrastructure. The organization owns the control and its selection, while DeployOpen prepares the systems and evidence that an independent assessor reviews.

How we scope

Confirm with your team whether SC-32 is selected in your baseline, tailoring or overlay before any design work starts.
Record the defined components, the physical or logical domains they must occupy, and the circumstances that drive each split.
Agree the written scope, deliverables and timeline with you in advance, since most engagements are fixed-scope.
Identify which related controls, such as SC-7 and AC-4, your partitions depend on and state how they are covered.

How we build

Implement separate networks, enclaves or hosts using open-source components such as OPNsense rule sets with aliases per domain.
Configure deny-by-default rules between domains and enable logging of each rule match for later review.
Deploy runtime monitoring with Falco rules that flag unexpected network connections crossing domain boundaries.
Test that partitions hold by attempting cross-domain access and recording the results for the assessor.

How we hand over

Produce current network and facility diagrams and a list of system physical domains or environments that match the deployed state.
Document the design rationale for each partition, linking it to the security needs that justified it.
Deliver configuration exports, rule listings and test records that map to the SP 800-53A examine and test methods.
Walk your assessor and internal owners through the evidence so the organization can run its own review of the control.

How we support

Keep diagrams, domain lists and rule documentation current when topology or tenancy changes after handover.
Re-run partition tests after upgrades, new workloads or firewall changes and retain the results.
Offer ongoing support, upgrades and continuous testing as a retainer, agreed in writing separately from the original scope.
Coordinate with the independent assessor when it requests additional evidence, while the organization keeps ownership of its findings.