SI-14 Non-persistence: requirements and evidence

What SI-14 non-persistence requires and why it is easy to miss

If a tailored baseline, an overlay or an assessor has handed you SI-14, the first thing to know is that the control asks for something most teams never configured on purpose. SI-14 requires the components and services you define to be non-persistent: each one starts from a known state and is terminated at the end of a session or on another trigger you set. The attacker risk it addresses is simple. An intruder who gets a foothold in a long-lived workload, virtual machine or endpoint can plant a backdoor, change configuration or stash tooling that survives for weeks. A component that is rebuilt from a trusted image on a schedule or per session gives that persistence much less room to survive. Because your organization chooses the components and triggers, the control is only as strong as those choices.

SI-14 is absent from every SP 800-53B baseline (low, moderate, high and privacy), so it appears only when your organization or an overlay selects it. Appendix C of SP 800-53 Rev. 5 marks it as organization-implemented and as an assurance-related control, which means the evidence an assessor expects comes from your design decisions and their operation, not from a vendor feature. In Release 5.2.0 the control has three organization-defined parameters and three control enhancements, all active, and none of those enhancements is assigned to a baseline. Read the catalog entry in the OSCAL content before you scope it, and confirm with the tailoring authority which parameters they expect you to fill in and whether they want any enhancement implemented.

The practical decision is which components to make non-persistent and what the trigger is. Ask whether the scope covers only containers and virtual machines or also endpoints, and whether the reset is a fixed schedule, a session end or a condition such as a failed integrity check. Once those are written down, the evidence set is design documentation, configuration settings and audit records showing rebuilds happening as stated. The assessment procedure for SI-14 in NIST SP 800-53A uses examine, interview and test methods against exactly those artifacts, so plan to produce them from the start.

Which systems and teams SI-14 applies to once it is selected

SI-14 does not reach any baseline, so the organization decides which components must be non-persistent, what triggers a rebuild and who answers for each one. Those choices are documented scope, not a default, and they determine how much rebuild work the control creates.

Container and stateless workloads

Containerized application tiers that hold no local state are the most common candidates, because a fresh container from a known image is the natural form of non-persistence. Check whether each workload writes to its own filesystem, keeps session data in memory or relies on node-local caches. Any of these must be moved out of the container before the workload can be defined as non-persistent. Record the decision for each service in the system design documentation.

Virtual desktops and session hosts

Virtual desktop sessions that reset to a golden image at logoff are a classic SI-14 design, since a browser or document compromise cannot survive the reset. The control requires that user profiles, downloads and application data live outside the session. Confirm whether users can save files locally, whether printers or redirected drives keep state, and how the image is patched and reissued.

Build agents and ephemeral runners

CI build agents are attractive candidates because a compromised runner can poison later builds. Scope them by deciding whether each job gets a fresh instance, how caches and dependency stores are handled and whether secrets are injected per job instead of stored on disk. Build outputs and signing keys usually need their own controls, so confirm that the rebuild does not remove the evidence that the pipeline must keep.

Administrative jump hosts

Privileged access paths are high-value targets, and rebuilding them per session limits what an intruder can keep. The scope decision is whether the jump host resets after each administrative session and where session recordings, audit records and access approvals are written. Those records must leave the host, or the reset will also erase the evidence an assessor will examine under the SI-14 procedures.

Externalized data and state

Non-persistence only works when the data a component needs is kept somewhere else. Inventory the databases, object stores, configuration sources, secrets stores and logs that each candidate depends on, and confirm that each is backed up, access-controlled and outside the rebuilt component. Logs and audit records also need a destination that survives the reset, which ties this card to the audit family.

Owners of images, pipelines and exceptions

Name one owner for each golden image or base image, one for the rebuild pipeline and one for every documented exception. Platform engineering commonly owns the pipeline, security owns the rebuild triggers and the business owner signs off on exceptions for components that must keep state. Write these assignments into the control implementation statement so an assessor can trace each component to an accountable team.

How an assessor tests SI-14 against SP 800-53A

This table maps each SP 800-53A Release 5.2.0 assessment method for SI-14 to the objects an assessor requests, the evidence that passes and the findings that appear most often. Read it as a preparation checklist: the organization should be able to show its defined components, its rebuild configuration and its audit trail before the assessor asks.

