SC-39 Process isolation: requirements and evidence

What SC-39 process isolation asks for and why it is hard to prove

An assessor asks how one process is kept from reading or changing another, and the team answers with the operating system. That answer is often correct as far as it goes, but SC-39 asks the organization to show that each executing process runs in its own separate execution domain, and to show that the arrangement holds in the systems it actually operates. In plain terms, every process should have its own address space and its own execution context, so a fault or a compromise in one process cannot quietly read memory, alter state or hijack the privileges of another. The risk is concrete: a flaw in a web application, a container or a service account should stay contained to that process rather than spreading to its neighbors on the same host.

Most of the mechanism is inherited. Modern operating systems give each process a private virtual address space and enforce it in hardware, and hypervisors do the same between virtual machines. The organization rarely writes this code, so the control is usually satisfied by the platform. The proof, however, stays with the organization. Assessors examine system design documentation, system architecture and testing and evaluation records, so the team must name the platform and versions in use, state which isolation boundaries it relies on (for example, separate processes, containers, virtual machines or hosts), and show evidence that those boundaries were tested and that exceptions, such as shared memory, debugging interfaces or privileged helpers, are documented and approved. Confirm the exact platform versions and vendor guidance with the vendors and in your own environment, because the isolation claim depends on them.

SC-39 sits in all three SP 800-53B baselines (low, moderate and high), so it applies to nearly every system that is categorized under the framework. Its two control enhancements are not assigned to any baseline, which means an assessor will test the base requirement at every impact level, while the enhancements become relevant only where the organization or a higher-assurance program chooses to adopt them. Plan the evidence for the base control first, then decide whether the enhancements add value for your highest-impact systems. Ask your assessor early which system boundaries and isolation claims they expect to see documented.

Which systems and workloads SC-39 process isolation covers

Process isolation is only as strong as the layer that enforces it, so the first task is deciding which execution layers fall inside the boundary. The cards below walk through the scoping choices that change the evidence an assessor expects, from physical hosts through hypervisors and container runtimes to the management plane. Each choice also pulls in related controls for access, separation and security functions.

Bare-metal hosts

On a bare-metal server, the operating system kernel is the component that gives each process its own address space and execution domain. The organization owns that kernel configuration, its patch level and any kernel modules loaded at boot. Confirm which OS build is in scope, document how process separation is provided, and record whether any privileged daemons run outside the normal isolation model. Assessors will look at system design documentation and architecture to confirm this boundary is described.

Virtual machines and hypervisors

When workloads run in virtual machines, isolation between guests depends on the hypervisor, which is a separate trusted component with its own patching and configuration. Decide whether the hypervisor is inside the SC-39 boundary as a system component, and document its version, hardening and update path. Include how guests share or do not share host resources, since shared hardware features can weaken separation even when each guest is isolated on paper.

Container runtimes and Kubernetes nodes

Containers share a host kernel, so process isolation inside a node depends on namespaces, cgroups, runtime configuration and any additional sandboxing you add. Scope the node pool, container runtime and kernel as one unit, and record which workloads run privileged or with host namespaces, because those settings remove isolation. Runtime monitoring such as Falco can supply evidence that unexpected process behavior is detected, though it does not replace the isolation mechanism itself.

Shared hosts with multiple tenants or data classes

A host that runs workloads for different tenants, or for different data classifications, is where isolation failures carry the most risk. Decide whether each data class gets dedicated hosts, dedicated nodes or only process-level separation, and record that decision as a scoping rule. Assessors will ask how the decision is enforced and tested, so keep placement policies, node labels and exception approvals together as evidence.

Management plane and administrative paths

The hypervisor manager, orchestration control plane, and the tools that push configuration to hosts can each reach every workload they manage. Treat these as components inside the scope, not as external tooling. Related controls SC-2 and SC-3 address separating management functions and protecting security functions, so confirm which administrative interfaces run on separate hosts and which accounts can reach them.

