SC.L2-3.13.4 Shared resource control: requirements and evidence

What SC.L2-3.13.4 shared resource control requires in plain words

If you are the compliance lead or engineer who has been handed SC.L2-3.13.4, the core question is simple: can information left behind by one user or process reach another through a resource the systems share? The requirement is about residual information passing between users through shared resources such as memory, cache, registers, disks and other storage that several accounts, processes or tenants touch over time. The risk is concrete. A buffer that still holds one user's documents, a cache entry that survives a session, or a disk block that was never cleared can surface to the next user who reads that space. The requirement asks you to prevent that transfer, whether it is unauthorized or simply unintended.

SC.L2-3.13.4 is a 1-point requirement drawn from the derived security requirements of NIST SP 800-171 Rev. 2, in the System and Communications Protection family. The point value is small, but the proof burden is not. Most of the protection lives in the operating system, hypervisor, storage layer and application software, and the vendors of those components design the behavior. Your organization therefore has to show what the platform does and how it is configured, not only that a policy says residual data is cleared. Expect to document inherited behavior from each vendor, the settings you control, and the evidence that those settings are in effect on the systems in scope.

A Level 2 assessment tests this requirement against the assessment objectives in NIST SP 800-171A, which for 3.13.4 is a single objective: unauthorized and unintended information transfer via shared system resources is prevented. Assessors look at procedures, configuration settings and audit records tied to that objective. Confirm with your assessor and the current assessment guidance which artifacts they will accept for inherited controls and how they expect shared components to be scoped. Start by listing every shared resource inside the CUI boundary, identifying which vendor controls each one, and collecting the configuration evidence that shows residual data handling is enabled.

Which systems and teams the shared resource control applies to

SC.L2-3.13.4 reaches any system where more than one user, process or tenant shares memory, storage or other resources. The cards below separate the components that usually fall inside the assessment boundary from the scoping choices that can move a system in or out of it.

Multi-user operating systems

Any server, workstation or jump host where several accounts log on, run processes or share memory is a primary candidate for this requirement. The question an assessor asks is how the operating system keeps one user's residual data, such as freed memory pages, temporary files and process registers, from becoming readable by the next user. Confirm which OS hardening settings, vendor protections and patch levels your team relies on, and record them in the system security plan.

Hypervisors and virtual machines

Hypervisors schedule memory, CPU caches and virtual disks across tenant virtual machines, so they sit at the center of shared resource risk. Confirm how the platform zeroes or isolates memory pages when a VM is stopped, migrated or reassigned, and how virtual disks are provisioned so that blocks from a deleted volume cannot reach a new one. Ask the platform owner which of these behaviors are vendor-defined and which you configure yourself.

Shared storage and disks

SAN, NAS and shared block storage hold CUI from several projects or departments, and deleted data often remains recoverable until blocks are overwritten. Document how volumes are allocated, how freed blocks are cleared or encrypted, and what happens during array replacement or lease return. Storage that is dedicated to one CUI enclave is simpler to evidence than a pool shared with unrelated workloads.

Container hosts and orchestrators

Containers on a shared host share the kernel, and often share tmpfs mounts, volumes and host memory. Check that pods or containers handling CUI do not share writable volumes with other workloads, that ephemeral storage is cleared when a container exits, and that node-level isolation matches the workload's sensitivity. Record how the orchestrator reuses nodes so the evidence shows the behavior in practice.

Multi-tenant databases

A database that serves several applications, business units or customers can return residual rows, cached query results or temporary tables to the wrong session if isolation is weak. Review how the database manages connection pooling, buffer caches, temporary tablespaces and row-level access for CUI tables. Confirm with the database vendor which of these protections are default behaviors and which need explicit configuration.

Dedicated devices and inherited vendor protections

A single-user device that is never shared, and that holds no CUI in shared memory or storage, may fall outside the practical reach of this requirement, but the boundary decision belongs to the organization and must be written down. Where a cloud or SaaS provider supplies the isolation, document what the provider's documentation and attestations cover, obtain them from the provider, and state which responsibilities remain with you. Inherited protections still need evidence in your own system security plan.