Method or statement	What the assessor requests	Evidence that passes	Common finding
Both determination statements	Confirmation that each organization-defined non-persistent component and trigger is met in practice	A written list of defined components with the rebuild trigger for each	Defined list does not match what actually runs in production
Examine: system design documentation	Architecture showing which components are rebuilt, and how a clean state is established	Design documents that name each non-persistent component and its base image	Design describes a persistent host that is never reimaged
Examine: configuration settings and documentation	Settings that enforce rebuild or session termination, and the procedures that describe them	Golden image or template settings, session timeout values and the matching runbook	Settings exist but the runbook was never updated after a change
Examine: system audit records	Logs showing rebuilds, session ends and the trigger that started each one	Timestamped records that link a terminated instance to its replacement	Rebuild events cannot be shown in audit records
Interview: operations and platform staff	Explanation of how rebuilds are initiated, approved and verified	Consistent answers that match the design and configuration documents	Staff describe a manual process that the documents do not mention
Test: observed rebuild or session end	Observation of a component being terminated and recreated from its known state	Recorded run showing the instance returns to the approved baseline	Replacement carries over state, data or configuration drift
Scope check against tailoring decision	Evidence that SI-14 was selected through tailoring or an overlay, since no SP 800-53B baseline assigns it	Tailoring record that explains the selection and the components in scope	Control is claimed without a documented selection decision

Implementing SI-14 in the order an assessor will check it

This sequence takes SI-14 from an organization's decision to use non-persistent components through to a tested rebuild and a documented exception rule, so each step leaves evidence an assessor can examine. Because SI-14 is not in any SP 800-53B baseline, the first step is confirming that the organization has selected it through tailoring or an overlay.

Confirm selection and define the parameters
Start by confirming that SI-14 is in scope, either because the organization tailored it into its control set or because an overlay requires it, since no SP 800-53B baseline assigns it. Then define the organization-defined parameters for the components and services that must be non-persistent and the triggers that end a session or force a rebuild, such as session termination or a scheduled interval. The output is a signed parameter record that names each component, its trigger and its owner. Ask the assessor's expected format for this record before writing it, and confirm the current parameter count against the Release 5.2.0 catalog.
Document the known-state source and its change control
A non-persistent component is only as trustworthy as the image or template it starts from, so define the golden source for each component type, such as a hardened machine image, a base container image or a configuration-managed template. Record who may change that source, how changes are reviewed and how the source is versioned. The output is a documented known-state baseline with a change log, which connects SI-14 to the configuration management records the organization already keeps. Confirm with the assessor whether the baseline must be reviewed on a defined cycle.
Build the rebuild mechanism
Implement the mechanism that recreates components from the known-state source. Depending on the environment, this is reimaging physical or virtual hosts, redeploying virtual machines from templates or redeploying containers from signed images. Open-source platforms that run in the client's own infrastructure can supply much of this layer, and DeployOpen can prepare and configure it as part of a fixed-scope engagement. The output is a working mechanism and a configuration record showing which triggers call it. Confirm with the platform vendor which rebuild features are native and which need custom automation.
Externalize state that must survive a rebuild
Non-persistence only works if data that must be kept is stored outside the rebuilt component. Identify logs, configuration secrets, application data and audit records that must survive a rebuild, then move them to externally managed storage with its own protections. Record the data classification and storage location for each item. The output is a state inventory that shows what is lost on rebuild and what is retained, which an assessor can compare against the parameter record. Check that state moved off the component still meets the organization's controls for protection, retention and access.
Enable logging of session ends and rebuilds
Configure logging so every session end, trigger and rebuild produces an audit record. Without these records, an assessor cannot confirm that the control operated, and the organization cannot investigate an event that happened on a component that no longer exists. Send these records to a central store outside the rebuilt components, and confirm they are retained under the organization's audit policy. Runtime monitoring tools such as Falco, which can evaluate Linux system calls against rules, may help detect unexpected changes before a rebuild. The output is a log source list and sample records showing a session end and a rebuild.
Test a rebuild end to end
Run a full rebuild test on a representative component: trigger the rebuild, confirm the component starts from the known-state source, confirm externalized state is restored correctly, confirm the audit records were written, and confirm the component returns to service with its expected configuration. Record the result, including any deviations and how they were resolved. The output is a tested rebuild runbook with dated test results signed by the owner. An assessor will expect the evidence to come from an actual run, so keep the test record and the logs it produced together.
Write the exception rule
Some components cannot be non-persistent, such as systems that hold long-lived state or legacy hardware. Write a rule that defines who may approve an exception, what compensating controls must apply, how long an exception may last and how it is reviewed. Record each approved exception in the parameter record or a linked register. The output is an approved exception policy and a register of current exceptions, which an assessor will check against the defined components. Confirm the review frequency with the organization's own policy owner and any assessor requirements before finalizing the rule.

