SI-21 Information refresh: requirements and evidence

What SI-21 information refresh requires and why it is easy to miss

SI-21 Information refresh asks an organization to do one of two things with defined information: refresh it at defined frequencies, or generate it on demand and delete it once it is no longer needed. Its purpose is to limit how long stale or compromised information stays in a system where it can be relied on or exploited. If your team has been told SI-21 applies, the most likely cause is that someone tailored a baseline or added an overlay that selected it, because SP 800-53B does not assign SI-21 to the low, moderate, high or privacy baseline. Nothing in the standard's baseline selection will bring it into scope for you.

That absence is why the control is easy to miss. Most teams finish baseline selection, see no SI-21 entry, and move on, while the organization that adopted an overlay or customized its baseline may never have read the control's two organization-defined parameters. Those parameters are the hard part. The organization must decide which information is refreshed or regenerated, and at what frequency or trigger. Until those decisions are written down, there is nothing for an assessor to test. Confirm with your overlay or sponsoring authority whether SI-21 was selected deliberately, and check whether FedRAMP's Rev5 baselines are relevant to you, since they do not require SI-21 at Class B, C or D.

Start by reviewing the tailoring record and any overlay for SI-21, then list the information stores in scope, such as reference data, cached credentials, lookup tables or configuration content. For each one, record the refresh interval or on-demand trigger and the deletion point. The SP 800-53A assessment procedure for SI-21 examines a list of the information to be refreshed, the system design documentation and the system configuration settings. Build those three artifacts first, because a refresh schedule that exists only in someone's memory will not satisfy an examiner. Consult the SP 800-53 Rev. 5 publication and the SP 800-53A procedure before you commit to a frequency.

Which systems and information fall under SI-21 information refresh

SI-21 applies only when an organization selects it through tailoring or an overlay, because no SP 800-53B baseline assigns it. The scope therefore starts with a deliberate decision about which information stores matter, and the organization-defined parameters then set how often each one is refreshed or deleted. The cards below cover the decisions that change the work the most.

Selecting the information stores

Start with an inventory of the information the system relies on for decisions, access or operations, then decide which stores need a refresh or deletion rule. The SI-21 requirement applies to the defined information, so a store left out of the list is outside the control's scope. Document each inclusion and exclusion in the tailoring record, along with the reason. Assessors will compare the list of information to be refreshed against the system design documentation, so the two must match.

Caches and derived copies

Caches, replicas, search indexes and precomputed reports are copies of information that can drift from the source. Decide whether each copy is refreshed on a schedule, regenerated on demand from the source, or deleted after use. A stale cache that feeds an authorization or pricing decision is a clear candidate for selection, while a short-lived rendering cache may not be. Confirm with the system owner which copies exist, since they are often created by frameworks and not listed in architecture diagrams.

Reference data and configuration baselines

Reference data such as lookup tables, sanctions lists, rate tables and trust store contents can become stale or be tampered with over time. Decide which of these change the system's security or business outcomes, and set a refresh frequency tied to the publisher's update cycle. Record the authoritative source for each dataset, so the refresh can be traced to a known origin during an assessment.

Credentials, keys and tokens

Credentials are information that can be exploited for a long time after compromise, so organizations often treat their rotation as an SI-21 decision. Confirm whether the organization has selected SI-21 for credentials, or whether those are handled under the authenticator management controls in the IA family, and avoid documenting the same mechanism twice. Where SI-21 covers them, define the rotation frequency and the deletion rule for retired secrets, and test that revoked values no longer work.

Threat intelligence and generated content

Threat indicators lose value as they age, and AI-generated or model-produced content can be stored and reused long after the conditions that produced it have changed. Decide whether these stores fall within the selected information, and set expiry rules that match how quickly they become unreliable. Ask the system owner which generated outputs persist in logs, tickets or knowledge bases, since these are commonly missed.

Owners and third parties that hold the data

Map which teams, service providers and cloud services hold or regenerate each selected store. Refresh duties often sit with a platform team, while the data owner sets the frequency and a third party may run the regeneration job. Put each duty in a responsibility matrix and in any service agreement that touches the data. Assessors will ask who approves a change to a parameter and who evidences that the refresh ran.

How an assessor tests SI-21 information refresh

This table walks through the single SP 800-53A determination statement for SI-21 and the examine, interview and test methods an assessor applies to it. Use it to see which artifacts to prepare, which questions staff should be ready to answer, and where refresh programs most often fail. The main takeaway is that an assessor needs a defined list, defined frequencies and proof that the schedule actually ran.