How an assessor tests SC.L2-3.13.4

This table breaks down how an assessor works through the single NIST SP 800-171A objective for SC.L2-3.13.4, from the test approach and the evidence requested to the findings that most often cause a gap. Read it as a checklist of what to have ready before an assessment, not as a guarantee of the outcome. The main takeaway is that the requirement is judged on demonstrated, documented prevention of residual data transfer, not on the mere existence of a vendor feature.

Assessment element	What the assessor does	Evidence to have ready	Where it usually fails
Assessment objective	Confirms that unauthorized and unintended information transfer through shared system resources is prevented	A written statement of which shared resources exist in scope, such as memory, caches, registers and disks	Scope is never defined, so the assessor cannot tell which resources the claim covers
Examine configuration settings	Reviews OS and platform settings that control memory, storage allocation and process isolation	Exported configuration baselines with version and date, plus the setting that governs object reuse or clearing	Settings are assumed from defaults and nobody can show the values in force
Examine application partitioning	Checks how applications and user sessions are separated so one user's data is not left in a resource another user receives	Architecture diagrams and procedures describing partitioning, including containers, virtual machines or dedicated hosts	Multi-tenant or shared-service components are not mentioned in the procedures
Examine audit records	Looks for logs that show allocation, release or clearing of shared storage and any related failures	Retained logs or alerts covering storage reallocation events, with retention settings	Logs exist but do not record the events the assessor needs to trace
Interview responsible staff	Asks administrators how residual data is cleared and who verifies it	Named roles, runbooks and a short walkthrough the staff member can perform on request	Staff describe the intended process, which differs from what the configuration does
Reallocated storage	Asks what happens to disks, volumes and memory pages when they move from one user or workload to another	Documented sanitization or clearing steps for reallocated storage, with a sample record of execution	No residual clearing is documented for reallocated disks or virtual volumes
Vendor default reliance	Asks whether the organization relies on operating system or software vendor protections and whether that reliance is documented	A written list of the vendor-provided protections the organization depends on, with the version each applies to	Reliance on vendor defaults is undocumented, and no one has confirmed the defaults still hold after upgrades
Final-form evidence	Accepts only evidence in final form when deciding whether the objective is met	Approved, dated versions of procedures and baselines rather than drafts or working notes	Procedures exist only as drafts, so the objective cannot be marked as met

Implementing shared resource control step by step

This sequence turns SC.L2-3.13.4 into a documented, testable state: every shared resource in the CUI boundary is known, each protection has a named owner, residual data handling is configured and verified, and the assessor can trace each claim to a record.

