03.13.04 shared system resources: requirements and evidence

What 03.13.04 asks for and why object reuse matters for CUI

03.13.04 requires that information left behind in a shared system resource cannot reach a later user or process by accident or design. For a compliance lead facing an assessment, the question is simple: when one user or process releases a resource, such as memory, a disk block, a session or a virtual machine, can the next user or process read what the first one wrote? NIST's Rev. 3 discussion names this requirement object reuse and residual information protection, and the source control NIST lists for it is SC-4 from SP 800-53 Rev. 5. The requirement covers transfers that happen through shared resources that are released and reused, and it does not extend to information remanence, covert channels or single-user components, so the assessor will expect you to scope it to the shared resources that actually hold CUI.

The risk is easy to miss because the leak leaves no visible trace. A freed memory page may still hold a CUI extract when the hypervisor assigns it to another tenant. A reused disk block may hold a deleted spreadsheet. A pooled application session may carry one user's CUI-bearing context into the next user's request, and a container or virtual machine image may retain files from a build that handled CUI. None of these events produces an alert by default, so the organization cannot rely on logs or day-to-day operations to show that residual data is cleared. The evidence has to come from design and configuration: documented zeroing or sanitization behavior for each shared resource type, system configuration settings that enforce it, and design documentation that shows where CUI can persist between users.

Start by listing every shared resource type in the CUI boundary, then ask the platform owner or cloud provider to confirm, in writing, how each one is cleared before reuse. Confirm the answer for virtualization and container runtimes, shared storage, and session stores, since these are the places where assumptions tend to fail. Where the vendor cannot give a clear answer, plan a test that writes a known marker into a resource, releases it, and checks whether a second principal can read it. Record the test, the configuration in force and the result, because an assessor will interview system administrators and developers about these resources and will compare what they say with what the configuration shows.

Which shared resources and systems fall inside 03.13.04

03.13.04 applies wherever a resource is released by one user or process and handed to another. The cards below cover the resource types that carry residual information, the systems that process or store CUI, and the scoping decisions that change how much work the requirement creates. Start with the shared resources in your CUI boundary, then decide which of them can actually carry CUI between users or processes.

Memory and swap space

Physical memory pages and swap partitions are released by one process and reassigned to another, so bytes written by one workload can remain readable by the next. Check whether the operating system zeroes pages before reuse, whether swap is encrypted, and whether hypervisors and container runtimes clear memory they hand to guests or pods. Ask your platform team to document the mechanism for each host class that processes CUI, because the answer often differs between bare metal, virtual machines and managed container nodes.

Temporary files and scratch storage

Temporary directories, build caches, spool files and scratch volumes are created for one job and then deleted or left behind for the next. Deleting a file usually removes only its directory entry, so the data blocks may still hold CUI until overwritten. Inventory the locations where applications write intermediate CUI, confirm that cleanup runs at job end, and record how reused volumes are sanitized before another tenant or process can read them.

Storage blocks and volumes

Block devices, thin-provisioned volumes and deduplicated pools reassign allocated blocks to new owners. A new volume may expose blocks that held another tenant's data if the storage layer does not zero them on allocation. Confirm with your storage and cloud providers how unwritten blocks are returned, whether snapshots and deleted volumes are scrubbed, and who holds responsibility for each step. Shared storage that serves CUI and non-CUI workloads needs particular attention.

Virtual machine and container resources

Shared hypervisors, Kubernetes nodes and container hosts reuse CPU state, memory, network namespaces and writable layers across workloads. A workload that shares a node with a CUI-processing pod may inherit residual state if isolation is weak. Scoping decisions here change the work: a dedicated node pool or hypervisor cluster for CUI can narrow the set of shared resources you must demonstrate, while a mixed cluster requires evidence for every workload it hosts. Record which tenants share each node or host.

Session objects and print queues

Session tokens, cached web objects, clipboard buffers, print spool directories and collaboration sessions are reused between users of the same device or service. A print queue that retains a CUI document after the job completes, or a shared workstation that keeps session artifacts for the next login, creates a path for unintended transfer. Check how each application clears session state at logout and how print spoolers delete completed jobs, and document the settings in your configuration baseline.

Multi-user versus single-user components

The Rev. 3 discussion of 03.13.04 says the requirement does not cover single-user components. A dedicated laptop used only by one person with CUI generally falls outside it, while a multi-user server, shared jump host or pooled virtual desktop falls inside. Document the single-user or multi-user classification for each component in the system security plan, and confirm that the classification reflects how the component is actually used, since a device that later admits a second user changes its scope.