Assessment element	What the assessor checks	Evidence that passes or where it fails
Determination statement	Whether the organization refreshes defined information at defined frequencies, or generates it on demand and deletes it when no longer needed	Passes when each refresh job maps to a stated frequency or trigger. Fails when the schedule exists only in staff memory
Examine: list of information to be refreshed	Whether the organization has listed the information in scope and the parameters chosen for it	Passes with a dated list naming each data set, owner and refresh interval. Fails when the list is missing or not updated after system changes
Examine: system design documentation	Whether the design explains where refreshed or regenerated information lives and how deletion happens	Passes when diagrams and design notes show the refresh flow and deletion points. Fails when design documents omit backup or replica copies
Examine: configuration settings and associated documentation	Whether scheduler, job or retention settings implement the stated frequencies	Passes with exported job schedules, cron or pipeline definitions and change records. Fails when settings drift from the documented interval
Interview	Whether system owners, data owners and operators know what is refreshed, how often, and who approves changes	Passes when answers match the list and configuration. Fails when owners give different intervals or cannot name the approver
Test: refresh job	Whether a scheduled refresh or deletion actually runs and produces the expected result	Passes with run logs, timestamps and before-and-after checks on a sample. Fails when logs are absent or jobs silently error
Common finding: undefined frequencies	Whether the organization set the organization-defined parameters at all	Frequently raised when the parameters are blank or say only as needed. Resolve by writing numeric intervals and triggers
Common finding: no evidence the schedule runs	Whether operating records prove the schedule executed over the assessment period	Frequently raised when jobs exist but no run history is retained. Resolve by keeping job logs and exception tickets

How to implement SI-21 in the order an assessor will check it

This sequence takes SI-21 from a selection decision to a documented, tested and reviewed refresh or on-demand generation process. Each step produces an artifact that an assessor can trace back to the control text and the SP 800-53A procedure.

Confirm SI-21 selection through tailoring
Start by confirming that SI-21 is in the control set for this system. SP 800-53B does not assign it to the low, moderate, high or privacy baseline, so it appears only because the organization selected it through tailoring or an overlay. The system owner and the risk management lead record the selection, the reason for it and the risk it addresses in the system security and privacy plan. Done means the plan lists SI-21 with a documented rationale, and an assessor can see who approved it.
Define the information and both parameters
SI-21 has two organization-defined parameters, which the organization must set itself. The first identifies the information to be refreshed or generated on demand, such as lookup tables, reference data, cached credentials or configuration content. The second sets the refresh frequency or the conditions under which information is generated and then deleted. Record each item in a list of information to be refreshed, with its owner, its source and its parameter values. Done means every parameter has a concrete value and an owner, not a placeholder.
Design the refresh or on-demand lifecycle
For each item, decide whether it is refreshed from an authoritative source on a schedule or generated when needed and deleted after use. Document the trigger, the source of truth, the expected data handling and the deletion point. Record the design in system design documentation so the reviewer can trace how each parameter is met. Done means a reviewer can read the design and predict what the system does at each refresh event without asking the engineers.
Configure the refresh jobs and deletion rules
Implement the design in system configuration: scheduled jobs, pipeline steps, cache expiry settings or on-demand generation routines, plus the deletion logic. Keep configuration in version control so changes are attributable. Restrict who can alter the schedule or the source. Done means the configuration matches the design document and the settings are recorded in a form an assessor can examine.
Test refresh and deletion against the parameters
Run the refresh and deletion paths in a test environment and confirm that information is refreshed at the defined frequency, generated only when required and removed when it is no longer needed. Test a failed refresh as well, so the team knows what happens when the source is unavailable. Keep the test records, including inputs, timestamps and results. Done means each parameter has a test result that shows it works as defined, and failures have a recorded disposition.
Collect evidence the assessor can examine
Gather the evidence that maps to the examine objects in SP 800-53A: the list of information to be refreshed, the system design documentation, the configuration settings and their associated documentation, and the test records. Store them with version identifiers and dates. The implementation partner can prepare this package, but the organization owns it and presents it to the independent assessor. Done means each examine object has a current artifact and the package can be reproduced for the same system state.
Set a recurring review of the control
Set a review that checks whether the information list, parameter values and configuration still match the system. Trigger an out-of-cycle review after significant changes, such as a new data source or a changed deployment model. Record review outcomes and update the system security and privacy plan where the parameters change. Confirm the review owner and the review trigger in the plan. Done means the review has an owner, a documented trigger and a dated record of the last review.

How SI-21 differs from SI-14 non-persistence