Inventory shared resources inside the CUI boundary
Start by listing every shared resource that can carry information between users or processes inside the CUI boundary. That includes main memory, swap or page files, CPU caches and registers where you can reach them, local and network disks, virtual disks, shared temporary directories, and any container or hypervisor pools that host CUI workloads. Assign each item to the system component it belongs to. The output is a shared resource inventory tied to the system security plan's boundary diagram, reviewed by the system owner and the people who administer those components. The step is done when a reviewer can point to every resource that touches CUI and no resource is left unassigned.
Assign operating system and hypervisor protections
For each inventoried resource, record which protection is supplied by the operating system, hypervisor or platform software and which must be configured or operated by your organization. Operating system and software vendors typically provide the core mechanisms that clear or isolate memory, caches and storage between users, so the question is whether those mechanisms are present, supported and enabled in your versions. Ask each vendor for the documentation that describes this behavior for your release, and file it with the inventory. The output is a responsibility matrix that names the owner of each protection and the document that supports the claim.
Confirm configuration settings for residual data handling
Next, verify the settings that govern residual data: memory initialization and zeroing behavior, swap or page file encryption and clearing on shutdown, temporary file cleanup, disk sanitization on deletion or reallocation where the platform controls it, and cache isolation for multi-tenant hosts. Capture the actual values from each system with a read-only check, not from memory or a template. Where a platform offers a hardening guide, compare your values against it and record any deviation with a reason. The output is a configuration baseline per resource type, signed off by the administrator responsible for it, with dated screenshots or command output stored as evidence.
Document application partitioning and user separation
Shared resource control also depends on how applications use shared resources. Document how each CUI application separates one user's data from another's: process isolation, per-user sessions, database tenancy, temporary storage per request, and whether any component caches CUI in a location other users can read. Flag any application that writes CUI to a shared scratch location or keeps it in a common cache without clearing it. The output is a short partitioning record for each CUI application, reviewed by the development or service owner, that matches the system security plan and the configuration baselines from the previous step.
Test residual data behavior with controlled transfers
Verify the design with tests rather than assumptions. Using a test account that has no CUI, write a known marker string through the application, end the session, then check whether the marker can be recovered by another user or process through memory dumps, temporary files, swap contents or cache reads that your tools are permitted to perform. Repeat after restarts and after an administrative change. Record the test procedure, the account used, the time of each run, and the result. Any recovery is a finding that goes into the plan of action. The output is a test record with pass or fail results and the remediation ticket for every failure.
Record evidence and maintain it through change control
Bring the outputs together into one evidence folder: the shared resource inventory, the responsibility matrix with vendor documentation, the configuration baselines, the partitioning records and the test results. Map each item to the assessment objective for SC.L2-3.13.4 so an assessor can follow the trail from claim to proof. Then route any change to a shared resource, such as a new hypervisor pool, a new application tier or an OS upgrade, through change control so the inventory and baselines are updated before the change is accepted. The output is a current evidence package with a review date and an owner, and a clear rule that undocumented changes to shared resources are not accepted into the CUI boundary.
Monitor configuration drift on shared resource settings
Configuration drift is the usual way residual data controls fail after an assessment. Schedule recurring checks of the baseline values on the systems in the inventory. Open-source tools can help here: Wazuh Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies that check files, registry keys and running processes, and recommend remediation. Fleet policies pose yes or no osquery questions to devices and show which devices pass or fail each policy. Confirm with each tool's documentation whether a specific memory, swap or cache setting can be checked before you rely on it. The output is recurring scan results, reviewed and filed as evidence, with failing items routed into the same remediation process.

Why configuration evidence matters more than policy text

For SC.L2-3.13.4, the assessor is less interested in a policy saying shared resources are protected than in proof that the operating system and software in use actually behave that way. The CMMC Assessment Guide for Level 2 places this protection primarily with operating system and software vendors, so your organization's job is to confirm that the platform does what the vendor says, keep confirming it, and document the result. Start by collecting the vendor documentation for each operating system, hypervisor, database and application that processes CUI, and note the specific statements about memory clearing, residual data handling, and how disks and caches are reused between sessions or tenants. Where the vendor is silent or vague, that gap belongs on your risk register, not in a footnote.

Documentation alone does not show the control is operating. Translate the vendor claims into configuration items you can set and verify: the relevant kernel or hypervisor settings, storage encryption and scrubbing options, swap and temporary directory handling, and any multi-user or virtualization features that share physical resources. Record the baseline value for each setting, who approved it, and the tool or command that reads it back. A configuration assessment tool such as Wazuh Security Configuration Assessment can check files, directories, registry keys and running processes against YAML policies and report deviations, and Fleet policies can answer yes or no osquery questions per device, showing which hosts pass or fail. Treat these outputs as recurring evidence, and confirm with your assessor which form of output they will accept.

Retain proof through change. Patches, kernel updates and platform upgrades are the events most likely to reset a setting or change how a resource is shared, so the configuration check should run after each one and its results should be kept with the change record. Ask your assessor and your platform vendor which artifacts they expect for this, and confirm that scan results are final and dated rather than working drafts. Scope matters as well: if a shared resource is provided by a cloud or hosting provider, document what that provider supplies and what you must verify yourself.

Evidence that satisfies the shared resource control

An assessor testing SC.L2-3.13.4 looks for proof that residual information cannot cross between users through memory, caches or disks, and that the configuration producing that proof is documented and current. The artifacts below come from different owners, so each one should be dated, versioned and signed off before the assessment begins.

