What SC-3 security function isolation requires and why it is hard to evidence
If your system is in the high baseline or assessed at FedRAMP Class D, SC-3 requires you to isolate security functions from nonsecurity functions. Security functions here means the mechanisms that enforce access, generate audit records and protect the rest of the system's trust decisions. The point of the control is that a compromised application component should not be able to switch off access enforcement or audit logging, because those are the mechanisms that would reveal or contain the compromise. SP 800-53B assigns SC-3 to the high baseline only, so a moderate or low system does not need it unless your organization selects it through tailoring.
The isolation is architectural. It has to be built into how processes, accounts, hosts, containers and network paths are arranged, and it spans several layers at once: the operating system's privilege model, the hypervisor or container runtime, the identity provider, the logging pipeline and the administrative paths into each. Policy statements do not satisfy it. An SP 800-53A assessor will examine the list of security functions to be isolated, the system design documentation, configuration settings with their supporting documents and system audit records, so each of those artifacts must show the same boundary. Confirm early which of your components count as security functions, because a list that omits the audit pipeline or the policy engine is the most common gap assessors find.
SC-3 has five control enhancements in Release 5.2.0, and none of them is assigned to a SP 800-53B baseline, so the high baseline requires the base control only. Read the enhancements anyway and decide whether your authorizing official or FedRAMP assessor expects any of them for your design. Ask your assessor to confirm in writing which artifacts they will request, and plan to keep configuration and audit evidence current, since an isolation boundary that drifts after a change will fail the next assessment even if the original design was sound.
Which systems and components fall under SC-3 scoping
SC-3 scoping starts with a list of the security functions that must be isolated, then works outward to the hosts, hypervisors, cloud services and third-party components that share space with them. Each card below is a decision or check an assessor will expect you to have made and documented, and the related controls in the catalog show where the boundary decisions connect.
Security functions to list
Start with a written list of the security functions the system performs. Typical entries are access enforcement, audit record generation and storage, cryptographic key handling, and security monitoring agents. SP 800-53A makes this list the examine object for SC-3, so an assessor will compare it against the design documents. If a function is missing from the list, it is outside the isolation analysis by default. Confirm the list with the control owner before the assessment starts.
Nonsecurity code on shared hosts
Identify every nonsecurity workload that runs on the same host, virtual machine or container node as a security function. Shared hosts are the most common place where isolation breaks down, because a web application, batch job or reporting tool can read memory, files or credentials belonging to the audit or access logic. For each shared host, record the reason it is shared and the separation mechanism that applies. Inventory the results against the system configuration settings that an assessor will examine.
Hypervisors and shared control planes
Virtualization platforms, container orchestrators and management consoles often sit inside the security boundary even when the application teams do not manage them. Decide whether tenants, administrators and nonsecurity virtual machines share a hypervisor, a cluster or a control plane with security components. Record who can change those shared layers, because a compromised administrative path can reach every function that runs above it. Ask the platform team to show the configuration that separates these domains.
Third-party and open-source components
Put every third-party agent, library and appliance that performs a security function inside the scoping list, including logging forwarders, secrets managers, scanners and endpoint agents. Each component has its own privileges and update path, so a vendor patch can change the isolation you documented. Track the component versions, the accounts they run under and the privileges they hold. Include the open-source projects you deploy with the same rigor as commercial products.
Cloud services in the boundary
Managed logging, key management, identity and container services can hold security functions that you do not run yourself. Determine which of these services are inside your authorization boundary, and which responsibilities the provider keeps. Obtain the provider's documentation on how it separates its own tenants and security functions, and record it as inherited evidence. Confirm with the provider and your own assessor how inherited controls are cited, because an inherited claim you cannot evidence will not satisfy SC-3.
Related controls and FedRAMP Class D
The catalog links SC-3 to AC-3, AC-6, SC-2 and SC-7, among others, so access enforcement, least privilege, separation of user and management functions and boundary protection should be assessed together. FedRAMP's Rev5 baselines require SC-3 at Class D, so cloud offerings at that class should expect it in their assessment. Confirm which SP 800-53B baseline and which FedRAMP class apply to your system before you finalize the scope, because SC-3 is a high baseline control.
How an assessor tests SC-3
This table maps the single SP 800-53A Release 5.2.0 determination statement for SC-3 to the methods and objects an assessor uses, and to the findings that commonly appear. Read each row as a question the assessor will ask and the evidence that answers it.
| Assessment element | What the assessor checks | Evidence that passes | Common finding |
|---|---|---|---|
| Determination statement | Whether the organization isolates the security functions it has identified from nonsecurity functions, as the control requires | A documented isolation decision for each security function, with the mechanism that enforces it | Isolation is asserted in policy but no mechanism is named |
| Examine: list of security functions | Whether the organization has defined which functions are security functions and therefore need isolation | A current, approved list covering access enforcement, audit, key handling and similar functions, with an owner | The list is missing, outdated or does not match the components actually running |
| Examine: system design documentation | Whether the architecture shows where security functions run and how they are separated from user workloads | Architecture diagrams showing separate hosts, containers, namespaces or virtual machines for security components | Diagrams show a flat design where security services share hosts with application code |
| Examine: configuration settings and documentation | Whether the settings that enforce separation, such as container isolation, privilege boundaries and access restrictions, are in place and documented | Exported configuration files, policy baselines and the documentation that explains each setting's purpose | Configuration drift: settings in production differ from the documented baseline |
| Examine: system audit records | Whether logs show that security functions ran in their protected domain and that separation was not bypassed | Audit records that identify the host or domain where security events were generated and any changes to isolation settings | Audit records are missing for changes to separation settings or cannot be tied to a domain |
| Interview | Whether administrators and engineers can explain which functions are protected, how isolation is maintained and who may change it | Consistent answers from security, platform and operations staff, supported by the documentation | Staff disagree on what counts as a security function |
| Test | Whether the separation works in practice, for example by attempting to reach a security function from a nonsecurity process | Test results showing that unauthorized processes cannot read, modify or stop security functions | Test is not performed, or it covers only one host of several |
How to implement SC-3 in sequence
This sequence turns SC-3 from a requirement into a set of isolated domains that an assessor can examine. Each step produces a record the organization owns, so the isolation can be explained, tested and kept current after go-live.
Inventory and document the security functions
Start by listing every security function in scope: access enforcement, audit record generation and review, key and secret handling, logging agents, endpoint policy enforcement, and any administrative functions that change security settings. The system owner and security team compile the list, then confirm it against the system design documentation so nothing that enforces policy is missed. The step is complete when each function has a name, an owner and a short description of what it protects. That list is the first examine object SP 800-53A names for SC-3, so an assessor will ask for it directly.
Map each function to an execution domain
For each security function, record where it runs: a separate host, virtual machine, container, Kubernetes namespace or privilege domain. Mark which nonsecurity workloads share that domain, and flag any shared kernel, shared credentials or shared storage as a finding to resolve or accept in writing. The architecture team produces a diagram and a table that link each function to its domain. The step is done when no security function shares a domain with nonsecurity code without a documented reason. Assessors use this mapping to test whether the isolation exists in practice.
Configure and lock the isolation boundaries
Build each domain with only the components it needs, then restrict access into it using the platform's own controls, such as separate accounts, namespace policies, network rules, mandatory access controls or hypervisor settings. Store the desired configuration as code under version control so changes go through review. The platform or infrastructure engineer applies the settings, and the step closes when the configuration matches the mapping from the previous step and the approved baseline. Confirm with the vendor or your own environment which isolation features your platform version supports before you rely on them.
Restrict administrative paths and cross-boundary dependencies
List every path that crosses a boundary: service accounts, API calls, shared volumes, message queues, and administrative consoles. Remove any path that is not required, require authentication and logging for those that remain, and keep administrative access to security domains on separate paths from general user access. The security engineer reviews each remaining path and records its purpose, owner and approver. The step is complete when the cross-boundary inventory contains no unexplained paths. This also supports the related control SC-2, which covers separating user functionality from system management.
Verify the isolation with tests
Test the boundary from both sides. From a nonsecurity workload, attempt to read, modify or stop security functions, reach their management interfaces, and read their configuration and keys. Repeat the attempts from an administrator account to confirm that only approved paths succeed. Keep the test scripts, inputs and results as evidence. The security team or an independent tester runs the tests, and the step is done when every attempt that should fail does fail and each failure is logged. Use findings to correct the configuration and rerun the affected tests.
Monitor the boundaries for drift and violations
Enable runtime and configuration monitoring that reports when a security function is modified, when a process crosses an expected boundary, or when a configuration drifts from the approved baseline. Open-source tools can cover parts of this work. Falco can flag unexpected process execution and file changes at runtime, Wazuh can check endpoint configurations against policies, and Fleet can report whether devices pass or fail queries you define. Confirm which events each tool can observe in your environment before you rely on it. The step is complete when alerts route to a named owner and a test event produces an alert.
Record the output of each step
Keep one evidence record for each step: the function inventory, the domain mapping, the configuration files and approvals, the boundary-path register, the test scripts and results, and monitoring alerts with their handling. Store the set in the system security and privacy plan repository and link it to the SC-3 entry. Re-run the verification after material changes, and review the record at the schedule your governance process sets. The step is complete when an assessor can trace a single security function from its inventory entry through its domain, its tests and its alerts without asking the team for missing items.
Evidence that passes an SC-3 assessment
SP 800-53A has an assessor examine a short list of objects for SC-3: the list of security functions to isolate, design documentation, configuration settings and audit records. The cards below cover each artifact, plus change records, and how to keep them current between assessments so they reflect the system as it actually runs.
Documented list of security functions
This is the starting artifact. It names every security function that must be isolated from nonsecurity code, such as access enforcement, audit generation, key handling and integrity checks, and identifies the component that hosts each one. Keep it in version control next to the system security plan so each entry points to a named owner. Review it whenever a service is added, split or retired, and check that no security function has quietly moved into a shared container or a general-purpose host.
System design and architecture documents
Diagrams and narrative documents must show where each security domain begins and ends, which network segments, clusters, namespaces or hosts form each domain, and which paths cross between them. An assessor will test whether the diagrams match reality, so name the trust boundaries explicitly and record which controls enforce them. Update the document after each architectural change and keep dated revisions so the assessor can trace how the separation evolved during the assessment period.
Configuration exports and infrastructure as code
Exported settings and the infrastructure-as-code that produces them are the strongest evidence that isolation is configured, not just intended. Capture firewall and security group rules, Kubernetes namespace and network policy definitions, host partitioning, and privilege settings for security services. Store the code in a repository with protected branches, and generate a dated export at each assessment milestone. Confirm that deployed state matches the code, because drift between the two is a common finding.
Audit records and alerts showing enforcement
Logs and alerts show the boundary being enforced in operation. Keep records of denied cross-domain access attempts, unexpected process activity in a security domain, and modifications to security function configuration. Runtime sensors such as Falco can flag unexpected process execution or file changes in a container, and their rule sets belong in the evidence package alongside sample alerts. Confirm that log forwarding to the central store is working, because the assessor will ask for records from the assessment period.
Scan results and policy compliance reports
Scheduled compliance checks show whether the isolation settings stay in their approved state over time. Configuration assessment tools such as Wazuh can check hosts against YAML policies, and Fleet policies answer yes or no questions about devices so you can show which hosts pass or fail each rule. Export these reports on a fixed schedule and record how failures were remediated. Container image scans, such as the Trivy results that GitLab produces, can support the claim that security functions run from approved, patched images.
Change records and access approvals
Every change to a security domain, its firewall rules, or the hosts that run security functions should have a ticket, an approver, a test record and a rollback plan. Assessors compare change records against the configuration exports to confirm that no unapproved change altered isolation. Set a review cadence, for example monthly, where the security owner reviews changes to security domains and signs off the list. Ask the organization to confirm its own review interval, since no fixed frequency is set by SP 800-53.
What meeting SC-3 costs in money and effort
The largest one-time cost is engineering time to decide which security functions must be isolated and to build the domains that keep them apart. SC-3 asks the organization to list the security functions, such as access enforcement, audit logging and key handling, and to separate them from nonsecurity code. That work is design, change and verification effort inside the organization's own teams, often with an implementation partner preparing the domains, hosts or namespaces. Cost rises with the number of security functions, the number of hosts and clusters involved, and how many nonsecurity components share those hosts today.
- Inventory of security functions: Time to list every function that enforces policy or records events, and to document which nonsecurity code sits beside it.
- Domain design: Architecture work to choose partitions, separate hosts, namespaces or accounts, and the access paths between them.
- Build and migration: Engineering time to move functions into their domains without breaking dependent services.
- Verification testing: Time to show that nonsecurity processes cannot read or alter security functions in each domain.
- Rework from scope change: Extra effort when new functions or hosts join the boundary after design is approved.
Ask the provider to state in the quote how many security functions, hosts and domains the fixed scope covers, and whether the domain design and migration are priced separately from testing.
Tooling costs come from the platforms that enforce separation and the tools that show it is working. Hypervisors, container runtimes, orchestrators and operating systems usually provide process and address-space separation, and many organizations already pay for them. Commercial monitoring and configuration assessment products add license fees that scale with endpoints or events. Self-hosted open-source tools can remove most of that license spend, though they still need hosting, patching and configuration effort inside the client's environment.
- Open-source detection: Falco (Apache-2.0) parses Linux syscalls at runtime, by default through an eBPF probe, and can flag unexpected process activity around protected domains.
- Configuration evidence: Wazuh (GPL-2.0-only) Security Configuration Assessment checks monitored endpoints against YAML policies, which can show how domains are configured.
- Device and host state: Fleet (MIT) policies ask yes or no osquery questions of devices, which can show whether hosts in each domain meet the agreed settings.
- Hosting and operations: Servers or cluster capacity to run these tools, plus the staff time to keep them current.
- Commercial alternatives: License and support fees for proprietary products, which the quote should list as separate line items.
Confirm with each vendor which features your chosen version offers, and ask the provider to show license cost and hosting cost as separate lines so the comparison is exact.
Evidence upkeep is the recurring cost. An assessor needs current records showing the list of security functions, the system design documentation, the configuration settings and the audit records that show the boundaries hold. Each time a host, namespace or function changes, the design documents, configuration exports and test records must change with it. Cost depends on how often the environment changes and whether evidence is generated automatically or assembled by hand before each review.
- Design documentation: Keeping the domain diagrams and the security function list accurate after each change.
- Configuration exports: Regular captures of settings for each domain, stored with dates and owners.
- Audit records: Retention, review and sampling of logs that show security functions were not altered by nonsecurity code.
- Change control: Records that link each boundary change to an approval and a test result.
- Automated collection: Scheduled scans and policy checks that produce evidence without manual assembly, which lowers recurring effort but needs its own upkeep.
Ask the provider how evidence is produced, who maintains it after handover, and whether the quote includes an evidence refresh for each assessment cycle or only the initial build.
Outside review covers two separate things. Security testing of the separated domains, such as attempts to reach security functions from nonsecurity processes, is a scoped engagement with its own deliverables. The independent assessment that reaches a conclusion about SC-3 is performed by an assessor or auditor, not by the implementation partner. These are different contracts with different owners, and the organization pays each one. DeployOpen prepares systems and evidence and runs security testing, but it does not issue assessment reports or certifications.
- Security testing: Fixed-scope testing of isolation between security and nonsecurity components, with written findings and retest work where needed.
- Implementation support: Partner effort to prepare domains, configurations and evidence for the assessor.
- Independent assessment: Fees paid to the assessor or auditor for examining documents, interviewing staff and testing the controls.
- Retesting: Additional testing after remediation of any finding, usually scoped separately.
- Ongoing testing: Retainers for continuous testing, which recur and should be priced from their own written scope.
Ask for each engagement to be quoted separately with its scope, deliverables and what is excluded, so the organization can tell which party is responsible for each finding.
The assessor's effort follows the assessment procedure for SC-3, which uses examination of documents and records, interviews and testing. The assessment objects include the list of security functions, the system design documentation, the configuration settings and the audit records. Sampling depth is set by the assessor and the organization's risk decisions, and the cost of an assessment grows with the number of domains, hosts and functions the assessor must sample. The organization cannot estimate that effort from this page alone, so it should confirm the scope with the assessor before work starts.
- Document examination: Time to read the security function list and design documentation for each domain.
- Configuration review: Sampling of settings on hosts or clusters in each domain.
- Audit record review: Sampling of logs to check that security functions were not altered by nonsecurity code.
- Interviews and walkthroughs: Staff time to explain how domains are built and changed.
- Scope boundaries: Clear definition of which systems count as security functions, since a broader scope increases sampling.
Ask the assessor for a written scope and sampling plan before accepting a fee, and confirm how any SC-3 result links to the related controls that share the same evidence.
Open-source tools that produce SC-3 evidence
This table compares three self-hosted open-source tools that can generate evidence for SC-3 isolation claims: runtime detection, configuration assessment and fleet policy results. Read each row as a source of evidence for a different part of the isolation argument, not as proof that isolation is in place. Each tool needs to be confirmed against the security domains in your own environment before an assessor sees its output.
| Tool and license | Evidence it produces | Where it fits for SC-3 | Caveats to confirm |
|---|---|---|---|
| Falco (Apache-2.0) | Runtime alerts from Linux syscalls, evaluated against YAML rules and enriched with container and Kubernetes metadata | Detects unexpected activity crossing a boundary, such as a nonsecurity process touching audit or security function paths | Default probe is eBPF. Confirm rule coverage for your security domains and where alerts are retained |
| Wazuh SCA (GPL-2.0-only) | Configuration assessment results from YAML policies that check files, directories, registry keys and running processes | Shows whether security function components are configured as the isolation design states | Policies are mostly CIS-based and extendable. Write custom checks for your own separation settings and review GPL-2.0 obligations |
| Fleet (MIT) | Per-device pass or fail results for osquery policies, shown on the policies page for each fleet | Shows which endpoints meet a yes or no isolation check, such as a required control being enabled | Coverage depends on the osquery tables available on each platform. Confirm the policies match your documented design |
| Your design documents | Authoritative list of security functions and the separation method chosen for each | Gives the tool results a baseline. Assessors compare runtime and configuration evidence against it | No tool produces this list. Confirm the list is complete and current before any assessment |
Who owns SC-3: your team, a partner and the auditor
Your organization owns SC-3. That means deciding which functions count as security functions, documenting where they run, and accepting the residual risk of any shared component. The security team usually leads the list of security functions, such as access enforcement, audit record generation and key handling, while the platform team maps those functions to the hosts, namespaces, virtual machines and network segments where they execute. Assessors will read this decision record first, so it has to match the running system.
- Security function list: Name each function that must be isolated from nonsecurity code and state why it qualifies.
- Design documentation: Show the partitions, domains or hosts that separate those functions, and the paths between them.
- Configuration ownership: Assign named owners for isolation settings such as namespace policies, kernel and hypervisor controls, and privileged access paths.
- Change control: Route any change to a security function or its boundary through review, so the documented design stays accurate.
- Exception handling: Record any function that shares a domain with nonsecurity code, with a risk acceptance and a compensating control.
Before an assessment, confirm that the function list, the design documents and the live configuration describe the same system.
An implementation partner such as DeployOpen can build and document the isolation configuration inside your environment and prepare the evidence an assessor will examine. Partner work is typically scoped in writing before it starts, and the deliverables usually include configuration baselines, the tooling that checks them, and an evidence package mapped to SC-3. The partner does not decide what your security functions are, and it does not sign off on the control. DeployOpen does not issue assessment reports or attestations.
- Isolation configuration: Implement the partitions, namespaces, separate hosts or domains that your team has specified, within your own cloud accounts, data centers or air-gapped network.
- Monitoring tooling: Set up self-hosted tools that show whether isolation holds, for example runtime detection of unexpected process or file access.
- Evidence package: Assemble configuration exports, design diagrams, audit records and test results, indexed to the SC-3 examine objects.
- Documentation: Write runbooks for how the isolation is maintained, changed and verified.
- Scope and handover: Agree deliverables, exclusions and acceptance criteria in writing, and hand over ownership of every artifact.
Before engaging a partner, ask for a written scope that names the systems covered and states that the partner will not issue assessment conclusions.
The independent assessor tests SC-3 and reports the result. Under NIST's assessment procedure for SC-3, the assessor examines the list of security functions, design documentation, configuration settings and audit records, and may interview staff and test the isolation directly. Only an assessor who is independent of the implementation can issue the findings your authorizing official or customer relies on. In federal contexts, the assessment and authorization process decides who may perform the assessment.
- Examine: Review the security function list, design documents, configuration exports and audit records against the stated boundaries.
- Interview: Ask system owners how isolation is maintained, changed and monitored day to day.
- Test: Attempt to reach security functions from nonsecurity code paths, and confirm that the attempt fails and is logged.
- Report: Issue findings, including any exceptions, in the assessment report that your organization owns and submits.
- Independence line: An assessor cannot design or configure the isolation it then tests.
Before hiring an assessor, confirm its independence rules, the methods it will use, and which parties must sign the final report.
Where organizations fall short on SC-3
Most SC-3 findings do not come from missing technology. They come from security functions that were never listed, exceptions that were never written down, and evidence that describes what the team intended. The cards below cover the gaps assessors meet most often, each with a closing action the organization can take before its next assessment.
No written list of security functions
SC-3 starts with a defined set of security functions that must be isolated from nonsecurity code. Many systems have no such list, so access enforcement, audit generation and key handling are scattered across services without anyone naming them. An assessor cannot test isolation for functions that were never identified. Action: publish a named inventory of security functions, with the owner and the host or domain where each runs, and tie it to the system design documentation.
Audit agents sharing user space
Log shippers, intrusion sensors and endpoint agents often run beside application code with the same privileges, which means a compromised workload can stop or alter them. Assessors look for audit functions in separate execution domains, such as a dedicated host, a separate container namespace or a hypervisor-level sensor. Check the process tree and container specs on production nodes, not only the architecture diagram. Action: confirm each audit and detection agent runs in a domain that application workloads cannot modify.
Administrative paths crossing the boundary
Security administration often reaches production through the same network paths, jump hosts and service accounts that application users share. When management traffic and user traffic cross the same boundary without separation, isolation exists on paper only. Review which accounts can reach policy engines, key stores and logging configuration, and from which networks. Action: trace every administrative path to a security function and document where it crosses from user-accessible space.
Undocumented exceptions
Teams frequently grant temporary exceptions, such as a debugging container with host access or a shared database account for a batch job, and never record them. Each undocumented exception is a place where security and nonsecurity code meet without a decision on record. Assessors ask who approved the exception, what it allows and when it ends. Action: keep a dated exception register that names the approver, the function affected, the compensating control and the review date.
Intent instead of configured state
A design document saying that security functions are isolated is not the same as configuration showing it. Teams often present architecture diagrams and policy text while the running system has overlapping permissions or shared volumes. Assessors weigh system configuration settings and audit records more heavily than statements of intent. Action: collect configuration exports and audit records that show the isolation in effect, then reconcile them against the design documentation and fix any drift.
Questions buyers ask about SC-3
How much effort does SC-3 security function isolation take?
SC-3 takes most of its effort in design and documentation rather than in new tooling. The organization has to identify which functions are security functions, such as access enforcement, audit logging and key handling, and show how those functions sit in protected domains apart from nonsecurity code. The work usually splits into three parts: producing the list of security functions and the design documentation that explains the separation, configuring the system so the separation is enforced (for example through separate hosts, namespaces, accounts or privilege boundaries), and collecting audit records and configuration evidence that show it is still in place. Effort rises with the number of components, the number of security functions and how much shared infrastructure the system relies on. Ask any partner to break its estimate into these three parts so you can see where the hours go.
Can we implement SC-3 in-house without an outside partner?
Yes, if your team has the architecture knowledge and the time to produce the evidence. An assessor tests SC-3 by examining a list of the security functions to be isolated, system design documentation, configuration settings and audit records, and by interviewing staff about how the separation works. Teams with strong platform engineering and a clear system design can usually meet this in-house. Outside help tends to be useful when the system has many shared components, when design documents do not exist, or when the team needs an independent check before an assessment. Whichever route you choose, the organization owns the control and its decisions. Only an independent assessor can report on whether SC-3 is met.
What does the team need to provide for SC-3 work?
The work needs people who understand the system architecture, the operating system or virtualization layer, and the security functions that run on it. In practice you need:
How long does it take to prepare SC-3 evidence?
The duration depends on how well the system is already documented and how many security functions need separate domains. No researched duration is available for this control, so treat any timeline as something to confirm in writing. The main drivers are the state of the design documents, the number of components that must be checked, whether the separation already exists in configuration or must be built, and how many review cycles your assessor or internal governance requires. Systems with clear architecture diagrams and configuration management usually produce evidence faster than systems where the security functions are spread across shared hosts. Ask for a schedule with named milestones tied to deliverables such as the security function list and the design document.
Does SC-3 apply to systems below the high baseline?
No. SP 800-53B assigns SC-3 to the high security control baseline only, so a low or moderate system does not select it by default. Some organizations still apply it voluntarily because separating security functions reduces the impact of a compromise, and some frameworks or contracts may require it for lower-impact systems. Confirm your system's impact level and baseline selection with your authorizing official or the requiring contract before you plan the work. If your environment is governed by a FedRAMP or agency-specific baseline, check that document directly, since its selections can differ from the SP 800-53B baseline.
What can an implementation partner do for the SC-3 audit, and what can it not do?
An implementation partner can help plan the separation, document the security functions, configure and harden the domains, and collect the configuration settings, audit records and design documentation that an assessor will examine. DeployOpen works this way: it prepares systems and evidence within a written, fixed scope. It does not issue audit reports, attestations or certifications, and it cannot decide whether SC-3 is met. Only an independent assessor, auditor or certification body does that. The organization remains responsible for its controls, its risk decisions and its answers during interviews. Ask any partner to state in the scope document which artifacts it will deliver and which assessment steps remain with you.
Which open-source tools can produce SC-3 evidence?
Several self-hosted tools can generate evidence that supports isolation claims, although none of them proves SC-3 on its own. Falco, which is licensed under Apache-2.0, parses Linux syscalls at runtime and can flag events such as privilege escalation or unexpected network connections, which helps show that boundaries hold in practice. Wazuh's Security Configuration Assessment, under GPL-2.0-only, checks endpoint configuration against YAML policies that can be extended with custom checks. Fleet, under MIT, runs osquery-based yes or no policies across devices and shows which devices pass or fail each one. Confirm each tool's fit against your own design documents before relying on its output as assessor evidence.
How DeployOpen scopes and prepares SC-3 evidence
DeployOpen plans, implements and documents the separation between security functions and nonsecurity code inside the client's own infrastructure. We prepare the systems and evidence an assessor will examine for SC-3, while the organization owns the control and an independent assessor reaches any conclusion.
How we scope
- Written scope lists which security functions must be isolated from nonsecurity functions, such as access enforcement and audit record handling.
- Scope names the domains, hosts, namespaces or partitions that hold each security function and the systems that must stay outside them.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Design documentation maps each isolated security function to its partition, host or domain and records the boundary between them.
- Configuration of access paths, administrative interfaces and audit storage is set so nonsecurity workloads cannot change security function settings.
- Isolation is tested by attempting access from nonsecurity components to security functions and recording the results.
How we hand over
- Handover includes the list of isolated security functions, system design documentation and configuration settings with their change history.
- Audit records showing the isolation settings, test results and any exceptions are packaged for the organization's assessor.
- The organization receives the evidence set and remains responsible for keeping the control operating after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which covers changes to isolation boundaries over time.
- Retainer work re-checks isolation after platform upgrades, new workloads and changes recorded in configuration management.
- Questions about the assessor's findings are answered by DeployOpen, while the assessor makes the final determination.
