SI-12 Information management and retention: evidence

SI-12 information management and retention: what the requirement asks

When an assessor or a contract asks how information is kept and disposed of, the question behind it is whether the organization decides, in writing, how long each kind of information stays in its systems and what happens to it afterward. SI-12 requires the organization to manage and retain information within the system and the output it produces in line with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements. It sits in the System and Information Integrity family of SP 800-53 Rev. 5 as a base control, so it is not an enhancement of some other control. In SP 800-53B, it is assigned to the low, moderate and high security control baselines and to the privacy baseline, which means it applies whatever the system's impact level. The control is written so that the organization sets its own rules. NIST does not supply a retention period for any data type, and the organization owns its retention schedule and the justification behind it.

Retention and disposal are often weak for predictable reasons. Logs, backups, exports, test copies and application output tend to be kept by default because nobody was assigned to decide otherwise, and the systems that hold them were never linked to the schedule. An assessor will look for the schedule itself, evidence that it reflects the legal and operational drivers the organization says apply, and proof that the schedule is applied to the systems that actually store the data. The assessment procedure for SI-12 in SP 800-53A Rev. 5 points to examining audit findings, personally identifiable information inventories, and privacy impact and privacy risk assessment documentation, so those records are the first place to check whether retention decisions were made for the personal data the system holds. Confirm the current assessment objects against the SP 800-53A Rev. 5 publication before you build your evidence list.

Start by asking the system owner for three things: the retention schedule for each information type in scope, the legal or contractual source for each period, and the disposal method used when a period ends. Then confirm who approves changes to the schedule and how often it is reviewed. Retention is also a cost question. Storage, backup copies and the effort of proving deletion all grow with the periods chosen, so a longer period should be justified by a named requirement, not by habit. Any quote for work on this control should separate the time spent drafting the schedule, which is organizational work, from the time spent configuring systems to enforce it, which is where an implementation partner usually helps.

Which systems, data and third parties SI-12 reaches

SI-12 applies wherever information is kept, copied or output by the system, so scoping starts with an inventory of those copies rather than the primary application alone. The cards below cover the places where retention rules most often diverge, and they explain how the baseline choice changes how far the work extends.

Data stores holding personal information

Start with every database, object store, file share and search index that holds personal information, and record the retention rule each one must follow. SI-12 asks that information be kept and disposed of in line with applicable law and operational need, and the privacy baseline adds enhancements that limit which PII elements are kept at all. Check whether each store has a documented owner, a purpose, and a disposal method that an assessor can observe.

Backup and archive repositories

Backups often outlive the data they protect, so a deletion in production may leave personal information in weeks or years of snapshots. Confirm the retention period for each backup set, how expired sets are purged, and whether restores can reintroduce data that was meant to be removed. Backup tooling such as Bareos keeps a catalog of backed-up files, which can help identify where a given record was stored.

Logs and audit records with their own rules

Application, access and audit logs frequently contain personal identifiers, and they often follow retention rules set by a different team. Map which logs carry personal information, who owns their retention, and how they are rotated and deleted. Audit logs may need to be kept longer than the data they describe, so the retention decision should be written down rather than left to default log rotation settings.

Test and non-production copies

Developers and testers frequently receive production extracts that were never meant to leave the production boundary. The privacy baseline's minimization enhancements expect those copies to be reduced or de-identified before use. Confirm who approves copies, how long they persist, and whether masking or synthetic data is used. Each copy should appear in the inventory with an owner and a deletion date.

Third-party processors holding copies

Cloud services, SaaS tools, support vendors and managed backup providers may hold copies of personal information without the organization's direct visibility. Contracts and processor records should state how long each party keeps data and how disposal is confirmed at the end of service. Ask each processor for its deletion procedure and the evidence it provides, since the organization remains responsible for the outcome.

Baseline choice and the privacy baseline

