SR-12: Component Disposal

To meet the sr-12: component disposal requirement, you must ensure system components are disposed of using defined, approved techniques so the organization’s data and configuration details cannot be recovered from retired, replaced, or failed parts. Operationalize SR-12 by scoping in-scope components, selecting sanitization/destruction methods per media type, controlling chain of custody, and retaining auditable disposal evidence. ¹

Key takeaways:

• SR-12 is a process control: define disposal methods, then prove you followed them for every in-scope component. ¹
• Your biggest audit risk is missing evidence (tickets, certificates, chain-of-custody logs), not the lack of a policy statement. ¹
• Disposal must cover hardware and media-bearing parts across ITAD, RMA/repairs, cloud/colocation, and third parties handling your components. ²

SR-12 sits in the Supply Chain Risk Management family and focuses on what happens when components leave your control: decommissioned endpoints, failed drives, network gear replaced during upgrades, parts returned under warranty, and devices sent to third-party repair. The requirement is simple to state but easy to fail in practice because disposal workflows span teams (IT, Security, Facilities, Procurement), systems (ITSM, CMDB, asset tools), and external providers (IT asset disposition firms, OEMs, logistics).

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing SR-12 is to treat it as an end-to-end “component exit” control: you define which components are in scope, define approved disposal techniques by component type, embed those steps into decommission/RMA workflows, and retain evidence that disposal happened as specified. The control is satisfied when you can pick a random disposed component from the asset register and produce a disposal record with method, date, handler, and chain of custody. ¹

Regulatory text

Requirement (excerpt): “Dispose of {{ insert: param, sr-12_odp.01 }} using the following techniques and methods: {{ insert: param, sr-12_odp.02 }}.” ¹

Operator interpretation: Your system must (1) identify the components that require controlled disposal, and (2) dispose of them using documented techniques and methods you have selected and approved. The placeholders in the excerpt indicate the organization must define the “objects of disposal” (components) and the “techniques and methods” (how disposal is performed) as part of implementation. ¹

What an assessor will expect to see:

• A defined standard for disposal/sanitization methods that is actually used, not just a generic statement.
• A repeatable workflow (tickets, approvals, handoffs) that triggers the right method based on component type and data sensitivity.
• Evidence per disposal event, including third-party certificates where applicable. ²

Plain-English interpretation of the requirement

SR-12 requires you to prevent data exposure through discarded, recycled, resold, returned, or scrapped components. If a component can store or reveal sensitive information (data at rest, credentials, configs, keys, logs, topology), you need a controlled process that ensures the component is sanitized or destroyed using an approved method and that you can prove it happened. ¹

This control is broader than “wipe hard drives.” In practice, it covers:

• Storage media (HDD/SSD, removable media)
• End-user devices and servers
• Network appliances and embedded storage (switches, firewalls)
• Printer/MFP internal storage
• Components replaced during break/fix (drives, mainboards)
• Any part leaving your custody via ITAD, RMA, repair, donation, or resale ²

Who it applies to (entity and operational context)

SR-12 is typically implemented by:

• Federal information systems and programs inheriting NIST SP 800-53 controls. ²
• Contractor systems handling federal data, including environments where components are owned, operated, repaired, transported, or disposed of by third parties. ²

Operational contexts where SR-12 commonly fails:

• Asset refresh projects where pallets of devices leave the building without a complete asset-to-disposal mapping.
• OEM warranty returns where failed drives or devices are shipped back without verified sanitization.
• Colocation or managed services where a provider removes hardware and the customer receives only a generic monthly report.
• “Shadow disposal” by local offices using e-waste bins without chain of custody. ²

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

1) Assign ownership and map the control to workflows

• Name a control owner (often IT Asset Management or Security Operations) and a compliance owner (GRC) responsible for testing and evidence.
• Map SR-12 to the actual workflow entry points: decommission, break/fix, RMA, end-of-lease, office closures, lab cleanouts.
  Recommended operational control: “Map SR-12 to control owner, implementation procedure, and recurring evidence artifacts.” ¹