What 03.13.04 does not cover, and where those risks go

NIST's discussion of 03.13.04 draws explicit boundaries. The requirement is about preventing unauthorized and unintended information transfer through shared system resources that are released and reused, which NIST also calls object reuse and residual information protection. It does not cover information remanence, covert channels or single-user components. Those three exclusions matter for scoping because a reader who assumes 03.13.04 handles them will leave real exposure without a named owner. Treat them as separate risks to be assigned, not as settled by this requirement.

Information remanence, covert channels and single-user components each need a home in your risk assessment. Remanence questions, such as whether sanitized media or decommissioned storage still expose CUI, are usually addressed through media protection and sanitization requirements in the 03.08 family and the encryption requirements in 03.13.08. Covert channels, where processes signal data through timing or resource contention, are not a requirement you can close with one setting, so record them as accepted or mitigated risks with a named owner. Single-user components, such as a workstation used only by one person, still need the controls their own categories require even though this requirement's reuse concern does not apply to them.

Before you finalize scope, confirm the boundary in writing with the federal agency that holds the contract and with your assessor. Ask specifically whether they expect covert channel analysis or remanence testing for your system, and whether they will assign organization-defined values or apply additional protections. Document each excluded risk in your system security plan, state where it is controlled or accepted, and record the decision and its approver. The organization owns this decision. An implementation partner can prepare the scoping evidence, but only the agency or assessor can confirm that the boundary is acceptable.

How an assessor tests the two determination statements for 03.13.04

This table maps each assessment method in SP 800-171A Rev. 3 to the objects an assessor reviews for 03.13.04, with the evidence to prepare and the findings that usually appear. Read it as a checklist of what to have ready before an assessor arrives, since the two determination statements are tested through examine, interview and test methods together.

Method or object	What the assessor does	Evidence to prepare	Common finding
Examine: policy and procedures	Reads the system and communications protection policy and the procedures for protecting information in shared system resources	Dated policy naming object reuse, and procedures stating when and how buffers, memory, storage and sessions are cleared	Policy exists but does not describe how release and reuse are handled for CUI-bearing resources
Examine: system configuration settings	Checks settings that govern clearing or zeroing of reused resources, such as memory, temporary storage, swap and virtual disks	Configuration exports or baseline files showing the relevant settings and who approved them	Settings are left at vendor defaults with no documented rationale
Examine: system audit records	Looks for records showing that the cleanup or reuse controls ran or that failures were logged	Log samples, alert rules or retention settings tied to resource cleanup events	No records exist, so the organization cannot show the control operated
Examine: system design documentation	Traces how shared resources such as virtual machine pools, containers, shared storage and caches are allocated and released	Architecture diagrams and data flow notes showing where CUI can persist between users or processes	Design documents omit shared caches or persistent volumes that reuse storage
Interview: personnel with security responsibilities	Asks how they know reused resources are cleared and who reviews exceptions	Named owners, review cadence and escalation path for exceptions	Answers differ between the security team and platform operators
Interview: system administrators and developers	Asks how new components, images and reused sessions handle residual data	Engineering notes on image build steps and session teardown code	Developers describe behavior that the written design does not reflect
Test: mechanisms preventing transfer	Runs or observes a test showing that a released resource does not expose prior content to the next user or process	Repeatable test script, test results with dates and the system version tested	Untested cleanup: the mechanism exists but no one has shown it works after a change

Implementing object reuse controls in the right order

This sequence turns the 03.13.04 requirement into a set of named shared resources, documented clearing behavior, verified configurations and recurring checks that an assessor can trace from the requirement to the evidence. Each step ends with an artifact the assessor will ask to see.