Related control overlaps

SC-39 sits beside AC-3, AC-4, AC-6, AC-25, SA-8, SC-2, SC-3 and SI-16, and assessors will often test them together. AC-3 and AC-6 cover access enforcement and least privilege, AC-4 covers information flow, and SA-8 covers engineering principles. Map each isolation decision to the access and separation control that depends on it, so one design document can answer several findings. Confirm the exact enhancement and baseline text in the catalog before relying on these links.

How an assessor tests process isolation under SP 800-53A

This table breaks down the single SP 800-53A determination statement for SC-39 by assessment object, showing what the assessor checks, the evidence to prepare and the findings that commonly appear. Read each row as a document the assessor will examine, and use the test approach column to plan the technical demonstrations that support it.

Assessment object	What the assessor checks	Evidence requested	Common findings
Independent verification and validation documentation	Whether independent review or testing has confirmed that each process runs in its own execution domain, and whether findings were tracked to closure	Independent test reports, reviewer identity and independence statement, findings log with remediation status	Verification scope excludes the hypervisor, container runtime or kernel that enforces isolation; no independent review on record
Testing and evaluation documentation	Test cases showing that one process cannot read or write another process's memory, and that failed isolation tests were retested	Test plans, scripts, dated results and the configuration tested, including kernel or hypervisor version	Tests run only on a sample host, results not tied to the production build, or no negative test where isolation should fail
System design documentation	Whether the design states the isolation mechanism for each process class (OS process model, containers, virtual machines) and who owns each domain	Security architecture document, process inventory with execution domain assignments, and design decisions for shared components	Design says processes are isolated without naming the mechanism, or lists no owner for shared service accounts
System architecture	Whether the deployed architecture matches the design, including where processes share memory, sockets, volumes or privileged helpers	Architecture diagrams, deployment manifests, host and container configuration exports, and a list of intentional shared resources	Diagrams out of date, undocumented shared volumes or host namespaces, and privileged containers that bypass the stated domain
Examine method (all objects)	Reads each document for completeness and consistency with the others	Document set cross-referenced to the one SC-39 determination statement	Documents contradict each other on which processes share an execution domain
Interview method	Asks system administrators and developers how processes are launched, isolated and changed	Named interviewees, role descriptions and a record of questions answered	Staff describe isolation as a default that nobody verifies after changes
Test method	Runs or observes isolation behavior on the system, such as confirming separate address spaces and blocked cross-process access	Test scripts, command output, logs from the tested host and before and after change records	Testing relies on a screenshot or a single run, with no repeat after patching or upgrades

Implementing SC-39 process isolation step by step

This sequence takes an organization from an undocumented isolation model to a documented, tested and continuously checked set of process boundaries for SC-39. Each step produces an artifact that an independent reviewer can verify.