2) Define scope: which “components” require controlled disposal

Create an in-scope component list tied to your asset inventory/CMDB:

• Any component with non-volatile storage.
• Any component that may hold configuration or credentials.
• Any component that is programmed or customized for your environment. ²

Make scoping rules explicit (examples you can adopt):

• “All drives are in scope regardless of classification.”
• “Network gear is in scope if it contains persistent configs/logs.”
• “Printers/MFPs are in scope if they contain storage.”
  Your scoping rule is what keeps exceptions from turning into findings.

3) Define approved disposal techniques and methods (the “methods library”)

Build a disposal standard that states, by component type and data sensitivity, the allowed methods. Keep it simple enough that technicians follow it:

• Sanitization (logical clearing/purging) for reusable devices where permitted.
• Physical destruction for components you will not reuse, or where sanitization cannot be validated.
• Cryptographic erase where storage is encrypted and you can reliably destroy keys. (Describe the condition under which this is acceptable in your environment.) ²

Include decision criteria:

• Reuse vs. destroy
• On-prem vs. third-party handling
• Classified/restricted environments vs. standard corporate endpoints
• RMA path: “sanitize first unless device is non-functional; if non-functional, destroy storage media and return device without media if contract allows.”

4) Embed SR-12 into operational tickets (so it happens by default)

In your ITSM:

• Add a required field: Disposal method selected (dropdown tied to your methods library).
• Require asset identifier(s) (serial, hostname, asset tag) and component identifiers (drive serials when feasible).
• Add approvals for higher-risk categories (restricted data, regulated workloads, privileged systems).
• Add a “no exit without evidence” gate before closing the decommission/RMA task. ²

5) Control chain of custody end-to-end

Chain of custody is where audits focus because it proves components were not diverted:

• Use tamper-evident packaging for shipments where feasible.
• Track handoffs: who released the component, who transported it, who received it, who performed destruction/sanitization, and when.
• For third parties, require documentation that ties certificates to your asset identifiers, not just “box 3 destroyed.” ²

6) Manage third parties (ITAD, repair, logistics, managed services)

Update contracts/SOWs to require:

• Approved disposal methods aligned to your standard.
• Evidence formats (certificate of destruction/sanitization, serial-level reporting where required).
• Breach notification and loss reporting for components in transit.
• Right to audit or obtain independent attestations relevant to disposal. ²

7) Validate and monitor (control operation)

Build a lightweight assurance loop:

• Periodic sampling: select disposed assets and verify complete evidence.
• Reconcile: disposed assets in CMDB must match disposal records.
• Exception handling: document and approve any deviation from the methods library (for example, device too damaged to sanitize). ²

Required evidence and artifacts to retain

Retain artifacts that prove method, scope, and execution:

• Component disposal standard (methods library) and approval record.
• Asset inventory/CMDB extract showing disposed status and dates.
• ITSM tickets/work orders with method selected, approvals, and closure evidence.
• Chain-of-custody logs (handoff records, shipping tracking, receiving confirmation).
• Certificates of destruction/sanitization from third parties, tied to serial/asset tag where feasible.
• Exception register (what deviated, why, who approved, compensating steps).
• Periodic review results (sampling worksheet, findings, remediation tickets). ²

Daydream tip: In Daydream, model SR-12 as a requirement with a single “evidence bundle” checklist so teams upload the same artifact types each cycle, and you can answer assessor requests without hunting across tools. ¹

Common exam/audit questions and hangups

Expect these, and prepare evidence that answers them quickly:

1. “Show me your approved disposal methods.” Auditors want the defined techniques and how you choose them. ¹
2. “Prove this specific device was disposed of properly.” They will pick a sample asset tag and ask for end-to-end evidence. ²
3. “How do you control warranty returns?” RMA paths often bypass ITAD controls. ²
4. “How do you ensure third parties follow your methods?” Contract language plus actual certificates and reconciliation. ²
5. “What about non-traditional storage?” Printers, IoT, network gear, and embedded flash. ²