Inventory shared resources that touch CUI
Start by listing every shared resource that a CUI-handling process can reuse between users or processes. This includes memory and buffers, temporary and scratch storage, virtual disks and volumes, container and virtual machine images, print and collaboration spool areas, and session or application caches. The system owner and the system administrators should review the list against the system boundary and the data flow diagrams in the system security plan. The step is done when every resource has an owner, a location and a note on whether CUI can reach it. The assessor will ask to see this inventory and how it was reconciled with the boundary.
Define the clearing behavior for each resource
For each inventoried resource, write down what must happen to the residual information before the resource is released to another user or process. Typical choices include zeroing memory on allocation or deallocation, overwriting or cryptographically erasing storage before reuse, and destroying temporary files at session end. Assign the decision to a named role and record the reason where the default behavior is accepted. The output is a clearing standard that names the resource, the required behavior and the responsible team. The assessor will look for this standard when testing the policy and procedures behind 03.13.04.
Configure the platform to enforce clearing
Apply the clearing behavior through system configuration rather than user procedure. Depending on the platform, this can mean operating system memory initialization settings, hypervisor or storage settings that scrub freed blocks, container runtime settings for ephemeral storage, and application settings that remove temporary data at logout. Store the configuration in version control so changes are reviewed and traceable. The step is complete when each configuration setting matches the clearing standard. The assessor will ask for the configuration settings and the change records that show how they were set.
Verify the clearing with tests
Test that the configured behavior works as intended. A tester should create residual data in a resource, release the resource, and confirm that a second user or process cannot read the earlier content. Repeat the test for each resource class and record the commands, inputs, observed results and the date of the test. Where a control depends on the storage layer, include a check of the underlying device or volume, not only the application view. Failed tests go to the change process with a remediation owner. The assessor will ask to see the test procedure, results and any retest evidence.
Document the design and its boundaries
Write the design record that explains how each shared resource is cleared, which components implement the behavior and where the requirement does not reach. The NIST discussion for this requirement notes that it does not cover information remanence, covert channels or single-user components, so the record should state how those topics are handled under other requirements or accepted risk. Include system design documentation, data flow references and any dependency on the cloud or hosting provider. The output is a design document approved by the system owner. The assessor will look for this document and for consistency between it and the system security plan.
Feed audit and monitoring evidence into recurring checks
Set up recurring checks that confirm the clearing controls remain in place after updates and configuration drift. Configuration assessment tools can compare endpoint settings against written policies and report failures, and runtime monitoring can flag unexpected file modification or process behavior around sensitive storage. Osquery-based policies can answer yes or no questions about devices, such as whether a required setting is present. Route the failures into the same tracking system used for other findings. The output is a schedule, the policy definitions and a log of results. The assessor will ask to see recent results and evidence that failures were investigated and closed.
Review the controls after each significant change
Re-run the inventory and verification steps whenever the system changes in a way that could add a shared resource, such as a new hypervisor, a new container platform, a new storage tier or a new collaboration service. Record the change, the reviewer, the affected resources and the retest results. Confirm that the system security plan and the design document still match the live environment. The output is a dated change record that links to the inventory and test evidence. The assessor will check that the controls were kept current and not only set up once before the assessment.

Evidence that passes 03.13.04 and how to keep it current

An assessor testing 03.13.04 looks for a small set of artifacts that show how shared resources are cleared before reuse and that the mechanisms actually work. Each artifact below has a different owner, a different refresh trigger and a different test, so keep them separate rather than bundling them into one policy binder.

Approved procedures for resource reuse

Written procedures for information protection in shared system resources are the examine object SP 800-171A Rev. 3 names first. They should say which resources are cleared on release (memory, temporary files, swap, caches, reused storage blocks and virtual machine images), who triggers the clearing and what counts as a failed clearing step. Review them at least annually and after any change to the hypervisor, container runtime or storage layer. The system security official approves them, and the procedure owner records the approval date and version.

Design documentation of resource reuse

Design documentation should show where information could persist between users or processes: shared memory, pooled database connections, reused virtual disks and container image layers. For each path, record the mechanism that clears or isolates it and the component that owns it. Engineers update this document with each architecture change, and the system security officer reviews it before the system security plan is revised. An assessor will ask whether the diagram matches the running system, so check it against a current inventory.

Configuration baselines with verification output

Settings that govern clearing, such as memory zeroing, swap encryption, ephemeral storage defaults and tmpfs options, belong in a configuration baseline. Wazuh Security Configuration Assessment can check endpoint settings against YAML policies, including custom policies written for the organization's own clearing rules, and reports the result with remediation guidance. Keep the scan output dated and tied to the baseline version. Re-run the scan after patching, imaging or hypervisor upgrades, and have the configuration owner accept any deviation in writing.

Fleet query results for endpoints

Endpoint devices that handle CUI also reuse storage and memory, so a policy that asks whether disk encryption is on and temporary directories are cleared gives a yes or no answer per device. Fleet policies are osquery queries, and its policies page shows which devices pass or fail each one. Export the passing and failing lists on a fixed schedule, keep the query text under version control, and show the assessor how failing devices were remediated or excluded. Confirm that the queries you need are supported in your Fleet version before relying on them.

Audit records showing checks ran