SI-21 and SI-14 both limit how long something can be trusted, but they act on different things. SI-21 targets information: it requires an organization to refresh defined information at defined frequencies, or to generate it on demand and delete it when no longer needed. SI-14 targets components: it requires rebuilding system components from a known state on a schedule or per session, such as reimaging a host or redeploying a virtual machine, so that an attacker cannot persist inside them. SI-14 is the only related control the Release 5.2.0 catalog lists for SI-21, which signals that the two are close neighbors in the SI family, not substitutes for one another.

The practical difference shows up in what you inventory. For SI-21, the organization must maintain a list of the information to be refreshed (the assessment procedure examines exactly that list, along with system design documentation and configuration settings), and each entry needs an organization-defined refresh frequency or deletion trigger. For SI-14, the question is which component images, containers or sessions are rebuilt and from what authoritative source. A cached lookup table, a set of signing material or a directory extract is an SI-21 question. A web server image or an ephemeral build runner is an SI-14 question. Confirm which of the two organization-defined parameters in SI-21 your system actually uses before writing either control statement.

Both controls can apply to the same system, and often should when a system is selected for both. A stateless application tier rebuilt from a golden image under SI-14 may still hold cached data, session stores or derived datasets that persist across rebuilds, and those fall under SI-21. Conversely, refreshing a database every night under SI-21 does not help if the database server itself has been compromised and is never rebuilt. Because SI-21 is not assigned to any SP 800-53B baseline, a system will only carry it when the organization or an overlay selects it through tailoring, so the decision and its rationale belong in the tailoring record. Ask your assessor to confirm how they will test each control separately, since their procedures and evidence differ.

Evidence that passes SI-21 and how to keep it current

An assessor testing SI-21 checks whether the defined information, refresh frequencies and deletion actions exist on paper and in the running system. The cards below cover the artifacts that connect those pieces, and how to keep each one accurate between assessments.

Defined list of information and parameters

This is the core artifact. It names each information set subject to refresh or deletion, the organization-defined refresh frequency or on-demand trigger, and the deletion point. SI-21 has two organization-defined parameters, so the list should show a value for each. Record an owner and a review date for every entry, and check that the list matches what the system actually stores. Assessors often start here and compare it against configuration and logs.

System design documentation

Design documents show where refreshed or generated information lives, which components rebuild or purge it, and how those components depend on each other. Confirm that the design describes the refresh path end to end, including caches, replicas and backups that might keep older copies. Update the diagrams whenever a data store or pipeline changes, because a stale diagram hides the copies that matter most.

Configuration settings and job schedules

Screenshots and exports of scheduler definitions, retention settings, lifecycle rules and on-demand generation scripts show the parameters in force. Export them as versioned files from the source of truth so the assessor sees the configured values rather than a description of them. Compare the exported values with the defined parameters each quarter, and treat any drift as a finding you record and fix.

Job logs showing refresh and deletion

Logs prove that refresh and deletion ran as configured, not just that they were configured. Keep job start and end times, record counts, exit status and the identity of the process that ran. Missing runs are as important as successful ones, so alert on skipped or failed jobs and keep the alert history. Confirm that log retention is long enough to cover the assessment period.

Deletion records and verification

Where deletion is the chosen action, the organization needs records that show what was removed, when and by which job, plus a check that the data is gone from primary stores and backups as the design states. Hash manifests, deletion certificates from storage platforms and sampled restore tests all serve this purpose. Ask your storage and backup vendors to confirm which deletion guarantees their products provide before you rely on them.

Change records for refresh logic

Any change to refresh frequencies, deletion rules or the data sets in scope should pass through the change process and leave a ticket, an approval and a diff. Without these records an assessor cannot tell whether a current setting was reviewed or quietly edited. Link each change to the defined list so the list and the running configuration stay aligned between assessments.

What meeting SI-21 costs in money and effort

This table breaks down the cost components of implementing SI-21 Information refresh, marking which are one-time and which recur, and what moves each one up or down. No figures are given because none are supplied for this control, so use it to build the questions for a written, scope-based quote.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Scoping and tailoring decision	Internal security and compliance leads, possibly an implementation partner	One-time, revisited at each reassessment	Whether SI-21 is selected through tailoring or an overlay; a system that does not select it avoids this work entirely
Refresh and deletion design	Platform engineers and data owners, with an implementation partner if contracted	One-time	Number of information types in scope, how many defined refresh frequencies exist, and how many systems hold the information
Build of refresh or on-demand regeneration	Platform engineering, usually the largest one-time item	One-time, with later changes	Use of existing automation such as scheduled jobs or infrastructure-as-code versus custom tooling written for each data store
Open-source tooling licensing	Organization, for hosting and staff time rather than license fees	Recurring hosting and maintenance	Self-hosted open-source components can remove license spend, but hosting, patching and upgrades still need staffing
Evidence upkeep	Operations and compliance staff	Recurring	Frequency of refresh cycles, whether logs of each refresh and deletion are collected automatically, and how often configuration changes
Independent assessor time	Independent assessor, engaged by the organization	Recurring at each assessment cycle	Number of determination statement checks, the examine, interview and test methods chosen, and how well evidence is prepared in advance
Internal review and remediation	Security engineers and system owners	Recurring, plus one-time after a failed finding	Quality of the list of information to be refreshed and the system design documentation the assessor examines