The low, moderate and high baselines assign SI-12 with its base requirement, while the privacy baseline also selects SI-12(1), (2) and (3). Moving from a standard baseline to the privacy baseline widens the work from keeping information under legal rules to limiting PII elements and minimizing them in testing. Confirm which baseline applies to each system before scoping, because it determines which of these cards need full evidence.

How an assessor tests SI-12 against its four determination statements

This table compares the three SP 800-53A assessment methods for SI-12 and the objects an assessor samples under each one. Read it as a checklist of what to prepare before an assessment, since each row shows what the assessor will ask to see and where retention programs usually fall short.

Assessment element	What the assessor does	Evidence to have ready	Where it usually fails
Examine: audit findings	Reviews audit findings to see whether information retention and disposal activity matches the stated requirements	Audit records of deletion, archive and retention jobs; exception logs	Audit logs for disposal jobs are missing or not reviewed
Examine: PII inventory	Compares the inventory of personally identifiable information with where data actually resides and how long it is kept	Current PII inventory mapped to systems, retention periods and owners	Inventory is out of date or omits backups, logs and test copies
Examine: privacy impact assessment	Checks whether retention and disposal decisions were analyzed for privacy risk	PIA documentation covering retention periods and disposal methods	PIA exists but does not address retention or disposal
Examine: privacy risk assessment	Checks that identified retention risks have been evaluated and tracked	Privacy risk assessment records with retention risks and treatment decisions	Risks are recorded but no treatment or owner is assigned
Interview: system owners and records staff	Asks how retention rules are applied, who approves disposal and how legal holds are handled	Named roles, procedures and approval records for disposal	Staff describe a rule that differs from the written schedule
Test: deletion and retention in the system	Samples records and confirms that data past its retention period is removed or archived as specified	Sample reports from the system showing records by age and disposal status	Retention schedules exist on paper but are not enforced in the system
Test: backup and restore behavior	Confirms that retained backups follow the same schedule and that expired data is not restored unintentionally	Backup retention settings, expiry reports and restore test records	Backups hold data far beyond the stated retention period

Implementing SI-12 information management and retention in six steps

This sequence turns SI-12 from a policy statement into a working set of retention rules, enforced settings, disposal records and periodic reviews that an assessor can test against the examine, interview and test methods in SP 800-53A.

Inventory information types and their owners
Start by listing every category of information the system creates, stores, processes or outputs, including logs, backups, exports, test data and personal data. For each category, name an accountable business owner and the system components where the data lives. The output is an information inventory that identifies owners and locations, and the check that closes this step is a sign-off from each owner confirming the entries. Assessors look for this inventory first, because the SA-based examine objects for SI-12 include the personally identifiable information inventory and privacy risk documentation.
Set retention and disposal rules with legal input
Work with legal, privacy and business owners to define how long each information type must be kept and how it is disposed of at the end of that period. Record the legal, regulatory, contractual or operational basis for each rule, and identify where the rules conflict. The output is a retention schedule approved by named owners, and the step closes when every inventory entry has a retention period, a disposal method and a stated basis. Confirm the applicable laws, executive orders, directives and contractual terms with counsel, because SI-12 requires retention in line with them.
Configure systems and backups to enforce the rules
Translate the retention schedule into configuration. Set log retention, application data lifecycles and backup retention in each platform, and confirm that backup jobs expire or prune data as the schedule requires. Where backups hold information with a shorter retention period than the primary data, document how that difference is handled. Open-source tools such as Bareos, which keeps a SQL catalog of backed-up files and runs backup, restore, verify and archive jobs, and restic, whose check command can read pack files back to confirm stored data is unmodified, can produce evidence of both retention and integrity. The output is a configuration baseline mapped to each retention rule, and the step closes when a test restore and a test expiry run both behave as documented.
Build the disposal and legal hold procedure
Write the procedure that governs how information is disposed of and how disposal stops when a legal hold or investigation applies. The procedure should name who approves disposal, how disposal is performed for each storage type, how deletion from backups is handled, and how holds are recorded and released. Include a rule for test and non-production data copies so that disposal reaches them too. The output is an approved procedure with defined roles, and the step closes when a tabletop walkthrough shows that a hold blocks disposal of the affected records and that the disposal record captures the item, the date, the approver and the method.
Collect evidence on a defined schedule
Decide which evidence will be collected, how often, and who collects it. Typical items include retention configuration exports, backup job and expiry reports, disposal logs, hold registers, and records showing that personal data in test environments was removed or masked. Audit records from applications such as Nextcloud's admin_audit app, which writes event information to audit.log, or OpenBao's audit devices, which keep a JSON log of API requests and responses with sensitive values hashed, can support the disposal trail. The output is an evidence calendar with a named collector for each item, and the step closes when the first full collection is filed in the system's evidence repository with a date and the name of the person who ran it.
Review the rules and the evidence periodically
Set a review cycle for the retention schedule, the disposal procedure and the configuration baseline, and run it with the same owners named in the inventory. Review changes in law, contracts, business processes and system architecture, and update the schedule and configurations to match. Record each review, the decisions taken and any changes made. The output is a dated review record with approved revisions, and the step closes when the updated schedule is published and the configurations and evidence reflect it. Ask your assessor how often they expect reviews to occur for the systems in scope, because the appropriate frequency depends on the organization's own policy and the authorization or audit framework it operates under.

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

