Information Management and Retention SI-12

System and Information Integrity · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SI-12 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Information Integrity family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SI-12 (Information Management and Retention) is about handling the information a system holds and produces on purpose — keeping it as long as the rules require, and no longer. ‘The rules’ means applicable laws, regulations, and your own policies. It covers data stored in the system and the output the system generates, such as logs, backups, and reports. This is a foundational System and Information Integrity control that appears in the Low baseline.

What good looks like

Know what information the system holds and produces — stored data, logs, backups, and reports.
Set a retention period for each type, driven by law, regulation, and policy — not by habit.
Keep information only as long as it is needed, then dispose of it in a defined, repeatable way.
Write the decision down so retention is documented, not something each admin guesses at.
Apply the schedule to logs and backups too — these grow quietly and often outlive their purpose.

Framework mapping

NIST CSF 2.0 — ID.AM-08 — Systems, hardware, software, services, and data are managed throughout their life cycles
CIS Controls v8 — Control 3 — Data Protection

How to move it toward Implemented

Write a one-page retention schedule: list each information type (application data, logs, backups, reports), its retention period, the legal or policy basis, and how it is disposed of.
Make the log side tangible — configure logrotate (in /etc/logrotate.conf or /etc/logrotate.d/) with a rotate count and maxage that match the schedule, so logs are kept and then removed automatically.
Set a matching retention for backups, and record where old copies go and when they are deleted.
Have the owner of the data review and date the schedule so it reflects real requirements.
Attach the retention schedule and the logrotate config as hardening evidence on the asset, naming SI-12 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.