Open-source tools that produce SI-14 evidence

Falco is an Apache-2.0 licensed runtime security tool. It parses Linux system calls, by default through an eBPF probe, and evaluates them against YAML rules. For SI-14, its value is evidence that a workload behaved as expected during its session and that unexpected changes were recorded. Its alerts can show unauthorized file modification or suspicious process execution on a node that was supposed to be rebuilt from a known state.

Runtime alerts: Falco can emit alerts for events such as unauthorized file modification, unexpected network connections and privilege escalation, which an assessor can compare against the expected session lifecycle.
Container and Kubernetes context: Events are enriched with container and Kubernetes metadata, so records can be tied to a specific workload.
Output destinations: Alerts can go to stdout, files, syslog, HTTP endpoints or programs, so you can retain them in your own log system.
What it does not prove: Falco does not show that a component was reimaged or terminated at session end. Pair its records with deployment and teardown logs.
License caveat: Apache-2.0 permits use, but confirm the rule sets and any add-on content you adopt carry terms you accept.

Confirm in your own environment that the eBPF probe runs on your kernel and node images, and that alerts reach your retention store before relying on them as SI-14 evidence.

Evidence that passes an SI-14 assessment and how to keep it current

An assessor testing SI-14 looks for proof that the organization defined which components are non-persistent, what known state they start from, and that the rebuilds actually happen. Each artifact below should be generated or updated through normal operations rather than rebuilt for each audit, so the evidence stays accurate between assessments.

Defined component and trigger list

This is the organization-defined list of components and services that must be non-persistent, along with the trigger for each one, such as session end or a fixed schedule. Assessors check that the list matches what is deployed. Regenerate it from the platform's inventory or orchestrator (for example, the list of pods, virtual machine templates or session hosts) on a defined cadence, and record who approved changes to it. A list written once and never compared with live systems is the most common gap.

Known-state image and definition

The golden image, container image or infrastructure template that every rebuild starts from must be identifiable by version and checksum. Keep its build definition in version control, record the change history with reviewer sign-off, and confirm that each running instance traces back to a specific approved version. Ask the assessor which image sources they will accept as the known state, and confirm your own build pipeline produces signed, reproducible artifacts before the audit.

Configuration settings for non-persistence

Capture the settings that make persistence impossible or limited: read-only root filesystems, ephemeral storage, disabled writable mounts, and session-bound profile handling. Export these from the platform configuration and store the output with its documentation, so a reviewer can see the setting values as they were at a given date. Re-export after every change to the platform and compare against the last approved baseline.

Rebuild and session-end records from audit logs

Audit records should show each component being destroyed or reimaged at its trigger, with timestamps and the identity of the automation or operator. Forward these events from the orchestrator and host to a central log store that the organization controls, and set retention to cover the audit period. Sampling the log for a few components across the period is how an assessor tests that the trigger actually fired.

Rebuild exercise test records

Run a planned rebuild of selected components from the known-state image and record the outcome: time taken, configuration drift found, failed steps and how they were resolved. Keep the test plan, the results and the remediation tickets together. Repeat the exercise after major image or platform changes so the records reflect current behavior, not the state at the first test.

Exception approvals

Some components cannot be non-persistent, such as those that hold state by design. Each exception needs a documented justification, a named risk owner, compensating controls, and an expiry or review date. Tie exceptions to the change process so that a component's removal from the non-persistent list is approved and logged. Confirm with your assessor how they expect exceptions to be recorded, since the wording of acceptance is an organizational decision.

What meeting SI-14 costs in money and effort