SI-12 is tested by looking for proof that information is kept and disposed of according to documented rules, not by reading a policy alone. The artifacts below connect the retention schedule to what the system actually does, and each needs a named owner and a refresh trigger between assessments. Your assessor will sample across them, so they must agree with one another.

Approved retention schedule

This is the reference point for every other artifact. It lists each information type, the legal, regulatory or operational reason for keeping it, the retention period, the disposal method and the business owner who approved it. Check that every category in the information inventory maps to a schedule entry and that legal counsel has reviewed categories with statutory periods. Refresh it when laws, contracts or business lines change, and have the records owner and legal sign off on each revision with a version number.

Information inventory with owners

An inventory lists the systems, data stores, backups and outputs that hold information, the data types in each, and the retention category assigned to it. Assessors use it to test whether the schedule covers everything the system holds. Refresh it when systems are added, decommissioned or integrated, and record who verified each entry. A common gap is backup copies and log stores that appear nowhere in the inventory.

Retention and purge configuration

Screenshots, exported configuration files and change history showing that retention periods and purge jobs are set in the systems themselves. For example, a log retention setting, a database purge job or an object storage lifecycle rule should match the schedule exactly. Keep a dated export from each system, compare it to the schedule at each review, and have the system owner confirm that changes went through change control.

Backup catalog and restore test records

Backup catalogs show what was retained, where, and for how long, and restore tests show the copies are usable. Open-source tools such as Bareos keep a SQL catalog of backed-up files, and restic can verify repository data with its check command. Record dated restore tests and integrity checks, and confirm that backup expiry matches the schedule so that data is not kept past its period in backup media. The backup administrator should sign off on test results each quarter.

Disposal logs with approvals

Disposal logs record what was destroyed, when, by which method, and who approved it. They provide the strongest proof that the schedule is enforced rather than aspirational. Each entry should reference the schedule category, the approving records owner and, where relevant, a certificate of destruction from a vendor. Confirm that legal holds were checked before disposal. Review logs at each assessment cycle and reconcile them against audit records of deletion events.

Legal hold and privacy assessment records

Legal hold notices show which information is exempt from disposal and when that exemption ends, and privacy impact assessments and privacy risk assessments document why personal information is retained and how its volume is limited. Assessors examine these for the PII inventory and PIA documentation named in SP 800-53A. Have legal and the privacy office confirm each hold and assessment at its review date, and update the PIA whenever a new PII element or test data source is introduced.

Limiting PII elements and keeping personal data out of testing