System security plan entries

The system security plan should state how the organization prevents unauthorized and unintended information transfer through shared resources, naming the operating systems, hypervisors, storage and components in scope. Each statement should point to the configuration exports, procedures and design notes that back it. Check that the entry matches the system as it runs today, not the design from the original build.

OS and hypervisor configuration exports

Exports of operating system and hypervisor settings show the protections in effect, such as memory and storage handling defaults, virtual machine isolation options and the state of relevant kernel or hypervisor features. Export the settings from the live systems with a timestamp and keep the file that a reviewer can re-read. Confirm with each vendor which settings govern residual data, because the protections are typically provided by operating system and software vendors.

Application partitioning design notes

Design notes explain how applications that handle CUI are separated in memory, process space and storage, so one user's session data is not left where another user's process can read it. Assessors examine partitioning as a potential object for this requirement, so the notes should name the components, the isolation boundary and the reason each boundary holds. Update the notes whenever a multi-tenant feature, cache or shared service changes.

Sanitization and residual-data procedures

Written procedures describe how disks, memory buffers, temporary files and caches are cleared or overwritten before reuse by another user or process, and who performs each step. Pair the procedure with records of execution, such as sanitization logs or cloud volume deletion confirmations. Ask whether the procedure covers virtual disks, snapshots and backups, since residual data often survives in those places.

Audit records of configuration checks

Scheduled configuration assessments produce dated records showing that the settings governing shared resources were checked and whether they passed. Wazuh Security Configuration Assessment checks files, directories, registry keys and running processes against YAML policies, and Fleet policies report which devices pass or fail each query. Keep the pass and fail history, and document how each failure was remediated or accepted.

Vendor documentation and attestations

Vendor security documentation, hardening guides and any third-party reports show what the platform does to prevent residual data transfer and which protections the customer must enable. Record the product version each document covers, because a document for an older release does not prove the current build. Where a vendor cannot provide documentation, record that gap in the POA&M or the system security plan rather than assuming coverage.

What meeting SC.L2-3.13.4 costs in money and effort

This table breaks down the cost and effort components of meeting SC.L2-3.13.4 by who is paid, whether each item is one-time or recurring, and what moves it up or down. No figures are published for these components in the sources used here, so use the table to build a written scope and to ask each provider for a line-item quote.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Internal engineering time to verify configurations	Your own platform and operating system staff	Recurring, with a large first pass	Number of hosts, hypervisors and multi-user systems in scope; drops when builds come from a hardened baseline with documented memory and disk sanitization settings
Configuration compliance tooling	Software vendor or your own staff if self-hosted	Recurring if licensed; one-time setup	Self-hosted open-source tools such as Wazuh (GPL-2.0-only) carry no license fee, though hosting and staff time still apply; confirm the license terms of any commercial tool in the quote
Implementation partner work to prepare systems and evidence	Implementation partner, under a fixed written scope	One-time, with optional retainer for upkeep	Count of shared-resource platforms, custom policies needed beyond vendor benchmarks, and how much evidence must be built from scratch
Evidence upkeep	Your compliance and system owners	Recurring	Frequency of configuration changes, patch cycles and rebuilds, since each change may require re-verification and updated screenshots, scan exports or policy results
External review or penetration testing of multi-tenant components	Independent security testing firm	Recurring when multi-tenant components are in scope	Whether the system shares hosts, virtual machines or storage between users or tenants; ask whether residual data testing is included in the scope
Assessor fees for certification	C3PAO or other assessor authorized under the CMMC program	One-time per assessment cycle	Scope size and assessment cycle; the Department of War suspended CMMC Phase II, so confirm current timing and whether certification applies to your contracts before budgeting
Coordination and internal reviews	Your compliance lead and an executive sponsor	Recurring	Number of systems sharing the requirement and how many teams must sign off on the system security plan and evidence

Open-source tools that support shared resource evidence

Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints for misconfigurations. Its checks are written as YAML policies. Most shipped policies are based on CIS benchmarks, and organizations can extend the set with custom policies. The checks look at files, directories, registry keys and running processes, and each failed check comes with a recommended remediation. For SC.L2-3.13.4, this helps show that settings governing shared resources, such as kernel and operating system options your baseline requires, are defined and consistently applied.