Who owns SI-21 and what an implementation partner can prepare

SI-21 has two organization-defined parameters, so the first decision belongs to your organization: which information is refreshed or regenerated, and how often or under what conditions it is deleted. Those choices are risk decisions. They depend on what the information is, who relies on it, and how long stale or compromised data could be exploited in your environment. Your team also decides whether SI-21 applies at all, since SP 800-53B does not assign it to any baseline and it enters a system only through tailoring or an overlay.

Parameter values: Record the information types in scope and the refresh frequency or on-demand trigger for each, with the reasoning behind it.
Tailoring decision: Document why SI-21 was selected or excluded in the system security and privacy plan.
Accountable owner: Name the person who approves changes to refresh intervals and signs off exceptions.
Risk acceptance: Record any information that cannot be refreshed or deleted on schedule, with the compensating measures and the accepting official.
Evidence custody: Keep the list of refreshed information and the configuration records where the assessor can find them.

Before any partner starts work, confirm that these decisions exist in writing, because a partner can only implement the parameters you have set.

Where organizations fall short on information refresh

SI-21 looks simple on paper, but it has few built-in anchors: no baseline requires it, and its two organization-defined parameters are easy to leave blank. The gaps below tend to appear in the same place, which is the link between the definition of the information, the schedule, the job that runs it and the proof that it happened.

No defined list of information

SI-21 applies to information the organization has named. If no inventory exists of which datasets, caches, reference tables, credentials or lookup files are subject to refresh, an assessor has nothing to test against. The examine method for SI-21 starts with a list of information to be refreshed, so an absent or outdated list fails at the first step. Action: build the list from system design documentation and data flow diagrams, assign an owner to each item, and version it with the system security plan.

Parameters left undefined

SI-21 has two organization-defined parameters: the information to be refreshed and the frequency, or the trigger for on-demand generation and deletion. Teams often write the control statement, then leave the values blank or write 'as needed'. Vague values make the control impossible to test. Action: record a specific frequency or event trigger for each item in the list, and confirm the values match the parameter entries in the system security plan.

Refresh jobs without logs

A scheduled regeneration or cleanup job that runs silently cannot show that it ran, on time or with the expected result. Cron entries, orchestrator schedules and pipeline triggers often write no record of start, finish or failure. The configuration settings and associated documentation are examined for SI-21, so the schedule must be visible and its runs must leave records. Action: confirm each job emits a log entry with timestamp, target, outcome and error, and forward those entries to central monitoring.

Deletion not verified

When SI-21 requires deletion after information is no longer needed, a job that reports success while leaving copies in backups, replicas, temporary storage or logs does not meet the intent. Deletion checks are often missing, so no one knows whether stale records persist. Action: sample deleted items after each run, confirm they are absent from primary storage and replicas, and document how backups age out of the retention window.

SI-21 missing from the tailoring record

SP 800-53B does not assign SI-21 to any baseline, so it reaches a system only through tailoring or an overlay. If the decision to select it, or to decide it is not needed, is not written down, an assessor cannot tell whether the omission was deliberate. Action: add SI-21 to the tailoring worksheet with a rationale, whether selected or not, and link the decision to the system's risk assessment and to the overlay in use, if any.

No owner for refresh decisions

Refresh frequency is a business and risk decision as much as a technical one. Data owners know how long a dataset stays accurate, while platform teams run the jobs. When neither group owns the parameter, values drift and nobody reviews them after a change. Action: name an accountable owner for each item in the list, require them to approve parameter changes, and review the values when the system's architecture or data sources change.

Questions buyers ask about SI-21 information refresh

Is SI-21 information refresh required by default under NIST SP 800-53?

No. SI-21 is not required by default. SP 800-53B does not assign it to the low, moderate, high or 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 the system, and marks it as an assurance-related control. FedRAMP's Rev5 baselines, under the Consolidated Rules for 2026 (rule FRC-CSF-BSL), do not require SI-21 at Class B, C or D. If an agency, contract or authorizing official names SI-21 specifically, treat it as an added requirement and confirm its scope in writing before planning the work.

Why would an organization select SI-21 if no baseline requires it?

