SI-14(2): Non-persistent Information

SI-14(2) is a requirement you feel most during assessments when an auditor asks a simple question: “Show me that this environment does not retain information after use.” If you cannot answer with diagrams, configurations, and repeatable test results, teams often fall back to vague statements like “it’s in the cloud” or “containers are ephemeral.” That does not pass a serious control review.

“Non-persistent information” is a design and operational constraint. It usually shows up in higher-risk environments where you want to reduce forensic residue, limit data-at-rest exposure, or ensure clean-state operation between sessions (for example, kiosks, VDI, high-side/low-side boundaries, jump hosts, disposable build runners, or segmented analysis sandboxes). In federal contexts and contractor systems handling federal data, it also becomes a contractual and authorization expectation aligned to NIST SP 800-53 Rev. 5 control families.

This page gives requirement-level implementation guidance you can execute quickly: what to scope, what to configure, what to test, and what evidence to keep so you can defend SI-14(2) in an audit without heroics.

Regulatory text

Control: SI-14(2): Non-persistent Information
Excerpt (as provided): “{{ insert: param, si-14.02_odp.01 }} ; and” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning (how to read the excerpt):

• Treat SI-14(2) as a requirement to implement and enforce non-persistence for information in the defined scope, and to support that enforcement with operational mechanisms and evidence consistent with NIST SP 800-53 Rev. 5 expectations. (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON)
• Because the excerpt text is parameterized in the source, your implementation must be anchored to your system-specific assignment/parameter values (what information, which components, what conditions) and then expressed in an assessable way: “Here is the boundary, here is how non-persistence is technically enforced, here is how we verify it.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation (what SI-14(2) is asking you to do)

If your system (or a defined part of it) is supposed to operate with non-persistent information, you must:

1. Stop sensitive or scoped information from being stored persistently (for example, local disks, long-lived volumes, caches, browser storage, temp directories that survive restart, leftover container layers, swap files).
2. Make the non-persistent behavior intentional and consistent, not accidental. Clean state must be a design property, not a hope.
3. Prove it continuously through configuration baselines and validation checks.

A practical test: if an endpoint, VM, container host, or user session restarts, and data from the prior session can still be recovered locally, you likely do not meet the spirit of “non-persistent” for that scope.

Who it applies to (entity and operational context)

Entity types in scope:

• Federal information systems
• Contractor systems handling federal data (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational contexts where SI-14(2) commonly applies:

• Virtual desktop infrastructure (VDI) or kiosk-style endpoints where user sessions must reset to a known-good state.
• Jump hosts / bastions intended to be disposable with minimal local residue.
• Ephemeral compute (short-lived VMs, containers, CI runners) where build artifacts must be pushed to approved repositories and not left on hosts.
• Sensitive analysis environments where you want to minimize data-at-rest footprint on local nodes.

If you run hybrid environments, scope matters. Auditors will accept “only these components are non-persistent” if you can show a clear boundary, a rationale, and consistent implementation.

What you actually need to do (step-by-step)

Step 1: Define the “non-persistent” scope and boundary

Create a short scoping memo (one page is enough) that answers:

• Which systems/components are required to be non-persistent (by hostname pattern, cluster, subnet, environment tag, or authorization boundary).
• What information types are in scope (for example, CUI, authentication material, regulated data classes, investigative data).
• What “non-persistent” means operationally in your environment (for example, “no data remains on local disk after reboot,” “no user profile persistence,” “no local application caches retained”).
  Keep this aligned with your system security plan language for NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5)

Step 2: Map data flows and identify persistence traps

For each in-scope component, document:

• Where data enters (browser, RDP, API calls, file transfer, clipboard).
• Where data could persist:
  • OS temp directories, pagefile/swap, crash dumps
  • Browser caches, downloads folders, cookies/local storage
  • Application caches (package managers, model caches, dataset caches)
  • Container writable layers, node local paths
  • Logging agents buffering on disk