Confirm the isolation model and boundaries
Start by listing every execution environment in scope: the operating systems, hypervisors, container runtimes and orchestration layers that host system processes, plus any shared tenants or multi-user workloads. For each one, record which mechanism provides separate address spaces and execution domains, such as kernel process isolation, virtual machine separation or container namespaces. The output is a boundary inventory that names each platform, its isolation mechanism, and the owner accountable for it. An independent reviewer should confirm that the inventory matches the system boundary already defined in the security plan and that no in-scope platform is missing.
Document the design in architecture artifacts
Write down how isolation is achieved in the system design and architecture documentation. Describe which processes share a host, which run in separate virtual machines or containers, how memory and execution domains are separated, and where shared kernel or hypervisor dependencies exist, since those are the places isolation can fail. Link each design decision to the boundary inventory from the previous step. The output is an approved design document that assessors can examine. An independent reviewer should check that the documented design describes the systems as actually deployed, not as originally intended.
Configure and harden the isolation layers
Configure the operating system, hypervisor or container runtime to enforce the documented separation. Typical work includes enabling kernel memory protections, restricting container capabilities and privileged modes, setting namespace and cgroup limits, disabling unneeded shared mounts, and applying the vendor or community hardening guidance for each platform. Keep the configuration in version-controlled code so every change is traceable. The output is a hardened configuration baseline for each layer in the inventory. An independent reviewer should confirm that the baseline matches the design document and that changes since the last review are recorded.
Verify isolation through independent testing
Test whether one process or tenant can read, modify or interfere with another's memory, files or execution, and whether a process can escape its container or virtual machine. Use a tester who did not build the configuration, such as an internal independent team or an outside security testing provider, and define the test cases from the design document. Record the commands run, the observed results and any failed cases with their remediation. The output is a test report tied to each boundary in the inventory. An independent reviewer should check that the tests cover every boundary and that failed cases were retested after fixes.
Record results in test and evaluation documentation
Consolidate the test cases, results, defects and retests into the test and evaluation documentation for the system. Map each result to the assessment object it supports, including the design documentation, the architecture and the independent verification records, so an assessor can trace a claim to its proof. Note any residual risk accepted by the system owner and the plan to address it in the plan of action and milestones. The output is a signed evaluation record. An independent reviewer should confirm that the records are complete, dated and reproducible, and that accepted risks have a named owner.
Set up recurring isolation checks
Isolation drifts as platforms are patched, upgraded or reconfigured, so schedule recurring checks that compare the running configuration against the hardened baseline. Run automated configuration assessments and runtime monitoring where the platform supports them, and route alerts to the team that owns the boundary. Re-run the boundary tests after significant changes and whenever a new platform or tenant joins the inventory. The output is a documented monitoring schedule, the alert records and the change-triggered test results. An independent reviewer should sample recent checks and confirm that deviations were investigated and closed.

Evidence that passes an SC-39 assessment

SP 800-53A examines SC-39 through documentation rather than a single test, so an assessor will look for design, architecture, configuration and verification records that agree with each other. The cards below map to the examine objects and to the change records that keep them accurate after updates.

System architecture diagram with boundaries

Show every execution domain that matters, such as separate hosts, virtual machines, containers, pods and privileged service accounts, and draw the isolation boundary around each one. Mark where the hypervisor, container runtime or kernel enforces separation. An assessor compares this diagram against the running estate, so a diagram that omits a cluster or a shared management host will fail review. Refresh it whenever a workload moves to a new hosting pattern. The platform or architecture lead should own it, with the security team reviewing.

Design document for the isolation mechanism

Explain how the platform keeps each process in its own address space and execution domain, for example through kernel process isolation, namespaces, cgroups, container sandboxes or virtual machine boundaries. Name the component that enforces each boundary and the configuration that turns it on. Record which processes share a domain by design and why. Confirm with the assessor whether they expect this as a standalone document or as a section of the system security plan. The solution architect should own it and update it with each design decision.

Configuration baselines for hosts and runtimes

Keep versioned baselines for operating systems, hypervisors, container runtimes and orchestrators that set the isolation features the design relies on. Include settings such as kernel protections, runtime security profiles, privileged container restrictions and host namespace sharing. Use a benchmark-based scanner to show drift from the baseline. Ask the assessor which configuration evidence format and tool output they accept. The platform engineering team should own the baselines and the compliance lead should approve exceptions.

Independent verification and validation reports

SC-39 examine objects include independent verification and validation documentation, so keep reports from a party that did not design or build the isolation mechanism. These may come from an internal assurance function, a separate testing team or an external reviewer. Each report should state its scope, the version tested and the findings with their disposition. Confirm with the assessor how independence is defined in your environment. The assurance or internal audit function should own scheduling, with the reviewer named in the report.

Isolation test results

Record tests that try to break the boundary, such as a container reading another container's memory, a process attempting to access a sibling process address space, or a workload escaping to the host. Save the test plan, the environment, the commands or scripts run and the pass or fail results. Re-run the tests after each significant platform change so the results remain tied to current configurations. The security testing team should own the test cases, and the engineering team should own remediation of failures.

