MP-5(2): Documentation of Activities

MP-5(2): Documentation of Activities requires you to record and retain evidence of media protection activities so an assessor can verify what was done, by whom, when, and under which approved procedure. Operationalize it by defining what “media activities” you perform, assigning an owner, standardizing a log template, and setting a repeatable evidence-collection cadence tied to those workflows. ¹

Key takeaways:

• Treat MP-5(2) as an evidence engineering requirement: activities must be provable, not just performed. ¹
• Map each media-handling workflow to a record type, owner, and retention location so audits do not devolve into email archaeology. ¹
• Build “audit-ready by default” documentation into ticketing, chain-of-custody forms, and approvals for sanitization, transport, storage, reuse, and disposal. ¹

The mp-5(2): documentation of activities requirement sits in the Media Protection (MP) family of NIST SP 800-53 Rev. 5. In practice, it is the control enhancement that turns your media protection program from “we have a policy” into “we can prove we executed it.” The fastest path to compliance is to stop thinking of documentation as a separate task and instead treat it as an output of each media activity your teams already perform: issuing encrypted drives, moving backup tapes, receiving assets from a third party, sanitizing endpoints for redeployment, or destroying retired media.

For a Compliance Officer, CCO, or GRC lead, the operational goal is clear: define the documentation you expect for each activity, ensure it is captured consistently, and store it where you can retrieve it quickly for internal reviews, customer inquiries, and external assessments. If you run federal systems or handle federal data as a contractor, MP-5(2) often becomes a “show me” control during security assessments because media is a common pathway for data loss, inventory gaps, and weak offboarding. ²

Regulatory text

Framework excerpt: “NIST SP 800-53 control MP-5.2.” ¹

What the operator must do: implement and maintain documentation that records your media protection activities with enough detail for an assessor to confirm that required actions occurred and were authorized. Because the excerpt provided is high-level, operationalization should focus on: (1) defining which activities count, (2) standardizing what gets recorded for each, and (3) ensuring records are retained and retrievable across the system lifecycle. ¹

Plain-English interpretation (what MP-5(2) is really asking)

MP-5(2) expects you to document media-related security actions as they happen so you can later demonstrate control operation. If you sanitize a laptop, you should have a record that links the asset ID to the method used, the approver, the technician, the date/time, and the outcome. If you move backup media offsite with a third party, you should have chain-of-custody evidence that shows transfer and receipt.

A clean mental model: every media activity needs a “who/what/when/where/how/proof” record. ¹

Who it applies to

Entity types and environments

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data, including environments where a third party stores, transports, sanitizes, or destroys media on your behalf. ¹

Operational contexts where MP-5(2) becomes “real”

• Endpoint refresh and redeployment programs (sanitize, reimage, reuse).
• Data center operations (drive replacement, storage arrays, decommissioning).
• Backup operations (tapes, removable drives, offline backups).
• Incident response (quarantining or preserving media as evidence).
• Third-party logistics and destruction (RMA shipments, shredding vendors, e-waste).

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

1) Define your “media activities” in scope

Create a short, explicit list of activities that must generate documentation. Start with:

• Media receipt and assignment (new assets, returned assets, loaners)
• Media transport (internal moves, offsite storage, shipping)
• Media storage and access (who can access cages, safes, tape rooms)
• Media sanitization (wipe, crypto-erase, degauss)
• Media destruction/disposal (shred, pulverize, certified destruction)
• Media reuse/redeployment (post-sanitization approval to reissue) Tie each activity to where it happens (sites, cloud ops locations, remote workforce) and who performs it (IT, facilities, third party). ¹

2) Assign ownership and RACI for documentation

For each activity, assign:

• Control owner (accountable for the program)
• Process owner (runs the workflow)
• Record producer (who fills the log/ticket)
• Record approver (who signs off when required) Avoid “shared ownership.” Audits stall when nobody owns completeness. ¹

3) Standardize a documentation schema (template + required fields)

Build a single template (form, ticket type, or spreadsheet) with consistent fields:

• Unique record ID
• Activity type (sanitize, transport, destroy, etc.)
• Asset/media identifier (serial, hostname, tape ID)
• System/business owner or custodian
• Data classification (if used in your program)
• Location (origin/destination)
• Method/procedure reference (SOP name/version)
• Date/time performed
• Performer and verifier
• Outcome (pass/fail) and exceptions
• Attachments (photos, certificates, scan of chain-of-custody) This standardization is how you keep evidence coherent across teams. ¹

4) Embed documentation into the workflow (don’t bolt it on)

Pick the system your operators already live in:

• ITSM ticketing for endpoint and data center tasks
• A GRC workflow for approvals and attestations
• A secure repository for third-party destruction certificates Hard requirement for operators: no activity is “done” until the record is complete and any approvals/attachments are present.

Practical guardrails:

• Make required fields mandatory in the ticket type.
• Require an attachment for any third-party destruction event (certificate + asset list).
• Use barcode/QR scanning where available to reduce transcription errors. ¹

5) Set retention, access controls, and retrieval expectations

Define:

• Where records are stored (system of record)
• Who can view/edit
• How you prevent tampering (permissions, immutable storage where feasible)
• How you will retrieve evidence for an assessor (search fields, naming conventions)