• Where data must go instead (central log platform, approved object store, managed database, encrypted remote profile store).

Output: a simple data flow diagram plus a “persistence trap list” per workload. This becomes your audit narrative.

Step 3: Enforce non-persistence through technical controls

Pick controls that match the platform. Common patterns:

• Immutable images + rebuild, not patch-in-place. Recreate instances from a golden image, destroy on schedule or after session end.
• Ephemeral root disks; restrict or eliminate persistent volumes. If persistent volumes are required, limit them to approved paths and content types, encrypt them, and separate them from “non-persistent” claims.
• Session reset controls for VDI/kiosk: mandatory logoff cleanup, profile discard, block local downloads, redirect storage to managed locations.
• Container controls: disable hostPath mounts for in-scope workloads; prefer ephemeral volumes; enforce read-only root filesystem where feasible; ensure secrets are injected via approved mechanisms and not written to disk.
• OS hardening to reduce residue: disable hibernation, manage crash dumps, control swap/pagefile behavior consistent with your risk decisions, and ensure temp directories are cleared on reboot.
• Logging design: avoid local log retention on non-persistent nodes; ship logs off-host in near real time to a centralized service.

Your goal is consistent behavior under normal use and under expected failure modes (crashes, reboots, scaling events).

Step 4: Implement continuous validation (don’t rely on design claims)

Auditors will ask for proof that the control operates. Build lightweight checks:

• A configuration compliance rule set (CIS-style checks or custom) that asserts key settings (no persistent volumes attached, temp cleanup enabled, prohibited mounts blocked).
• A periodic “persistence test” procedure for each workload type:
  • Write a known marker file to typical persistence locations.
  • Restart/terminate/recreate the node or session.
  • Confirm the marker is gone and cannot be recovered from the instance.
• Alerting when drift occurs (for example, a persistent disk attached to an in-scope instance, or a policy exception created).

Store the results as evidence (see below).

Step 5: Assign ownership and make evidence recurring

SI-14(2) fails in practice when it is “owned by everyone.” Assign:

• Control owner: usually Infrastructure/Security Engineering.
• Operators: EUC/Workplace for VDI, Platform team for Kubernetes, DevOps for CI runners.
• Evidence owner: GRC or Compliance Ops, responsible for collecting and retaining artifacts per cycle.

Daydream (as a workflow, not a slogan) fits here as the system of record to map SI-14(2) to an owner, procedure, and recurring evidence artifacts so you are not rebuilding the evidence set every audit.

Required evidence and artifacts to retain

Maintain an “SI-14(2) evidence pack” that is small but decisive:

Design and scope

• Scope statement: in-scope components, exclusions, rationale.
• Architecture diagram and data flow diagram for each non-persistent workload.
• Standard(s) for non-persistent builds (golden image policy, ephemeral workload standard).

Configuration and enforcement

• Golden image build pipeline configs (IaC, Packer/AMI build steps, hardening scripts).
• Endpoint/VDI policies or MDM configuration profiles showing non-persistence settings.
• Kubernetes policies (OPA/Gatekeeper/Kyverno) or equivalent guardrails preventing persistent mounts for in-scope namespaces.
• Cloud configuration evidence: instance templates, launch configurations, disk settings, lifecycle rules.

Validation and monitoring

• Results of periodic persistence tests (date, executor, outcome, exceptions).
• Drift detection reports (policy violations, blocked actions).
• Exception register for any approved persistence (what, why, compensating controls, expiration).

Governance

• Control narrative mapped to SI-14(2) in your SSP/control matrix aligned to NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5)

Common exam/audit questions and hangups

Auditors tend to focus on these points:

1. “Define non-persistent for this system.” If your definition is implicit, you will lose time. Write it down.
2. “Show me that a reboot clears data.” Be prepared with a test record and, if needed, a live demo in a non-production clone.
3. “What about logs, caches, and crash dumps?” These are frequent hangups because teams forget them. Your trap list and hardening baselines should address them.
4. “Where does data go instead?” Non-persistent does not mean “no storage.” It means “no local residue.” Show approved remote destinations and access controls.
5. “How do you prevent drift?” If a developer can attach a persistent disk tomorrow, auditors will ask how you stop it.

Frequent implementation mistakes and how to avoid them

• Mistake: Calling containers “ephemeral,” but mounting host storage. Fix with explicit admission controls and namespace policies that block persistent mounts for in-scope workloads.
• Mistake: Ignoring browser and user profile persistence in VDI. Fix with enforced profile discard and redirection to managed storage when persistence is required for business.
• Mistake: Relying on manual cleanup. Fix by building cleanup into session termination, instance lifecycle automation, and configuration management.
• Mistake: No exception process. Non-persistent environments often need limited persistence (updates, drivers, special tooling). Document exceptions with expiration and compensating controls.
• Mistake: Evidence built once for an ATO, then stale. Fix by defining recurring evidence collection (build pipeline outputs, policy reports, test results) and tracking it in a control system of record.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for SI-14(2), so this page does not cite enforcement actions.

Risk-wise, SI-14(2) breakdowns usually show up as:

• Increased likelihood of data-at-rest exposure on endpoints and transient compute.
• Harder incident containment because artifacts persist outside managed repositories.
• Assessment findings for “control not implemented as described” when non-persistence is claimed but not enforced.

Practical 30/60/90-day execution plan

Because this requirement is parameterized and environment-specific, focus on outcomes per phase rather than time-based promises.

First 30 days (Immediate)

• Name the SI-14(2) owner and backup.
• Publish the scope statement and definition of “non-persistent” for your environment.
• Inventory in-scope components and document initial data flows.
• Identify top persistence traps and decide: eliminate, redirect, or manage by exception.

By 60 days (Near-term)

• Implement guardrails (IaC controls, policies) that prevent new persistence paths in-scope.
• Standardize golden image or baseline configuration for each in-scope platform.
• Create and run the first round of persistence tests; record results and exceptions.
• Stand up recurring evidence capture (policy reports, build artifacts, test logs) in a central repository.

By 90 days (Operationalize)

• Expand validation coverage across all in-scope workload types.
• Add drift alerting and a defined response playbook (who triages, who remediates, how exceptions are approved).
• Update SSP/control narrative to reflect actual implementation and evidence locations aligned to NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5)
• If you use Daydream, map SI-14(2) directly to the owner, procedure, and recurring evidence artifacts so the control stays assessment-ready as systems change.

Frequently Asked Questions

What counts as “persistent” storage for SI-14(2)?

Anything that can retain data across a reboot, session reset, or instance replacement can be persistent in practice, including local disks, attached volumes, caches, and buffered logs. Define persistence in your scope memo and test against real restart/terminate scenarios.

Can I meet SI-14(2) if I ship logs to a central SIEM?

Often yes, if local log retention is minimized and your design ensures logs leave the non-persistent node promptly. Keep configurations that show off-host log shipping and evidence that local storage does not accumulate sensitive residue.

We need some persistence for user settings in VDI. Does that violate SI-14(2)?

Not automatically. Document what persists, why it is necessary, where it is stored, and what controls protect it, then narrow your “non-persistent” claim to everything else.

How do auditors typically verify non-persistence?

They ask for architecture and configuration evidence, then request a repeatable validation method. A simple marker-file test across reboot/terminate cycles, recorded and retained, usually resolves the debate quickly.

Do ephemeral cloud instances automatically satisfy SI-14(2)?

No. Ephemeral compute can still write to local disks, caches, and temp locations during runtime. You need enforced configurations and validation that instances do not retain scoped information after lifecycle events.

What’s the minimum evidence set to keep for SI-14(2)?

Scope definition, an architecture/data flow diagram, baseline configurations (image or policy), and recent validation results. Add an exception register if any persistence is approved.