Change records that preserve isolation

Show that updates to kernels, hypervisors, runtimes and orchestrators do not weaken process separation. Link each change ticket to the affected baseline, the design document and any re-run isolation tests. Record approvals and rollback plans for changes that alter security features or privileged access. Ask the assessor how far back change history must go before an assessment. The change manager should own the process, and each platform owner should attach the evidence to the ticket.

Open-source tools that support SC-39 evidence, by layer

Falco (Apache-2.0) is the tool in this set that observes process activity as it happens. It parses Linux system calls at runtime, by default through an eBPF probe, and evaluates them against YAML rules. Those rules flag events such as privilege escalation, unauthorized file modification, unexpected network connections and suspicious process execution, and Falco enriches each event with container and Kubernetes metadata before sending alerts to stdout, files, syslog, HTTP endpoints or programs.

Process-level events: Alerts can show which process performed a privileged action, which helps test whether one process reaches memory, files or network paths it should not.
Container and Kubernetes context: Metadata attached to each event ties behavior to a specific workload, which supports scoping of the evidence.
Alert routing: Output to a SIEM or log store creates a retained record that an assessor can sample.
Rule ownership: The rule set is YAML that the team writes and maintains, so the evidence reflects the rules chosen.

Falco cannot prove that address spaces or execution domains are separated by design, and it only sees events its rules match. Confirm in your own environment which kernels, probe modes and rules are supported, and test that a deliberate isolation violation produces an alert.

What meeting SC-39 costs in money and effort

This table breaks the cost of meeting SC-39 into its components, showing who is paid for each, whether it is one-time or recurring, what pushes it up and how to keep it down. No prices or durations were supplied for this control, so use the table to structure your own quote requests and internal estimates.

Cost component	One-time or recurring	What drives it up	How to keep it down
Tooling and licenses	Recurring if commercial; open-source tools carry no license fee	Commercial runtime monitoring or hardening products, paid support subscriptions, and extra nodes or clusters to cover	Use open-source runtime detection such as Falco where it fits your platform, and confirm the support model you need before relying on it
Engineering time for configuration	One-time, with ongoing changes	Number of workloads, hypervisors and operating system variants, and how much isolation must be designed and documented by hand	Standardize workload templates, use one isolation pattern per workload class, and fix scope early in a written statement of work
Evidence upkeep	Recurring	Frequent software updates, many hosts to re-check, and manual collection of configuration and design records	Automate configuration checks and keep the architecture and design documents under change control so evidence regenerates with each release
Independent testing	Recurring at each assessment cycle	Breadth of isolation testing across execution domains, the depth of escape and privilege testing expected, and the number of test environments	Agree the test scope and the isolation boundaries to be tested in writing before the assessment starts
Auditor sampling	Recurring at each assessment cycle	Number of systems in scope, the number of samples the assessor selects, and gaps found in the first pass that require re-testing	Prepare a consistent evidence package per system so the assessor can sample without requesting new material
Remediation of findings	One-time per finding, with recurring retests	Shared kernel or hypervisor weaknesses, legacy systems that cannot be isolated, and missing design documentation	Run internal checks before the assessment and track each finding to closure in the plan of action and milestones

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

Your organization owns SC-39. That means deciding how each executing process is kept in its own execution domain, which operating system and virtualization boundaries you rely on, and who signs off on the design. SC-39 is an assurance-related control in all three SP 800-53B security baselines, so the isolation design must be a deliberate decision recorded in your system documentation rather than an accident of default settings. Your team also decides whether any residual risk is acceptable and who formally accepts it.