Policy format: Checks are declared in YAML, so the policy itself can be version controlled and attached to the system security plan.
Baseline coverage: Shipped policies are mostly CIS-based, so confirm which benchmark versions and operating systems your fleet actually uses.
Custom checks: Organizations can write checks for their own baseline values, such as a setting your documented shared resource control depends on.
Remediation output: Failed checks include recommended fixes, which supports the tracking of corrective action in your POA&M.
License: Wazuh is released under GPL-2.0-only, so confirm the license obligations that apply to how you deploy and modify it.

Before relying on this tab, confirm with your own environment which checks run on your operating systems and whether a custom policy can express your required setting.

Where organizations fall short on shared resource control

Shared resource control failures rarely come from a single missing product. They tend to sit in assumptions: that someone else handles residual data, that a multi-user application separates users by default, or that a patched system still matches its approved baseline. Each gap below is easy to miss and easy to check before an assessor does.

Assuming the cloud provider covers everything

Many organizations assume that because a cloud or hosting provider manages the hypervisor and physical storage, SC.L2-3.13.4 is handled. The provider may protect its own infrastructure, but the organization still has to show how its own virtual machines, containers and storage volumes avoid passing information between tenants or users. Ask the provider for its written shared responsibility documentation and confirm which parts of memory, cache and disk isolation it covers and which parts the organization must evidence itself.

No residual data clearing for reused disks

A disk, volume or memory region reassigned from one user or workload to another can carry leftover data unless the platform clears it first. Teams often rely on reformatting, which does not always overwrite data, and rarely document the process. Check how volumes are released, whether block storage is zeroed or encrypted before reuse, and whether the procedure is written down and tested with a sample volume that is reassigned and inspected.

No documented partitioning for multi-user applications

Multi-user applications, shared build runners and internal tools can hold data from several users in the same process, cache or temporary directory. Without a documented partitioning design, an assessor cannot confirm that one user's session data stays out of another user's view. Document how sessions, caches, temporary files and job workspaces are separated, and record the configuration settings that enforce that separation so they can be shown as evidence.

Drafts submitted as evidence

Teams often gather screenshots, a design sketch or an untested runbook and call it evidence. Under the CMMC rules, a requirement is met only when evidence is in final form, so a draft procedure for clearing shared resources will not satisfy the assessment objective. Before an assessment, review each artifact for an approved version, a date, an owner and an approval record, and replace any draft with a signed final document.

Configuration drift after patching

Patches, hypervisor updates and image rebuilds can quietly change memory, cache or storage settings that were hardened earlier. Without a baseline and periodic comparison, the organization cannot show that the configuration it documented is still the one running. Compare current settings against the approved baseline after each change window, and use a configuration assessment tool such as Wazuh Security Configuration Assessment to flag deviations on monitored endpoints.

Questions buyers ask about SC.L2-3.13.4

How much effort does SC.L2-3.13.4 take to meet?

The effort is usually modest for this requirement alone, because it is a 1-point requirement with a single assessment objective in NIST SP 800-171A. Most of the protection comes from operating system, hypervisor and software vendors, so the work is mainly verifying how each platform isolates shared resources such as memory, caches, registers and disks, then documenting that evidence. Effort rises with the number of hosts, virtualization layers, multi-tenant services and shared storage pools in the boundary. Ask any partner for an inventory of shared resources in scope and a written list of the evidence each one will produce before agreeing on effort.

Can we meet SC.L2-3.13.4 with an in-house team?

Yes. The organization owns its controls and its evidence, so an internal team can meet the requirement and prepare its own documentation. An outside implementation partner can help prepare systems and evidence, but only an independent assessor or certification body issues assessment results. In-house teams need people who understand how their operating systems clear memory, how their virtualization platform isolates guests, and how their storage handles deleted data. They also need time to collect evidence in final form, because drafts do not satisfy the assessment objectives.