This table lists the cost components of putting SI-14 Non-persistence in place, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. NIST does not estimate compliance costs, so no figures appear here; use the drivers to structure a written quote and compare like with like.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Engineering to build the rebuild mechanism	Internal platform engineers or an implementation partner under a fixed-scope agreement	One-time, with later changes recurring	Number of component types, how many images or builds must be rebuilt, and whether reimaging or virtualization is already in place
State externalization	Internal engineers or implementation partner	One-time, then recurring as data flows change	How much state must move out of the component (logs, configuration, secrets, persistent data) and how many services depend on it
Tooling and licenses	Vendors for commercial products; no license fee for Apache-2.0, MIT or GPL-2.0 tools, though hosting and staff time still apply	Recurring for commercial tools; infrastructure recurring for self-hosted tools	Choice of commercial versus open-source tooling, number of endpoints or nodes monitored, and retention of audit records
Evidence upkeep	Internal compliance and platform teams	Recurring	Frequency of rebuilds and changes to golden images, how often configuration settings are re-exported, and how many systems must be evidenced
External testing or review	Independent testers or consultants, scoped in writing	Recurring at each test cycle	Whether tests cover the rebuild process itself, the number of environments, and whether findings require retesting
Auditor or assessor sampling	Independent auditor or assessor, quoted per engagement	Recurring at each assessment	Number of systems selected, how clearly rebuild schedules are documented, and whether audit records are easy to retrieve
Internal coordination and change approvals	Internal staff across operations, security and application owners	Recurring	Frequency of change windows, number of teams that own components, and whether rebuilds are automated

Where SI-14 implementations usually fall short

SI-14 Non-persistence is a short control with a lot of implied infrastructure behind it. Most shortfalls come from the same place: the organization never wrote down which components are meant to reset, what they reset to, and who approves that known state. The cards below cover five gaps that assessors tend to find and the specific action that closes each one.

Undefined component list

SI-14 requires the organization to define which system components and services are non-persistent, and an assessor cannot test a boundary nobody wrote down. Teams often assume that container workloads or virtual desktops are covered, while the hosts beneath them or a few long-lived service VMs are not. Close it by producing a named inventory of non-persistent components, each with its owner, its reset trigger and its session or schedule boundary, and reconciling that list against the system security plan.

Rebuilds with no record

A reimage or redeploy that happens silently cannot be shown to have happened, so the assessor's examine methods have nothing to read. SP 800-53A points assessors toward system audit records for this control. Close it by configuring the rebuild pipeline to log every reset with the component ID, the image or known-state reference, the trigger and the timestamp, and retaining those logs under the organization's audit policy.

Persistent state on the component

Non-persistence fails quietly when application data, credentials, logs or cached secrets live on the component that is supposed to reset. A rebuild then restores the attacker's foothold along with the operating system. Close it by moving state to external stores the component connects to, mounting writable paths as ephemeral, and running a check after each reset that confirms no unexpected files or configuration survived the rebuild.

Known-state source outside change control

The known state is only as trustworthy as the golden image, template or build script it comes from. If those artifacts can be edited without review, an attacker or an unreviewed change can make every rebuild reproduce the compromise. Close it by placing images and build definitions under configuration management with approval, versioning and integrity checks, and recording which approved version each component was rebuilt from.

Undocumented SI-14 decision

SP 800-53B does not assign SI-14 to any baseline, so many systems never select it and nobody records that decision. An assessor then asks why a sensitive workload was not made non-persistent and receives no answer. Close it by recording an explicit selection or rejection of SI-14 in the control implementation statement, with the rationale, the risk accepted and the reviewer, and revisiting that decision whenever the system boundary or threat profile changes.

Who does what for SI-14: your team, a partner and the auditor

Your organization owns SI-14. Only you can decide whether the control applies, because SP 800-53B does not assign SI-14 to any baseline and it applies only when you select it through tailoring or an overlay. Once selected, you must define the system components or services that will be non-persistent, the trigger that ends their life (such as end of session or a scheduled rebuild) and the parameters the control leaves for you to set. Accepting the residual risk and signing the system security plan stay with your leadership, not with any vendor.

Selection decision: Record in the tailoring rationale why SI-14 is in or out for each system, referencing the system's threat model.
Parameter values: Set the organization-defined parameters for which components reset, how often and from which known-good image.
Golden image authority: Name the owner who approves the baseline image or template that every rebuild starts from.
Exception handling: Decide who may grant exceptions for stateful workloads such as databases and who reviews them.
Acceptance: Review the evidence package and accept or reject the control before the assessor begins testing.

Before engaging anyone, confirm internally that you can name each of these owners, because the assessor will ask who approved the parameters.

Common questions about SI-14 non-persistence

Is SI-14 non-persistence required in any NIST SP 800-53 baseline?

No. SP 800-53B does not assign SI-14 to the low, moderate or high baselines or to the privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization and marks it as an assurance-related control. FedRAMP's Rev5 baselines also do not require it at Class B, C or D. If a contract, agency or assessor asks for SI-14, the requirement usually comes from the tailoring decision or from a specific overlay, so ask for that document before scoping the work.