Control ownership: Name an accountable owner for SC-39 and for the isolation design of each system in scope.
Boundary decisions: Decide which workloads share a host, which run in separate virtual machines or containers, and which require separate hardware.
Risk acceptance: Record any accepted residual risk, its approver and its review date in the plan of action and milestones.
Internal review: Review partner-prepared designs and test results before they enter the system security plan.
Staffing: Keep enough internal knowledge of the platform to operate, monitor and change the isolation controls after handover.

Before engaging anyone, confirm that these decisions have an owner in your organization, because no partner or auditor can make them for you.

Where organizations fall short on process isolation

Most SC-39 findings do not come from missing isolation technology. They come from isolation that exists but is not documented, not tied to a design decision, or not shown to still hold after the last change. The cards below pair each common gap with the artifact or check that closes it, so an assessor can trace the control from design to running system.

Inherited OS isolation left undocumented

Process separation usually comes from the operating system's memory management and privilege model, so teams assume it needs no write-up. An assessor testing SC-39 still needs to see which mechanism provides separate execution domains for each process, on which platform versions, and who owns it. Close the gap with a short isolation statement for each host class that names the OS, the kernel or hypervisor, and the configuration that enforces separation, and attach the platform vendor documentation it relies on.

No design artifact for boundaries

SP 800-53A lists system design documentation and system architecture among the examine objects for SC-39. Without a diagram showing which processes, containers, virtual machines and services share or do not share an execution domain, the assessor has nothing to check the configuration against. Produce one architecture view per system that marks each isolation boundary, the process or workload inside it, and the control that enforces it, then keep it under change control.

Mixed data classes on shared hosts

A single host running a payment service beside an internal reporting job may be acceptable, but only if someone decided that consciously and recorded the reasoning. Shared hosts that mix data classes with no documented decision are a frequent finding because the risk acceptance is missing, not because the separation fails. Record each co-location decision with the data classes involved, the isolation relied on, the approver and the review date, and link it to the system security plan.

Container isolation drifts after updates

Container runtime defaults, seccomp profiles, capability sets and namespace settings can change when base images or orchestration components are upgraded. A configuration that passed at assessment can quietly weaken after a routine update. Pin the settings in version-controlled manifests, and schedule a check that compares running workloads against the approved baseline after each image or platform change. Falco can alert on suspicious process execution and unexpected behavior at runtime, and its rules should be reviewed alongside those manifests.

No independent testing of isolation

Design documents show what the isolation should do, but SP 800-53A also expects testing and evaluation evidence and independent verification and validation documentation where the organization has it. Teams that never attempt cross-process or cross-container access in a controlled test cannot show that the boundary holds. Plan a scoped test that tries to read memory, escalate privilege or reach another workload's files from a compromised process, record the results, and have someone outside the build team review the findings.

Evidence that predates the last change

An isolation test run two years ago does not show that the current hypervisor patch level, kernel version or cluster configuration still enforces separation. Assessors look for evidence that matches the system as it runs today, with dates that follow the most recent significant change. Tie each isolation check to a change record and a re-test trigger, so that a kernel upgrade, a new workload on a shared host or a policy change prompts fresh evidence before the next assessment.

Questions buyers ask about SC-39 process isolation

How much does meeting SC-39 process isolation cost?

No researched figure exists for SC-39 alone, so treat any number you see with caution. The cost comes from three parts: the internal time to document the execution model, the engineering work to confirm process separation on your platforms, and the independent assessor's fees. Only the assessor and your own staff are paid for the assessment itself. The main cost drivers are how many operating system images, hypervisors and container platforms are in scope, how much of the design already exists in documents, and whether isolation is inherited from a platform that is already assessed. Ask any quote to itemize scope by system, deliverables for design and test evidence, and whether retesting after changes is included.

How long does SC-39 preparation take, and what does it need from our team?

The duration depends on how many systems share the same isolation design and how current your architecture documentation is. SC-39 is a single determination statement in SP 800-53A, so the core work is small, but it needs time from system architects, platform engineers and whoever owns testing. Expect them to explain how each process gets its own execution domain, provide system design and architecture documents, and run or accept test results showing separation holds. Confirm the timeline with your assessor and the scope in writing before work starts, since assessors set the evidence they accept.

