SI-12(3): Information Disposal

SI-12(3) sits at the intersection of records retention, security operations, and data lifecycle governance. The control is simple on paper: after the retention period, information must be disposed of using defined techniques. In practice, organizations fail it for two reasons: (1) retention and disposal live in different teams and systems, and (2) “disposal” is interpreted as a single action, even though modern environments have duplicates across SaaS apps, collaboration tools, logs, data lakes, endpoint caches, backups, and third-party systems.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SI-12(3) as a requirement to (a) specify disposal techniques, (b) implement them across the real storage locations where the data exists, and (c) retain evidence that the techniques ran, were effective, and were governed. Done well, SI-12(3) reduces breach impact (less data to lose), narrows discovery and litigation exposure (less data to produce), and lowers operational cost (less storage sprawl). Done poorly, it becomes an audit finding because you cannot prove deletion, or because you only deleted “primary” data while backups and exports continued to retain it.

Regulatory text

Requirement (excerpt): “Use the following techniques to dispose of, destroy, or erase information following the retention period: {{ insert: param, si-12.3_prm_1 }}.” ¹

Operator meaning: You must (1) define the disposal techniques your program allows, (2) apply them when retention ends, and (3) be able to demonstrate that disposal occurred for the relevant information and media. The “techniques” placeholder is an organization-defined parameter in your control implementation; auditors will expect to see a concrete list, not “we delete stuff.” ²

Plain-English interpretation

SI-12(3): information disposal requirement expects a governed end-of-life process for information. Once information reaches the end of its approved retention period, you dispose of it using an approved method appropriate to the medium and risk (for example: cryptographic erasure for encrypted cloud storage, secure wipe for endpoints, shredding for paper, vendor-certified destruction for drives). Your disposal method must be repeatable and backed by evidence.

A practical test: if you had to show an assessor “what happens to employee PII after it ages out,” you should be able to point to the retention rule, the disposal workflow, the systems it touches, and the logs or certificates showing completion and exceptions.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data, where NIST SP 800-53 Rev. 5 is the controlling baseline or is flowed down via contract. ²

Operational scope (what systems and teams)

• Data owners / business owners who approve retention and disposal requirements for a dataset.
• Records management / legal who define retention schedules and holds.
• Security / IT operations who implement deletion, wiping, sanitization, and asset disposition.
• Cloud / platform teams who configure lifecycle policies, key management, and storage controls.
• Third parties that store or process your information (SaaS, managed service providers, shredding vendors, e-waste handlers).

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

Use this sequence to implement SI-12(3) in a way an assessor can follow end-to-end.

1) Declare your “approved disposal techniques” (the missing parameter)

Create a short, explicit list of techniques your organization uses, mapped to media types. Keep it in a standard (policy or control standard) and reference it from procedures.

Minimum structure to document

• Technique name (for example: secure wipe, cryptographic erasure, physical destruction)
• Where used (endpoints, cloud object storage, databases, backups, paper)
• Tool/process owner
• Verification method (logs, sampling, certificates, automated attestations)
• When not possible (constraints) and the approved exception path

This is what fills the organization-defined “techniques” element in the control statement. ¹

2) Map retention triggers to real storage locations

Auditors will ask, “How do you know you disposed of it everywhere it lived?” Build a simple data-location map for in-scope information types.

For each information type (e.g., HR files, customer tickets, security logs), identify:

• System of record
• Downstream copies (BI exports, data warehouse, email attachments, collaboration links)
• Backups/snapshots
• Third-party processors and sub-processors
• End-user endpoints (downloads, synced folders)

If you already run a data inventory or records schedule, attach disposal locations to each inventory entry rather than creating a new spreadsheet.

3) Implement disposal workflows by environment (automation first)

Pick the disposal method that matches the medium, then implement it as an operational workflow with an owner and a run cadence.

Common implementation patterns

• SaaS apps: configure retention and deletion features; add admin-run deletion for edge cases; require third parties to support deletion and provide evidence on request.
• Cloud storage: use lifecycle policies to delete or transition data; use cryptographic erasure where encryption is enforced and keys can be destroyed under change control.
• Endpoints: integrate secure wipe into offboarding and device re-provisioning; ensure removable media has a defined handling and disposal path.
• Backups: align backup retention to records retention; define what “deletion” means if immutable backups exist; document compensating controls (for example: expired data becomes inaccessible and is purged on backup rotation).

4) Add governance gates: legal holds and exceptions

SI-12(3) is “following the retention period,” but you must also handle cases where disposal is paused.

Implement:

• Legal hold process that can suspend disposal for specific custodians/datasets.
• Exception process with expiration, approval, and documented rationale (for example: regulatory retention conflict, investigation hold, technical limitation).

5) Prove execution with recurring evidence

Design evidence as a recurring output of operations. Avoid “one-time” screenshots.

Examples of strong evidence:

• System logs showing deletion jobs ran and completed
• Key destruction records (change tickets + KMS logs where available)
• Media destruction certificates from approved disposal providers
• Ticketing records for device disposition and wipe verification
• Periodic reports that show retention rules in key systems and their last run status

6) Test effectiveness (spot checks that catch the real failures)

Run a lightweight validation protocol:

• Pick a sample of records that should have been disposed.
• Confirm absence in the system of record.
• Confirm absence (or inaccessibility) in known replicas (exports, collaboration, search indexes).
• Confirm disposal evidence exists for the relevant workflow run.

Document findings and remediation. This is often the difference between “policy exists” and “control operates.”

Required evidence and artifacts to retain

Keep artifacts in a single audit package with clear ownership.