How much effort does SI-14 take, and what drives it?

Effort depends mostly on how many components you decide must be non-persistent and how often they are rebuilt. SI-14 has three organization-defined parameters and three control enhancements in Release 5.2.0, so the policy decisions alone can take time before any technical work starts. Other drivers include whether workloads already run from immutable images, how much state lives outside the rebuilt components, and how well the build pipeline is documented. Ask any provider to break the effort into design, build pipeline changes, testing and evidence collection, and to state which components are in scope.

How long does implementing SI-14 usually take?

The timeline is set by the scope you agree, not by the control itself, and no supplied source gives a standard duration. The main factors are the number of component types, the maturity of your image and configuration pipelines, the state that must be separated from rebuilt systems, and the change approval process for production. Teams that already manage infrastructure as code often move faster than teams relying on manual builds. Request a written timeline tied to named deliverables, and confirm which dependencies, such as access to cloud accounts or change windows, sit with your team.

What does the internal team need to provide for SI-14?

The internal team owns the decisions that the control depends on. Expect to supply the list of components to be non-persistent, the defined triggers such as session end or a rebuild schedule, the location of persistent data and logs, and approval for changes to production build and deployment processes. Your team also owns the system security plan entries and the evidence the assessor will examine, including system design documentation, configuration settings and audit records. An implementation partner can prepare systems and evidence, but your organization remains responsible for the control.

Can we implement SI-14 in-house with open-source tools?

Often yes, if your team already runs automated builds and has the skills to maintain them. Open-source tools cover parts of the evidence trail. Falco, which is Apache-2.0 licensed, can detect unexpected changes at runtime through an eBPF probe and send alerts to your logging systems. Wazuh, which is GPL-2.0-only, can check endpoints against YAML configuration policies. Fleet, which is MIT licensed, can run osquery policies that show which devices pass or fail a check. These tools help show behavior, but they do not rebuild systems by themselves, so confirm each tool's capabilities against your own environment before relying on it.

How does SI-14 relate to SC-30, SC-34 and SI-21?

SI-14 is related to SC-30, SC-34 and SI-21 in the Release 5.2.0 catalog. SC-30 covers concealment and misinformation, SC-34 covers non-modifiable executable programs, and SI-21 covers information refresh, which regenerates or deletes information on a schedule. Together they address the same goal from different angles: limiting how long an attacker can keep a foothold in a component or in stored information. Because these are separate controls, each needs its own assessment, its own evidence and its own organization-defined parameters, so do not treat one implementation as satisfying all four.

What evidence will an assessor ask for to test SI-14?

SP 800-53A Release 5.2.0 assesses SI-14 through two determination statements using the examine, interview and test methods. The examine objects named for this control include system design documentation, system configuration settings with their associated documentation, and system audit records. In practice, that means documented non-persistence decisions, build and rebuild configuration, records showing components were restarted from a known state, and logs that confirm the schedule or session triggers ran. Confirm with your assessor which test methods they will use and what sample of records they expect.

How DeployOpen scopes and prepares SI-14 evidence

DeployOpen works on SI-14 Non-persistence as a fixed-scope engagement inside your own infrastructure. We prepare the systems and evidence an assessor would examine, while your organization owns the control decision and an independent assessor issues any findings.

How we scope

Confirm in writing whether SI-14 is selected through tailoring or an overlay, since no SP 800-53B baseline includes it.
Name the defined components and services that must be non-persistent, plus the session or schedule trigger for each.
List the three organization-defined parameters and which of the three enhancements your organization has chosen to adopt.

How we build

Design rebuild-from-known-state workflows, such as reimaging or ephemeral virtual machines, for the components in scope.
Deploy self-hosted runtime monitoring such as Falco to record changes that would otherwise persist between rebuilds.
Configure audit logging so rebuild events and configuration settings can be examined against the SI-14 assessment objects.

How we hand over

Document system design, configuration settings and rebuild procedures so an assessor can examine them directly.
Provide audit record samples and test results showing that components return to the defined known state.
Deliver a written mapping of each SI-14 determination statement to the artifact and owner that supports it.

How we support

Offer ongoing support, upgrades and continuous testing for rebuild pipelines and monitoring as a retainer.
Review configuration drift after platform upgrades so evidence stays current with the deployed environment.
Confirm with your assessor which evidence format and sampling they expect before the assessment begins.