If your evidence is split across email, shared drives, and third-party portals, consolidate pointers: store a single “evidence index” record that links to the authoritative artifact. ¹

6) Run a recurring completeness check (quality control)

Perform periodic checks for:

• Missing asset IDs
• Missing approvals
• No attached certificate/chain-of-custody
• Records created after the fact
• Inconsistent method references

Daydream fits naturally here as the place to map MP-5(2) to a named owner, a documented procedure, and a recurring evidence list so your evidence arrives on time and in the same shape every cycle. ¹

Required evidence and artifacts to retain

Keep evidence that proves both execution and authorization:

Core artifacts

• Media handling SOPs (sanitization, transport, destruction) with version control
• Logs/tickets showing each activity event and required fields
• Chain-of-custody forms for transfers (especially with a third party)
• Destruction certificates and supporting asset lists
• Sanitization reports (tool output) or technician attestation with method reference
• Inventory extracts that tie assets to disposition state (in use, stored, sanitized, destroyed)
• Exception approvals (if an alternate method was used)

Evidence hygiene

• Evidence should be attributable (named performer/verifier).
• Evidence should be time-bound (date/time).
• Evidence should be traceable (asset ID + record ID + procedure version). ¹

Common exam/audit questions and hangups

Expect assessors to probe “prove it” paths:

• “Show me the last set of media destruction events and the certificates.”
• “How do you prove sanitization happened before redeployment?”
• “How do you document chain of custody for offsite backup media?”
• “How do you prevent someone from editing records after the fact?”
• “How do you handle media activities performed by a third party?”

Hangup pattern: you have policies, but evidence is incomplete, scattered, or not linkable to asset inventory. MP-5(2) fails most often as an evidence retrieval problem, not a technology problem. ¹

Frequent implementation mistakes (and how to avoid them)

1. Relying on informal emails or chat messages
   Fix: force documentation into a structured record (ticket/form) with required fields. ¹

2. No linkage between certificates and your asset inventory
   Fix: require asset IDs on certificates or attach an internal mapping sheet signed by the custodian. ¹

3. Documenting only “destruction,” ignoring transport and storage events
   Fix: define the full activity list and attach evidence expectations to each workflow. ¹

4. Third-party performed work without your validation record
   Fix: treat third-party artifacts as inputs; your record should confirm receipt, review, and acceptance. ¹

5. Backfilled records created right before an audit
   Fix: implement close-out controls so the task cannot be completed until documentation is present. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Operational risk remains concrete:

• Missing documentation increases the chance you cannot prove media sanitization or destruction after an incident, customer inquiry, or assessment.
• Weak chain-of-custody documentation increases exposure when media is lost in transit or handled by a third party.
• Poor evidence practices create audit findings that can delay authorizations, renewals, or customer security approvals in federal or federal-adjacent environments. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Inventory your media activities and the teams/third parties involved.
• Assign a single accountable owner for MP-5(2) and owners per workflow.
• Choose a system of record (ITSM or GRC workflow) and define the required fields.
• Pilot the documentation template on the highest-risk activity (typically destruction and sanitization). ¹

Days 31–60 (embed into operations)

• Implement required-field ticket types/forms for each activity.
• Add approval steps where you need authorization (exceptions, reuse, offsite transport).
• Centralize third-party artifacts (certificates, custody forms) with consistent naming and indexing.
• Train operators and require documentation at task close-out. ¹

Days 61–90 (prove repeatability)

• Run a completeness review and remediate missing fields/attachments.
• Test evidence retrieval: pick sample events and assemble an “audit packet” quickly.
• Establish ongoing monitoring: periodic sampling, exception tracking, and a backlog process.
• In Daydream, map MP-5(2) to the control owner, the final procedures, and a recurring evidence checklist so your collection becomes routine instead of event-driven. ¹

Frequently Asked Questions

What counts as an “activity” under mp-5(2): documentation of activities requirement?

Treat any action that changes media custody, location, security state, or lifecycle status as an activity. Common examples are transport, offsite storage transfers, sanitization, redeployment approval, and destruction. ¹

Do we need a separate log if we already use ITSM tickets?

No, if the ITSM ticket contains the required fields, approvals, and attachments, it can be your record. The audit test is whether the ticket is complete, attributable, and retrievable by asset and date range. ¹

How do we handle third-party destruction certificates that don’t list serial numbers?

Require the third party to include identifiers when contractually possible. If they cannot, create an internal mapping record that ties the certificate to your asset inventory and have a custodian sign off on the mapping. ¹

What’s the minimum metadata we should capture for sanitization events?

Capture asset ID, method/procedure reference, date/time, performer, verifier, and outcome, plus tool output where available. That combination lets an assessor validate both execution and adherence to your defined method. ¹

Can a spreadsheet satisfy MP-5(2)?

A spreadsheet can work early on if it is access-controlled, versioned, and consistently completed. Most teams later move to ticketing or workflow tooling to reduce omissions and improve auditability. ¹

How should we present evidence during an assessment?

Build an “audit packet” per sampled event: the record (ticket/log entry), attachments (certificate/custody/tool output), and the referenced SOP version. Make the trace from asset inventory to final disposition easy to follow. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5