Control statement
Maintain a separate execution domain for each executing system process.
Discussion
Systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. Process isolation technologies, including sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. Process isolation helps limit the access of potentially untrusted software to other system resources. The capability to maintain separate execution domains is available in commercial operating systems that employ multi-state processor technologies.
From control text to operational evidence
Use Process Isolation as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure architecture, boundary protection, communications protection, cryptography, and system isolation.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- network and trust-boundary diagrams
- firewall and gateway configurations
- cryptographic configuration and key records
- segmentation and isolation test results
Common failure patterns
- diagrams omit cloud and third-party paths
- encryption enabled without key governance
- flat trust zones allow unnecessary lateral movement
- boundary rules accumulate without owner review
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
a separate execution domain is maintained for each executing system process.
Examine
- System design documentation
- system architecture
- independent verification and validation documentation
- testing and evaluation documentation
- other relevant documents or records
Interview
- System developers/integrators
- system security architect
Test
- Mechanisms supporting and/or implementing separate execution domains for each executing process
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
SC-39(1) — Hardware Separation
Implement hardware separation mechanisms to facilitate process isolation.
Official discussion
Hardware-based separation of system processes is generally less susceptible to compromise than software-based separation, thus providing greater assurance that the separation will be enforced. Hardware separation mechanisms include hardware memory management.
Assessment objectives and methods
hardware separation is implemented to facilitate process isolation.
Examine
- System and communications protection policy
- system design documentation
- system configuration settings and associated documentation
- system architecture
- system documentation for hardware separation mechanisms
- system documentation from vendors, manufacturers, or developers
- independent verification and validation documentation
- system security plan
- other relevant documents or records
Interview
- System/network administrators
- organizational personnel with information security responsibilities
- organizational personnel installing, configuring, and/or maintaining the system
- system developers/integrators
Test
- System capability implementing underlying hardware separation mechanisms for process separation
SC-39(2) — Separate Execution Domain Per Thread
Maintain a separate execution domain for each thread in [Organization-defined: multi-threaded processing].
Official discussion
None.
Organization-defined parameters (1)
Assessment objectives and methods
a separate execution domain is maintained for each thread in [Organization-defined: multi-threaded processing].
Examine
- System and communications protection policy
- system design documentation
- system configuration settings and associated documentation
- system architecture
- list of system execution domains for each thread in multi-threaded processing
- system documentation for multi-threaded processing
- system documentation from vendors, manufacturers, or developers
- independent verification and validation documentation
- system security plan
- other relevant documents or records
Interview
- System/network administrators
- organizational personnel with information security responsibilities
- system developer
- organizational personnel installing, configuring, and/or maintaining the system
- system developers/integrators
Test
- System capability implementing a separate execution domain for each thread in multi-threaded processing
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.