Organizations usually select SI-21 through tailoring when they want to limit how long stale or possibly compromised information stays usable. The control requires refreshing defined information at defined frequencies, or generating it on demand and deleting it when no longer needed. Typical candidates are reference datasets, cached credentials or lookup tables, and generated content that other systems trust. The decision belongs to your risk assessment and your authorizing official, not to a default setting.

What cost and effort drive the work to implement SI-21?

The main cost driver is how much information the organization defines as in scope. SP 800-53A assesses SI-21 through one determination statement, but the work behind it depends on the list of information to be refreshed, the refresh frequencies you set, and how many systems produce or consume that information. Costs fall into three groups: internal staff time to define the list and frequencies, engineering time to build refresh or deletion jobs, and assessor time to examine design documents and configuration settings. Ask any provider to split the quote along these lines so you can see what is one-time and what recurs, such as scheduled jobs that must be monitored and updated.

How long does it take to implement SI-21 and what does the team need?

The duration depends on how many information types you define, how many platforms hold them, and whether refresh logic already exists in the applications. No duration has been established for this control in the sources used here, so ask for a timeline tied to a written scope. Your team needs an owner who can define the information and its frequencies, system administrators who can configure refresh schedules and deletion routines, and developers who can change applications that cache or generate data. Plan time for the assessment as well, because an assessor will examine the list, the design documentation and the configuration settings.

Can our own team implement SI-21 without outside help?

Yes, if your team has the skills and capacity. SI-21 does not require specialized tooling, and the core work is documentation, scheduling and deletion configuration on systems you already run. Teams often struggle with three things: deciding which information needs refresh and at what frequency, finding every copy of that information across systems, and proving the result to an assessor. An outside implementation partner can help with those steps, but the organization still owns the control, its risk decisions and its evidence. Only an independent auditor or assessor can issue an assessment result.

What does a fixed-scope partner engagement for SI-21 cover?

A DeployOpen engagement is fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For SI-21, a typical written scope would name the systems covered, the information types in the refresh list, the target refresh and deletion configurations, and the evidence package to prepare, such as design documentation and configuration records. DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue assessment reports or attestations. Ongoing monitoring of scheduled jobs can be handled through a retainer if you want continued support. Request a quote based on the written scope rather than expecting a standard price.

What evidence will an assessor expect for SI-21?

An assessor following SP 800-53A examines three kinds of objects for SI-21: the list of information to be refreshed, the system design documentation, and the system configuration settings with their associated documentation. Prepare a current list with owners and defined frequencies, design notes that show where refresh or on-demand generation and deletion happen, and configuration exports or job definitions that match those frequencies. Keep records that show the jobs ran, because a configuration without operating history gives the assessor little to test. Confirm the exact evidence expectations with your assessor before you finalize the package.

Where can we read the SI-21 control text and assessment procedure?

Start with the SP 800-53 Rev. 5 publication, which describes the control and its Appendix C status, and then read the SP 800-53B publication for baseline assignments and tailoring guidance. The SP 800-53A assessment procedure for SI-21 is in the OSCAL catalog published in the usnistgov/oscal-content repository, which also includes the baseline profiles. Use the official NIST sources for the exact wording, since this page only explains the control in plain terms and does not reproduce standard text.

How DeployOpen prepares SI-21 evidence in your environment

DeployOpen's part in SI-21 work is preparation, not assurance. We start with a written scope that names the systems, the information sets to be refreshed or deleted, and the refresh frequencies your organization has defined for the two organization-defined parameters in SI-21. Once the scope is agreed, we configure the self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks so that the refresh jobs, deletion routines and their configuration settings can be shown to an assessor. We do not decide the parameter values for you. Those are risk decisions that belong to your system owners and authorizing official, and we will ask you to record them in writing before we build anything around them.

The evidence we prepare follows the examine objects in SP 800-53A for this control: the list of information to be refreshed, the system design documentation that explains how refresh and deletion fit the architecture, and the system configuration settings with their associated documentation. We assemble these as a package with change history, so an assessor can trace each setting back to the decision that set it. We also test that scheduled jobs run, that on-demand regeneration produces the expected output and that deletion removes what it should. Those results are recorded as operational evidence. The independent assessor decides whether the evidence satisfies the control, and only that assessor issues a report. Support after handover is available as a retainer, covering configuration drift, upgrades to the platforms and periodic re-testing of refresh jobs as your scope changes. Your organization still owns the control. Confirm with your assessor, before scoping starts, which SP 800-53A determination statement and evidence format they will accept, and ask us for a fixed-scope written proposal that lists these deliverables and their timelines.

SI-21 Information refresh