The privacy baseline in SP 800-53B selects SI-12(1), SI-12(2) and SI-12(3), so an organization that processes personally identifiable information (PII) must show that it limits the PII elements its systems keep and minimizes personal data wherever it is used outside production, including in testing, training and research. The enhancements do not define what minimal means for your organization. That decision belongs to the system owner and privacy office, who should document it in the PII inventory and the privacy risk assessment. Before you write any requirement around these enhancements, confirm their exact wording in the SP 800-53 Rev. 5.2.0 OSCAL catalog, because the enhancements' titles and parameters are the basis for how an assessor will test them.

In practice, most of the work sits in non-production environments. The usual approaches are synthetic test data generated to match the shape of production records, masked or tokenized copies of real records where a tester truly needs realistic values, and non-production refreshes built from a minimized dataset rather than a full production extract. For example, an illustrative customer database might be refreshed each cycle from a copy with only the fields that the test cases use, with names and identifiers replaced by consistent pseudonyms. Equally important is tracking where PII copies exist. Backups, developer laptops, ticketing attachments, log exports and CI pipelines can each hold a copy that is missing from the inventory, so the inventory must cover them, and each copy needs a defined disposal path under SI-12's retention requirements.

Assessors test this area by examining the PII inventory, privacy impact assessment and privacy risk assessment documentation, and by interviewing the people who build and refresh test environments. Ask your team to produce a current list of non-production datasets, the source and minimization step for each, the masking method and the date of the last refresh. An implementation partner can build the masking and refresh pipelines and the evidence that they ran, but the organization still owns the minimization decisions and the risk acceptance. Independent assessors, not the partner, decide whether the evidence is sufficient.

Self-hosted open-source tools that produce retention and disposal evidence

Several self-hosted open-source tools generate records that an assessor can examine when testing how information is kept, verified and disposed of under SI-12. Each one covers a different slice of the retention picture: backup catalogs, backup integrity, application audit trails and secrets platform request logs. None of them decides how long information must be kept, so the retention rule itself must come from the organization's legal and operational requirements.

Bareos backup scheduling and restore

Bareos is a backup system whose Director schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of backed-up files, so you can show which copies exist, where they are stored and which ones can be restored from a given date and time. For SI-12, the catalog and job history become evidence of how long backups are retained and when older copies are pruned. Confirm that Bareos pool and retention settings match your own retention rule, and check that expiry and pruning are recorded. Bareos is licensed under AGPL-3.0-only, so review the obligations with your legal team before distributing modified versions.

restic integrity checks on backups

restic is a backup tool whose check command verifies the structural consistency of snapshots, trees and pack files. With the read-data or read-data-subset options, it reads pack files back to confirm that stored backup data has not been modified. For SI-12, this produces dated records that retained backups are still complete and unaltered, which supports the claim that retained information remains usable. Schedule full-read checks at an interval your recovery objectives justify, and confirm that check output is retained alongside the backups it covers. restic is licensed under BSD-2-Clause, which permits broad reuse with attribution.

Nextcloud admin_audit event log

The Nextcloud admin_audit app records additional event information in an audit.log file in the data directory, or in a path set with logfile_audit. For SI-12, this log shows administrative actions such as changes to sharing, user or file handling that affect how long information is kept or who can remove it. Keep the log outside the web root, set its location deliberately, and confirm that your retention schedule for the log itself is written down. Check the event types the app captures against the disposal actions you need to evidence, because the log only shows what is configured to be logged. Nextcloud is licensed under AGPL-3.0-only.

OpenBao audit device request logs

OpenBao audit devices write a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log can show that a secret was read, changed or deleted without exposing the secret. For SI-12, this supplies a tamper-evident trail of when retained secrets, keys or credentials were created, accessed and removed, which helps assessors test disposal of sensitive information. Decide where audit logs are shipped, who can read them, and how long they are kept, and confirm that the audit device cannot be silently disabled by ordinary operators. OpenBao is licensed under MPL-2.0.