An assessor will not accept a baseline as evidence unless records show the checks executed on a schedule. Keep scan logs, job histories and alerts that show each clearing check ran, when it ran and what it found. Protect these records from modification and retain them for the period the organization's policy sets. Compliance staff should sample them each quarter to confirm that gaps in the schedule are explained, and the system security officer signs off on the quarterly summary.

Test results from clearing mechanisms

The test method in SP 800-171A Rev. 3 expects evidence that the clearing mechanisms work, not only that they are configured. Run controlled tests in a nonproduction environment: write a known marker to a reused buffer or volume, release it, allocate the resource to another process, and confirm the marker is gone. Falco can alert on unexpected file access to reused locations at runtime, which shows detection coverage. Record the test plan, the result and the tester, and repeat tests after material changes. An independent assessor may repeat the test during the assessment.

What meeting 03.13.04 costs in money and effort

This table breaks down the cost components of meeting 03.13.04 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no price or duration is stated for this requirement. The main takeaway is that most of the effort sits in verifying resource clearing across the system and keeping that evidence current, while open-source tooling mainly removes license spend rather than engineering time.

Cost component	Who is paid or who pays	One-time or recurring	What drives it up or down
Engineering time to inventory shared resources	Internal staff or implementation partner	One-time, then periodic refresh	Number of OS images, hypervisors, storage pools, memory and temp spaces in the CUI boundary; fewer shared resource types lowers effort
Verifying clearing of residual information	Internal engineers or implementation partner	One-time per resource type, recurring on change	Whether clearing is enforced by default in the OS or hypervisor, or must be scripted and tested per component
Tooling and licenses for configuration checks	Software vendor (commercial) or none (open source)	Recurring if commercial, otherwise none for license	Commercial scanner seats versus self-hosted open-source checks; open source removes license spend but not setup or tuning time
Evidence upkeep and change control	Internal compliance staff	Recurring	Frequency of image rebuilds, hypervisor patching and new shared resources; automated configuration baselines reduce manual capture
External testing or independent review	Security testing firm or assessor-adjacent reviewer	One-time or periodic	Scope of object reuse tests and whether covert channels are included, which NIST's discussion excludes from this requirement
Assessor sampling effort	Assessor (for example, the DCMA DIBCAC or an independent assessor, as applicable)	Per assessment cycle	Number of systems and resource types the assessor samples; clear documentation of each sampled resource shortens review
Remediation of findings	Internal engineers or implementation partner	One-time per finding, recurring if drift recurs	Configuration drift in images and virtual machine templates; codified baselines limit repeat fixes
Quote request items	Vendor or partner to provide in writing	Stated per line	Ask for resource inventory method, clearing test approach, tooling assumptions, evidence format, retest terms and assessor support included

Which self-hosted tools can produce evidence for shared resource checks

No single open-source tool verifies object reuse on its own. For 03.13.04 Information in shared system resources, the assessor wants evidence that the mechanisms preventing unauthorized and unintended transfer of information through reused resources are configured and working. Tools can supply pieces of that evidence, but the organization still has to define which resources are shared, which settings matter, and how the results are reviewed. Each tool below is a candidate to confirm against your own environment, not a control in itself.

Wazuh (GPL-2.0-only) Security Configuration Assessment scans monitored endpoints against YAML policies, shipped mostly based on CIS benchmarks and extendable with custom policies. It checks files, directories, registry keys and running processes and recommends remediation. A custom policy can test settings tied to memory and storage cleanup on your systems, such as the configuration keys your team has chosen to govern residual data handling. Fleet (MIT) policies ask yes or no osquery questions of devices, and its policies page shows which devices pass or fail each one, which gives a per-device record for a question such as whether temporary storage is cleared at logoff. Falco (Apache-2.0) parses Linux syscalls at runtime, by default through an eBPF probe, and evaluates them against YAML rules that can flag unauthorized file modification. Its alerts can go to stdout, files, syslog, HTTP endpoints or programs, so the record can reach your log retention system. Confirm that the rules you write cover the shared locations you have identified.

GitLab Community Edition (MIT) container scanning uses Trivy to find vulnerabilities in container images, including base images and OS packages, and emits a JSON report job artifact plus a CycloneDX SBOM file. This does not show object reuse behavior, but it documents what is inside images that share a host or cluster, which helps when an assessor asks what a reused image carries. Before you rely on any of these tools, confirm three things: that its license terms suit your deployment, that it runs in your network without sending data outside your boundary, and that its output is kept with your system security plan as evidence. An independent assessor decides whether the combined evidence meets the requirement.

Doing shared resource controls in-house or with a partner

