Information in Shared System Resources is the requirement that stops leftover data from bleeding between users on the same hardware. It sits in the System and Communications Protection (03.13) family, and it addresses what happens when a shared resource such as memory, cache, or disk space is released by one user or process and reused by another. Information in Shared System Resources (03.13.04) requires preventing unauthorized and unintended information transfer via shared system resources. Per the NIST discussion, this stops information produced by the actions of prior users or roles (or processes acting on their behalf) from being available to current users or roles after those resources have been released back to the system, and it also applies to encrypted representations of information.
A common difficulty with this requirement is assuming the operating system or hypervisor handles resource reuse automatically and never confirming it. This is largely a configuration and design objective, so the evidence is in how the system clears or isolates shared resources. Per the NIST discussion, this requirement does not address information remanence (the residual representation of data that has been nominally deleted), covert storage or timing channels, or single-user components, so scope it to shared-resource reuse rather than every data-protection concern.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.13.04 Information in Shared System Resources. Only the formatting has been adjusted for readability. This is a single statement with no lettered parts:
The source control is SC-04 from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, the control of information in shared system resources is referred to in other contexts as object reuse and residual information protection, and it applies to encrypted representations of information as well as plaintext. You can read the requirement directly at NIST 800-171 R3, 03.13.04 (p. 58).
None (0). Requirement 03.13.04 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.13.04 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.13.04 into two (2) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
The single statement splits into two (2) objectives: preventing unauthorized transfer and preventing unintended transfer via shared resources. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.13.04 (p. 76).
Examine: system and communications protection policy and procedures; procedures for information protection in shared system resources; system configuration settings; system audit records; system design documentation; system security plan.
Interview: personnel with information security responsibilities; system developers; system administrators.
Test: mechanisms for preventing the unauthorized and unintended transfer of information via shared system resources.
03.13.04 maps from NIST 800-171 R2 requirement 3.13.4 (prevent unauthorized and unintended information transfer via shared system resources):
Mapped against the two (2) AOs, both (2) are direct (minimal effort), with no net-new AOs and none with no mapping. This is a clean carry-forward with identical wording. If you satisfied R2 3.13.4, confirm the same controls still apply to your current systems, including any virtualized or cloud resources added since your last assessment.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.13.04 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about verifying resource reuse protections, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.13.04 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.13.04 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
The SCF controls that carry this requirement have no dedicated ERL artifact, so evidence rests on the configuration and records that demonstrate the objectives directly.
Alongside these, keep the System Security Plan (SSP) narrative for 03.13.04.
With both AOs mapping directly, 03.13.04 is a light lift focused on confirming existing protections. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.13.04 have? NIST 800-171A R3 breaks 03.13.04 into two (2) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.13.04 come from? SC-04.
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.13.04 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.13.04 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.13.04 Information in Shared System Resources prevents unauthorized and unintended information transfer via shared system resources such as memory, cache, and storage. It maps directly from R2 3.13.4 with identical wording, so there is no net-new work. The recurring problem is assuming the platform handles resource reuse without confirming it. Identify the shared resources, document how reuse is prevented for both unauthorized and unintended transfer, and include virtualized and multi-tenant environments in scope.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