What meeting SI-12 costs in money and effort

This table breaks the cost of meeting SI-12 into its components, showing who is paid for each, whether it is one-time or recurring, what moves it up or down, and what to request in a written quote. No prices or durations are stated because none are supplied for this control, so use the table to structure your own estimate and your questions to providers. The main takeaway is that most of the recurring cost comes from keeping the schedule current and producing evidence, not from the software itself.

Cost component	One-time or recurring	What drives it up or down	What to request in a written quote
Retention schedule and legal review	One-time, then recurring on review	Number of information types, count of applicable laws and contracts, and how often legal requirements change	Named deliverables, the list of information types covered, and who signs off on legal interpretation
Engineering time to configure retention and disposal	One-time build, recurring changes	Number of systems holding information, how many retention rules apply per system, and whether disposal is automated	Systems in scope, retention rules to be implemented, and whether disposal jobs are scripted or manual
Backup and storage infrastructure	Recurring	Retention periods, volume of data, number of restore points kept, and off-site copies required by the schedule	Storage sizing assumptions, retention periods per dataset, and the cost basis (own hardware, cloud account or data center)
Tooling and licenses	Recurring where commercial	Choice of backup, logging and audit products; self-hosted open-source options such as Bareos, restic, Nextcloud admin_audit and OpenBao audit devices avoid per-seat license spend but still need operation	Full list of licensed components, license terms, and any support contracts needed to run the tools in your environment
Evidence upkeep	Recurring	How often disposal and retention runs are logged, how many systems produce records, and how quickly evidence is collected for review	Evidence list mapped to SI-12 determination statements, collection frequency, and storage location for records
External review of the schedule	Periodic, typically one-time per revision	Breadth of the schedule, number of legal regimes covered, and whether a privacy or legal specialist must review it	Reviewer credentials, scope of review, and whether the output is advisory or a formal sign-off
Auditor sampling	Recurring at each assessment	Number of systems and datasets sampled, the depth of examine and test methods used, and the quality of existing records	Sampling approach, assessment objects expected, and what the assessor will need from you before fieldwork begins

Who owns SI-12, who can prepare it and what only the auditor issues

Your organization owns SI-12. That means deciding what information the system holds and produces, how long each category must be kept, what legal, contractual and operational obligations set those periods, and when information must be disposed of. These are business and legal decisions, and no implementation partner or assessor should make them for you. The control text asks that information be managed and retained in line with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements, so the sources of those requirements must be named by your own compliance, legal and records owners.

Retention schedule: Records each information category, its owner, its legal or contractual basis and its retention period.
Disposal decisions: Approves when and how information is deleted, anonymized or archived, including holds that suspend disposal.
PII handling rules: Decides which personal data elements may be retained, minimized or removed from testing copies.
Policy and procedure: Keeps the SI-1 policy and the retention procedure current, approved and reviewed.
Exceptions and sign-off: Records approved deviations and the people accountable for them.

Before any engagement starts, confirm that these decisions have a named owner and a written approval trail.

Questions buyers ask about SI-12 cost, effort and outside help

What does SI-12 cost to implement and what drives the price?

No public figure exists for SI-12 specifically, and NIST does not estimate compliance or certification costs. The cost is the sum of work that is paid for separately: defining the retention schedule with legal and records staff, configuring backup, archive and deletion jobs, producing evidence, and having an independent assessor test the result. The main cost drivers are the number of information types and systems in scope, how many systems hold personal data, whether retention rules already exist, and whether SI-12 is assessed alone or with its three enhancements. Ask any partner for a fixed-scope quote that lists each system, each deliverable and each evidence artifact, and separate one-time setup from recurring operation such as restore testing and retention reviews.

How long does SI-12 preparation take?