Can our own team prepare for SC-39 without an implementation partner?

Yes, if your team already knows how its operating systems, hypervisors and container runtimes separate processes and can write that down clearly. Many organizations do this internally for a single system. A partner is most useful when you have many platforms, inconsistent designs or little time to produce test evidence. Remember that the organization owns the control. A partner can prepare systems and evidence, but only an independent assessor issues the assessment result. Whichever route you choose, name one owner for the control and keep the design documents current.

Which parts of SC-39 are worth outsourcing?

Outsource the parts that need specialist time and produce evidence you would otherwise struggle to create. Typical candidates are:

Independent testing of process isolation on hardened hosts, containers and virtual machines
Writing or reviewing system design and architecture documentation
Building repeatable test scripts and collecting their output as evidence
Continuous detection of unexpected process behavior after changes

Keep ownership of the design decisions, risk acceptance and the final sign-off. An assessor will expect the organization to explain its own system, so the partner should teach your staff rather than replace them. Any engagement should be fixed in scope with written deliverables.

What does an assessor ask for first when testing SC-39?

An assessor starts with the documents that describe how the system is built, then tests whether the design matches reality. Under SP 800-53A, the examine objects for SC-39 include system design documentation, system architecture, testing and evaluation documentation, and independent verification and validation documentation. Expect to provide a current architecture diagram showing the execution domains, the isolation mechanisms in use, and recent test results. Be ready to explain how a process cannot access another process's memory or execution context. Interviews with engineers will follow, so the people who run the platform should know the design well.

Does SC-39 apply to containers and Kubernetes workloads?

SC-39 is written in terms of system processes, so containerized workloads fall within its intent when they run as processes on a shared host. Containers normally rely on kernel namespaces and cgroups for separation, which is a different mechanism from a virtual machine boundary. An assessor will want to see which mechanism you rely on, how containers are configured to isolate workloads, and whether the node operating system and runtime are kept current. Confirm with your assessor how they treat containers in your environment, because the answer depends on the scope and the boundary you define.

Can runtime monitoring tools produce SC-39 evidence?

Runtime monitoring can support SC-39 by showing that processes behave within their expected boundaries, but it does not prove isolation by itself. Falco, an Apache-2.0 project, parses Linux syscalls at runtime, by default through an eBPF probe, and evaluates them against YAML rules to flag events such as privilege escalation or unexpected process execution. Its alert output can be stored as records of monitoring over time. Confirm with the assessor whether this counts as supporting evidence alongside design documents and isolation test results, and check the current Falco documentation for the platforms you run.

How DeployOpen prepares SC-39 isolation evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so process isolation for SC-39 is set up and evidenced where the workloads run. The organization owns its control; DeployOpen prepares the systems and evidence that an independent assessor reviews.

How we scope

Engagements are fixed-scope, with the platforms, hosts and workloads in SC-39 agreed in writing before work starts.
The written scope names which execution domains, containers and virtual machines the isolation design covers.
Scope also records who owns the SC-39 control statement and who approves the isolation design.

How we build

Process separation is configured through the operating system, container runtime and virtualization layers in the client's environment.
Runtime monitoring such as Falco can be deployed to watch for unexpected process execution and privilege escalation across workloads.
Configuration baselines are checked with tools such as Wazuh policies or Fleet queries, with results kept as evidence.

How we hand over

Handover includes architecture and system design documentation describing how each process runs in its own execution domain.
Test records show the isolation settings in place and the results of configuration checks at the time of handover.
Documentation is delivered in the client's repositories so assessors and internal teams can review it without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can keep isolation settings and monitoring rules current as platforms are patched and upgraded.
Ask the auditor which SC-39 evidence they expect, since only an independent assessor issues the assessment result.