Your organization owns requirement 03.13.04 in every sense that matters to an assessor. Your security function decides how object reuse is handled for each system that processes CUI, accepts the residual risk where a control cannot be fully applied, and signs the system security plan entries that describe the approach. Those decisions cannot be handed to a vendor, and the assessor will ask who made them and when.

Ownership and decisions: Name an accountable owner for shared resource handling, including who approves exceptions for systems such as shared storage pools, virtual memory and container runtimes.
Policy and procedures: Write or approve the system and communications protection policy and the procedures for information protection in shared resources, since assessors examine these first.
Sign-off: Review the partner's configuration evidence and make the call on whether it meets your stated requirement.
Operations: Run the monitoring, alert review and change control that keep settings in their approved state over time.
Interviews: Make sure administrators and developers can explain the controls in their own words, because assessors interview them.

Before engaging anyone, confirm internally which decisions are yours and document them.

Where shared resource controls usually fall short

Most failures under 03.13.04 do not come from missing tools. They come from reuse behavior nobody wrote down, cleanup that was tested in one place, checks that ran once, and a boundary drawn too narrowly. Each card names a gap, the action that closes it, and the evidence an assessor will ask to see.

Reuse behavior assumed, not documented

Teams often assume that memory, disk blocks and temporary files are cleared before reuse, but nothing in the system security plan says so. An assessor testing 03.13.04 will look for procedures for information protection in shared system resources and for configuration settings that enforce them. Write down which resources are shared, how each is released, and who owns that step. Then show the settings that implement it, such as the file system and memory behavior of each platform in use.

Cleanup verified in one environment only

Residual data is often checked on a single on-premises server, then assumed to behave the same way in virtual machines, containers or cloud volumes. Reused virtual disks, pod scratch space and snapshot restores can each carry data across tenants or workloads. Test the release and reuse path in every environment that touches CUI, and record the result for each. Ask your platform team to confirm how the hypervisor, orchestrator and storage service zero blocks before reassignment.

Container and ephemeral resources left out

Containers, serverless functions and ephemeral build runners are reused or recreated in ways that bypass traditional cleanup. A process in one pod can leave files in a shared volume that a later pod reads. Document which workloads share volumes, node memory or caches, and define how each is wiped or isolated. Runtime evidence matters here, since static configuration does not show what a running workload actually writes or reads.

No evidence of ongoing checks

A one-time test proves the control worked on the day it ran, not after the next patch, image rebuild or configuration change. Schedule recurring configuration assessments against the hardened baseline and keep the results. Tools such as Wazuh Security Configuration Assessment can check files, directories and running processes against YAML policies and report findings. Pair them with change records so an assessor can see that drift was caught and fixed.

Scope drawn too narrowly

Organizations often define the CUI boundary around the application servers and forget the shared hosts, hypervisors, build systems and management consoles that process or hold the same data. If a shared host sits outside the assessed scope, its reuse behavior never gets tested, and the gap appears only during an assessment or after an incident. Confirm with your assessor which shared resources fall inside the boundary, and document any that are excluded with the reason. Include backup and snapshot infrastructure in that review.

Runtime activity not monitored

Unexpected reads or writes to shared memory, volumes or files may go unnoticed without runtime visibility. Falco parses Linux syscalls at runtime, by default through an eBPF probe, and evaluates them against YAML rules for events such as unauthorized file modification. Decide which rules matter for CUI workloads, route alerts to a system your team reviews, and keep records of triage. Confirm that the probe runs on each node type in your environment before you rely on it as evidence.

How much effort does 03.13.04 take, and can we do it ourselves?

How much effort does 03.13.04 add compared with the other requirements?

On its own, 03.13.04 is one of the smaller items in the Rev. 3 set. It is assessed with two determination statements in SP 800-171A Rev. 3, and its source control is SC-4 from SP 800-53 Rev. 5. The effort rarely comes from the requirement itself. It comes from confirming that every shared resource in scope, such as memory, temporary storage, virtual disks, and reused containers or virtual machines, is cleared before another user or process gets it. Ask your team to inventory those resources first. The size of that inventory, and how many platforms it covers, is what drives the effort. No fixed figure for hours is supplied here, so ask any provider to base its estimate on a written inventory of your environment.

What drives the timeline for implementing object reuse controls?

Timing depends mostly on how many shared resource types your environment reuses and how much of that behavior you already understand. The main drivers are:

The number of platforms in scope, such as hypervisors, container runtimes, shared storage and multi-user application servers
Whether configuration baselines already set sanitization or clearing behavior, and whether those settings are documented
Whether your team can test residual data behavior in a non-production copy before changing production systems
How quickly changes move through your change control process, which the Rev. 3 configuration management family also requires

No duration is supplied for this work, so confirm each driver with your own environment before you set a schedule.

What does the work need from our internal team?

The work needs people who understand how your systems reuse resources, not only people who know the NIST text. Plan for these internal roles:

A system administrator who can explain how memory, disks and temporary files are released and reused on each platform
A security engineer who can translate the two determination statements into tests and documented settings
A system owner who signs off on the system security plan language and accepts the residual risk
Someone who can pull configuration evidence and audit records when the assessor asks for them

The organization owns the control and its decisions. Any implementation partner prepares settings and evidence, and only an independent assessor can judge the result.

Can a small team implement 03.13.04 without an outside partner?

Yes, a small team can often do it internally if it has administrators who know the platforms well and time to test. The requirement is narrow, and the open-source tools that can support it, such as Wazuh Security Configuration Assessment for checking configuration against YAML policies, Falco for runtime syscall monitoring and GitLab container scanning for image review, are free to adopt. The harder part is discipline: testing residual data behavior, documenting it, and keeping it true after each upgrade. If the team lacks that bandwidth or platform depth, a fixed-scope engagement that is agreed in writing before work starts can cover the gap. Ask any provider to state in writing which parts it will do and which your staff must do.

What will an assessor ask to see for 03.13.04?

An assessor working from SP 800-171A Rev. 3 will examine documents, interview people and test mechanisms. For 03.13.04, expect requests for:

The system and communications protection policy and the procedures for protecting information in shared system resources
System configuration settings that show how resources are cleared or sanitized before reuse
System audit records and design documentation that show the mechanisms work as described
Interviews with administrators, developers and people with information security responsibilities
A demonstration of the mechanism in use

The assessor decides the result. Your evidence should match what your system security plan says, so keep those documents aligned.

Does 03.13.04 cover remanence, covert channels and single-user systems?

No. NIST's discussion states that 03.13.04 does not cover information remanence, covert channels or single-user components. That scope limit affects effort directly, because you will not need to build controls for those areas under this requirement. Confirm the boundary with your assessor before you start, and record it in the system security plan so the scope is clear to reviewers. Effort increases if your team treats the requirement as broader than NIST describes.

What recurring work follows once 03.13.04 is in place?

Most of the ongoing cost is operational. Recurring work includes re-checking clearing behavior after patches, upgrades and new platform onboarding, reviewing configuration drift and keeping documentation current. Automated configuration checks can reduce manual review, but they still need someone to read results and act on them. Ask any provider whether it offers ongoing support as a retainer and what that retainer covers in writing.

Which costs are one-time and which recur for this requirement?

One-time costs usually include the initial inventory of shared resources, the design of clearing settings, first-time testing and the first round of documentation. Recurring costs include staff time for reviews after changes, monitoring alerts, and evidence refreshes before each assessment. No supplied fact gives a dollar figure for either. When you request a quote, ask the provider to split one-time and recurring items, name the platforms each line covers, and state what you must supply.

How DeployOpen scopes and prepares evidence for 03.13.04

DeployOpen works on 03.13.04 Information in shared system resources by preparing the systems and evidence that show object reuse and residual information are controlled, not by issuing any assessment result. Your organization owns the control, and an independent assessor decides whether the evidence meets the requirement.

How we scope

Each engagement is fixed-scope, with the systems, environments and deliverables for 03.13.04 agreed in writing before work starts.
The written scope names which shared resources are in view, such as virtual memory, temporary storage, container and VM reuse, and enclave hosts.
Scope also records the policy, procedure and configuration sources the assessor will examine for this requirement.

How we build

We configure and document the sanitization and release mechanisms that prevent residual data from reaching the next user or process.
We deploy host-level monitoring, such as Wazuh configuration assessment policies, to check configuration settings that affect shared resource handling.
We test the mechanisms against the examine, interview and test objects in SP 800-171A Rev. 3 and record the results.

How we hand over

Handover includes the configuration baselines, procedures, design documentation and audit records your assessor will request.
We provide a mapping from each evidence item to the two determination statements for 03.13.04 so reviewers can trace it.
Your organization receives the documentation and access needed to operate the controls and to explain them to an independent assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Retained support can keep configuration baselines current when platforms are upgraded or new shared resources are added.
Confirm with your assessor which evidence formats and retention periods they expect before the handover is accepted.