NIST does not set implementation timelines for SP 800-53 controls, and it leaves that to OMB Circular A-130 for federal systems. Duration depends on how many systems and data stores need retention rules, whether the organization has a documented records schedule, how much deletion logic must be built or verified, and how long approvals take from legal and data owners. Organizations with clear, approved retention rules usually move faster than those that must first decide what the rules are. Ask for a timeline tied to the written scope, with milestones for approvals, configuration, evidence collection and the assessor's test window.

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

Yes, if your team has the skills and time to do the work, and nothing in SP 800-53 requires an outside firm to implement a control. Internal teams usually own the policy, the retention schedule and the business decisions. Outside help is most useful for configuring backup catalogs, audit trails and deletion jobs, building repeatable evidence, and preparing test material that an independent assessor can examine. Only an independent assessor or certification body can issue a report or certificate, so an implementation partner never replaces that step. Compare the internal effort against the scope of the systems and the assessment deadline before deciding.

What does SI-12 need from our legal, data and IT teams?

SI-12 depends on decisions that only your organization can make, so the work cannot start until those people are involved. Legal and records staff must confirm which laws, regulations and contractual obligations set minimum retention periods and which require deletion. Data owners must state what each information type is for, how long it is needed and who may access it. IT and platform teams must provide access to backup systems, logs, storage and the systems that hold personal information, along with change approval for configuration. Ask your partner to list these inputs in the written scope, with a named owner and a due date for each.

Can SI-12 be tested separately from its enhancements?

Yes. SP 800-53A assesses SI-12 through its own determination statements, so an assessor can examine the base control without the enhancements. The base control concerns managing and retaining information in line with legal and operational requirements. The three enhancements, SI-12(1), (2) and (3), add specific measures such as limiting personally identifiable information elements, minimizing it in testing and related requirements. Your baseline decides which apply: SP 800-53B selects the privacy baseline enhancements (1), (2) and (3) for SI-12. Confirm the exact scope with your assessor before you start, because the evidence for each enhancement differs.

How do we choose an implementation partner for SI-12?

Start with a written scope that names systems, controls, deliverables and dates, and ask every candidate to commit to it before work begins. Check that the partner works inside your own infrastructure and can explain how each retention and deletion job is configured, logged and tested. Ask how they hand over evidence, documentation and runbooks, and whether they support ongoing restore testing or retention reviews after the initial work. Confirm they will not issue audit reports or certificates, and that your independent assessor is engaged separately. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside client environments, prepares evidence for assessments, and quotes from a written scope rather than a price list.

How DeployOpen scopes and prepares SI-12 evidence

DeployOpen plans, implements and documents the retention, disposal and PII-minimization measures behind SI-12 inside your own infrastructure, then hands over the evidence an independent assessor will examine. DeployOpen prepares systems and records but does not issue audit reports or certifications; those come from independent assessors and certification bodies.

How we scope

We agree a written scope listing the systems, data stores, backups and test environments in which SI-12 retention rules apply.
We confirm with you which legal, regulatory and operational retention requirements the organization must meet, and who owns each one.
We identify where personally identifiable information appears, including test and staging copies, before any work starts.

How we build

We configure self-hosted backup and retention tooling such as Bareos or restic so retention periods match the documented schedule.
We set audit logging and retention for platforms such as Nextcloud and OpenBao so records of disposal and access are kept.
We build PII minimization steps for test data, including masking or removing identifiers before data leaves production.

How we hand over

We deliver configuration records, retention schedules, disposal logs and restore verification results mapped to the SI-12 determination statements.
We document the procedures your staff run for retention, disposal and test data handling, with named owners and review dates.
We provide a walkthrough so your team and your assessor can trace each piece of evidence back to the system that produced it.

How we support

Ongoing support, upgrades and periodic testing of retention and backup configurations are available as a retainer.
Retainers can cover changes to retention rules when laws, contracts or operational requirements change.
Any change to scope after work starts is agreed in writing before it is carried out.

SI-12 Information management and retention