Frequent implementation mistakes and how to avoid them

• Mistake: Policy-only compliance. A disposal policy with no ticket workflow and no sampleable evidence will fail. Fix: make ITSM closure contingent on evidence attachment. ²
• Mistake: Treating ITAD certificates as sufficient without reconciliation. A certificate that is not tied to your asset identifiers leaves gaps. Fix: require serial-level reporting where feasible and reconcile to CMDB. ²
• Mistake: Ignoring repair/RMA flows. Devices shipped to OEMs can still contain data. Fix: add an RMA playbook that includes sanitization or media removal and a documented exception path. ²
• Mistake: Missing component-level scope. Teams dispose of “devices” but forget replaceable components (drives, mainboards). Fix: define “component” explicitly in scope rules and require drive serial capture when possible. ²
• Mistake: No chain of custody for office cleanouts. Facilities-led e-waste disposal is a common blind spot. Fix: require Security/IT sign-off for any electronics disposal and route it through the same workflow. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should plan around assessor scrutiny and incident impact rather than case law. Practically, SR-12 failures tend to surface through data exposure events (lost devices, resale with recoverable data) and through audits where evidence is incomplete or inconsistent. The risk is high-impact even when the control severity is assessed as medium, because disposal failures can expose credentials, keys, and regulated data in a single event. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign control owner and GRC testing owner; document RACI.
• Pull an asset inventory extract; define in-scope component categories.
• Draft the disposal methods library and get Security approval.
• Identify disposal pathways (ITAD, RMA, repair, office e-waste) and owners for each. ²

Next 60 days (embed into operations and third parties)

• Update ITSM workflows: mandatory disposal method field, evidence attachment, closure gates.
• Create chain-of-custody template and shipping/receipt checklist.
• Amend third-party contracts/SOWs for evidence requirements and method alignment.
• Train IT, Facilities, and Procurement on the “component exit” workflow. ²

By 90 days (prove operation and build audit readiness)

• Run a sampling review of completed disposals; document results and remediation.
• Reconcile CMDB “disposed” assets to certificates/tickets; address mismatches.
• Stand up a recurring evidence cadence in Daydream (or your GRC system): monthly/quarterly uploads of disposal logs, samples, exceptions, and third-party certificates. ¹

Frequently Asked Questions

Does SR-12 apply only to hard drives?

No. Treat “components” as any part that can store or disclose data, configs, credentials, or logs, including embedded storage in network gear and printers. Your scoping rules should name these categories explicitly. ²

Can we rely on full-disk encryption and just dispose of devices normally?

You can allow crypto-erase in your approved methods library if you can show it reliably renders data unrecoverable (for example, by destroying keys). Document when it is acceptable and keep evidence that the method was executed for each asset. ²

What evidence is “enough” for an assessor?

Expect to produce a ticket/work order, chain-of-custody record, and a destruction/sanitization record tied to an asset identifier. Evidence must support a sample-based test across multiple disposal events. ²

How do we handle warranty returns (RMA) where the OEM requires the drive?

Build an RMA playbook: sanitize before shipment when possible; if the device is non-functional, remove and destroy the media if contractually permitted, or document an approved exception with compensating controls and OEM handling requirements. Keep shipping and receipt evidence. ²

Our ITAD provider gives a single PDF certificate per pickup. Is that sufficient?

Often no, because you still must prove which specific assets were included and which method was used. Require itemized reporting tied to asset tags or serials where feasible, and reconcile it to your CMDB and pickup manifest. ²

How should a GRC team test SR-12 without disrupting operations?

Use sampling: select disposed assets from the CMDB, then trace to tickets, manifests, and certificates. Record exceptions and remediation tickets as part of ongoing control monitoring. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5