How long does SC.L2-3.13.4 preparation usually take?

No duration is set for this requirement on its own, and any figure you hear should be checked against your own environment. Preparation time is driven by how many platforms share resources in scope, whether configuration baselines and architecture documents already exist, whether cloud or hosting providers can supply their own configuration evidence, and how quickly your team can review and approve it. Environments with well-documented baselines usually move faster than those where isolation behavior must be researched for each platform. Ask for a written schedule tied to the agreed scope, with named milestones for evidence review.

What does our team need to provide for SC.L2-3.13.4?

The client team must supply the facts and approvals that no outside party can supply for them. In practice that means:

A named owner for each system in scope who can confirm how shared resources are used
Administrative access or vendor documentation covering operating system, hypervisor and storage configuration
An inventory of shared resources and any known residual data risks, such as temporary files or swap space
Change records showing when isolation settings were last reviewed and by whom
Sign-off on evidence in final form before it goes to the assessor

Can SC.L2-3.13.4 go on a POA&M for Conditional status?

Yes, under the scoring rules in 32 CFR 170. SC.L2-3.13.4 is worth 1 point and is not on the exclusion list in 32 CFR 170.21, so it may be placed on a plan of action and milestones if the assessment score is at least 88 of 110 (0.8). The POA&M must be closed out within 180 days. Confirm with your contracting officer and assessor how your score and open items will be presented, because the decision on a POA&M follows the score you can document, not the score you expect to reach.

What changes for SC.L2-3.13.4 after the Phase II suspension?

The requirement itself does not change. The Level 2 requirements remain identical to NIST SP 800-171 Rev. 2, and SC.L2-3.13.4 still calls for preventing unauthorized and unintended information transfer through shared resources. On 13 July 2026, the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and a 60-day review by the CMMC Reform Task Force is underway. Check the DoW CIO About CMMC page and your contract terms for current status.

How do open-source tools check shared resource settings?

Open-source tools can show that configuration is in place, but they do not decide whether 3.13.4 is met. Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, covering files, directories, registry keys and running processes. Fleet policies ask yes or no osquery questions of devices and show which devices pass or fail each one. Your team must first define which settings matter for shared resources, such as memory and swap handling, temporary file cleanup and disk encryption, then confirm with each vendor how their platform behaves. Review the Wazuh configuration assessment documentation before writing custom policies.

How DeployOpen prepares shared resource evidence

DeployOpen prepares the evidence for SC.L2-3.13.4 inside your own infrastructure, working from a written, fixed scope that names the platforms, hosts and environments in play. The control itself is a single assessment objective: unauthorized and unintended information transfer through shared system resources must be prevented. In practice, the work starts with an inventory of the self-hosted platforms that share memory, disks or hypervisor resources, followed by a review of which of those components the organization inherits protection from and which it must configure. Your organization owns the control, the risk decision and the final system security plan. DeployOpen plans, implements and documents the technical settings and the evidence trail around them.

On the technical side, the evidence usually centers on operating system and hypervisor configuration, sanitization of storage reused between tenants or sessions, and the settings that govern process isolation. Where a platform runs on hosts you control, DeployOpen can use Wazuh Security Configuration Assessment to check endpoints against YAML policies, which look at files, directories, registry keys and running processes, and to record remediation output. Fleet policies, written as osquery questions, can show which devices pass or fail a chosen check over time. Confirm with each vendor which residual-data protections they document and which they leave to the operator before you write the policy statement that depends on them.

The deliverables are the configuration baseline, the check definitions, the scan and policy results, and the write-up of how each result answers the assessment objective. Those are inputs for your assessment, not findings an assessor will accept on DeployOpen's word. Only an independent assessor, under the CMMC process, can judge whether the control is MET, and the final evidence must be in its finished form. Ask any implementation partner for a written scope, a list of deliverables and a clear statement of what the partner will not sign or certify. To request a scoped quote for SC.L2-3.13.4, send DeployOpen your environment summary and the platforms that share resources, and we will reply with a fixed-scope proposal.

SC.L2-3.13.4 Shared resource control