Artifact	What it should show	Typical owner
Disposal standard (approved techniques list)	The defined techniques that satisfy SI-12(3)	GRC + Security
Records retention schedule / retention rules	Retention periods and triggers by data type/system	Records Mgmt / Legal
Disposal procedure(s)	Steps, tools, roles, verification	IT Ops / Security Ops
System configurations	Lifecycle/retention settings in SaaS/cloud systems	Platform / App owners
Execution evidence	Logs, job reports, tickets, certificates	Ops teams
Exceptions & legal holds	Approvals, scope, dates, expiration	Legal / Compliance
Third-party contract clauses	Deletion/disposal obligations + evidence rights	Procurement / Legal

Common exam/audit questions and hangups

Expect these and prepare short, evidence-backed answers:

1. “What are your disposal techniques?” Provide the approved list and show it is used in procedures. ¹
2. “How do you know retention is reached?” Show retention rules, triggers, and responsible owners.
3. “Do you delete from backups?” Explain backup retention alignment and how expired data is purged or becomes inaccessible over time; show documentation and evidence.
4. “How do third parties dispose of your data?” Show contract language, deletion requests (if applicable), and attestations/certificates when available.
5. “What happens under legal hold?” Show hold workflow and how it suspends disposal with approvals.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating disposal as “delete in the app” only. Fix: maintain a storage-location map and include exports, logs, endpoints, and third parties in scope.
• Mistake: No defined techniques, only a generic policy statement. Fix: publish a short disposal techniques standard that teams can follow and auditors can test against. ¹
• Mistake: Backups are ignored or hand-waved. Fix: document how backup retention works, what is immutable, and what compensating controls exist; align backup retention to retention requirements where feasible.
• Mistake: Evidence is “screenshots from last year.” Fix: set recurring evidence collection (monthly/quarterly) from logs and tickets, stored in a controlled repository.
• Mistake: Third-party disposal is assumed. Fix: require disposal terms and evidence rights in third-party contracts; track disposal requests for offboarded systems.

Risk implications (why assessors care)

Failure modes map to real risk:

• Data minimization failure: retaining data past retention increases impact if compromised.
• Discovery exposure: stale data increases what you may need to collect and produce in investigations or litigation.
• Third-party risk: if a third party retains your data after contract end, you may still bear reputational and contractual impact.

NIST frames SI-12(3) as a defined-method, retention-linked disposal requirement; auditors usually treat “can you prove disposal happened” as the pass/fail line. ²

Practical execution plan (30/60/90-day)

Use these phases as a realistic operating plan. Adjust scope to your highest-risk systems first (PII, authentication data, security logs, regulated records).

First 30 days (foundation)

• Assign a control owner and a technical owner for disposal execution.
• Publish the approved disposal techniques list (the SI-12(3) parameter) and route it through your normal policy/control approval flow. ¹
• Identify in-scope information types and top systems where retention expiration occurs.
• Define the minimum evidence set you will collect per system (logs, tickets, certificates).

Days 31–60 (implementation)

• Configure retention/deletion settings in priority systems (system of record first).
• Implement endpoint and media disposal procedure for IT asset disposition and offboarding.
• Add legal hold and exception workflows if they are informal today.
• Update third-party contract templates or add addenda for disposal obligations and evidence rights.

Days 61–90 (operate + validate)

• Run at least one full disposal cycle in each priority system and collect evidence.
• Perform spot checks across replicas (exports, shared drives, data warehouse feeds).
• Record issues as corrective actions with owners and due dates.
• Package artifacts for assessment: standard, procedures, configs, and execution evidence.

Ongoing (keep it passing)

• Review disposal techniques annually or after major platform changes.
• Monitor deletion job failures and exception volume.
• Re-test samples periodically and after system migrations.

Tooling note (where Daydream fits)

Most SI-12(3) programs fail on coordination and evidence, not intent. Daydream helps by mapping SI-12(3) to a named control owner, a concrete implementation procedure, and a recurring evidence checklist so you can show consistent operation during assessments. ¹

Frequently Asked Questions

Do we need to physically destroy media to satisfy SI-12(3)?

SI-12(3) requires that you use defined techniques appropriate to the medium after retention ends. Physical destruction can be one technique, but you can also define secure erase or cryptographic erasure where appropriate, as long as you document the technique and can prove execution. ¹

How should we handle immutable or write-once backups?

Document how backup retention aligns to retention requirements and what “disposal” means in that context (for example: purge at rotation, key destruction for encrypted backups, or documented inaccessibility until expiration). Keep evidence of backup retention settings and the purge/rotation process.

What evidence is strongest for auditors?

Automated logs or reports showing deletion jobs executed and completed are the most defensible, followed by ticketing records and certificates of destruction for physical media. Pair evidence with the disposal techniques standard so the assessor can trace “method” to “execution.” ¹

Does SI-12(3) apply to data in third-party SaaS tools?

Yes if those systems store or process your in-scope information. Treat third parties as storage locations, require disposal obligations contractually, and retain deletion attestations or administrative evidence when accounts/workspaces are decommissioned.

How do legal holds interact with disposal requirements?

Legal holds are a controlled pause in disposal. Your process should show how holds are issued, how they suspend disposal actions, and how disposal resumes when the hold is released, with approvals and records retained.

What’s the fastest way to operationalize SI-12(3) if we’re starting from scratch?

Start by defining your disposal techniques list and mapping it to your top systems that have retention timers (email, ticketing, file storage, HR/CRM). Then automate deletion in those systems and set up recurring evidence capture so you can prove the control operates. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5