3.8 MP
788 paragraphs across seven sections. Here is the structure and the decisions that matter most in this family.
Document structure
The nine MP controls split into four implementation areas, and the document is organised around that split rather than control number order. Physical media protection and access control (3.8.1, 3.8.2, 3.8.4, 3.8.5) is primarily an IT operations and facilities matter. Media sanitisation (3.8.3 — the CMMC Level 1 practice) gets its own group with a prominent call-out, and its full operational procedure is in Section 3. Removable media (3.8.7, 3.8.8) is a technical enforcement problem. Encryption (3.8.6, 3.8.9) links directly to the cryptographic standards in AT-SC-ENC.
Section 3 is the operational core — it contains the complete media sanitisation procedure across six media type groups (HDDs, SSDs/NVMe, USB/SD cards, magnetic tape, mobile devices, and paper), each with scenario-specific methods, the applicable standard, the approved tool, and the documentation requirement. The destruction certificate minimum content table at section 3G defines exactly what a vendor certificate must contain to be admissible as evidence for MP.L1-3.8.3. This table exists because the most common finding in this family is not that sanitisation was not done — it is that the certificates cannot prove it was done correctly.
The SSD sanitisation issue — the most technically important point in the document
The SSD sanitisation tables in section 3B contain a warning box that deserves particular attention: overwrite is not an accepted method for CUI disposal on solid-state media. This is not a minor technical detail — it is a fundamental difference from how HDDs are handled that many organisations miss entirely.
Wear-levelling algorithms in SSDs distribute writes across the storage medium to extend lifespan. When an overwrite tool writes zeros or random data to logical block addresses, it writes to the logical address space — but the physical storage cells underneath are managed by the drive's firmware. Reserved cells, over-provisioned cells, and cells holding data that the wear-levelling algorithm has moved cannot be reached through logical address writes. A forensic tool reading physical cell voltages can recover data from these cells even after multiple logical overwrites.
For CUI on SSDs: cryptographic erasure (destroying the encryption key, rendering all data permanently inaccessible) on self-encrypting drives, or physical shredding to particles of 2mm or smaller, are the only acceptable methods under NIST SP 800-88. This applies to every USB drive, SD card, laptop SSD, NVMe drive, phone flash storage, and cloud instance ephemeral storage that ever held CUI. The common situation to watch for is a laptop return: the laptop goes to the IT team, someone runs DBAN on it, and it is either reissued or sent to a disposal vendor. If the laptop has an SSD (which all modern laptops do), DBAN accomplished nothing for the underlying cells.
Destruction certificates — the evidence item that assessors reach for first
The destruction certificate content table in section 3G lists nine required elements. The two that most frequently disqualify vendor certificates are the per-asset identification requirement and the destruction method requirement.
Per-asset identification means individual line items: make, model, serial number, and organisation asset ID — one row per device. A certificate that says "50 hard drives, 200 kg" does not satisfy this requirement regardless of how reputable the vendor is. The certificate must let an assessor trace from the certificate to the media inventory (EV-D22) for every disposed item, confirming that every CUI-scope asset that left the building has a corresponding destruction record. Assets not on the certificate cannot be evidenced as destroyed.
The destruction method requirement means the specific technical method — not "destroyed" or "data wiped." A certificate needs to state shredding with particle size, or cryptographic erasure of specific device models, or degaussing with a specific degausser model followed by shredding. Without the method, there is no basis for assessing whether the method applied was appropriate for the data classification.
Before any assessment, print the EV-D25 destruction certificate file and cross-reference it against the asset register. Every CUI-scope asset marked as disposed in the asset register must have a corresponding certificate entry with that asset's serial number visible on the certificate. Any gap is a finding.
Backup encryption — the cloud provider key issue
The 3.8.9 backup encryption section makes a distinction that is frequently misunderstood in cloud environments. AWS S3 server-side encryption with an AWS-managed key (SSE-S3) or even with an AWS KMS key (SSE-KMS with an AWS-managed CMK) means that AWS holds the encryption key. If AWS is compelled by legal process, or if an AWS administrator has sufficient access, the data can be decrypted without the organisation's knowledge or consent. For CUI, this is not an acceptable model.
The required implementation is client-side encryption: the backup software encrypts data using a key that never leaves the organisation's control before transmitting to the cloud storage provider. The cloud provider stores and retrieves ciphertext — it never sees the plaintext or the key. This distinction must be documented in the SSP and verified in the annual encryption audit (EV-D31): specifically, that the backup encryption key is in the organisation's PAM vault, not in the cloud provider's key store.
Cross-linking in Confluence
The AT-MP page connects to five other pages in the ISMS space. Link to AT-PE (Physical Protection) because the server room and media cabinet physical access controls are documented there under 3.10.1 through 3.10.5 — the two families share the physical access log evidence (EV-D23). Link to AT-SC-ENC because the portable media encryption requirements in 3.8.6 use the same FIPS validation standard documented for transit and at-rest encryption; the FIPS module numbers for approved hardware-encrypted drives belong in EV-D31 alongside the other cryptographic module documentation. Link to AT-CM because the removable media USB block policy is part of the system hardened baseline specifications, and the quarterly configuration audit (EV-D20) that verifies the USB block is the same audit that checks all baseline settings. Link to FC-07 (the all-staff visible Fundamental Controls media protection page) to make the relationship between the technical page and the behavioural page explicit. And link to the Data Classification Policy because CUI marking (3.8.4) implements that policy for physical media — the marking format and the CUI category designations are defined in the policy, and this page operationalises them.
The complete NIST 800-171 family page library so far
With AT-MP complete, seven of the fourteen family pages are now built:
| Page | Controls | Status |
|---|---|---|
| AT-AC · Access Control | 22 | Complete |
| AT-AT · Awareness and Training | 3 | Complete |
| AT-SC · System and Comms Protection | 16 | Complete (3 sub-pages) |
| AT-SI · System and Info Integrity | 7 | Complete |
| AT-IA · Identification and Authentication | 11 | Complete |
| AT-CM · Configuration Management | 9 | Complete |
| AT-MP · Media Protection | 9 | Complete |
Seven families remain: AT-AU (Audit and Accountability, 9 controls), AT-IR (Incident Response, 3 controls), AT-MA (Maintenance, 6 controls), AT-PE (Physical Protection, 6 controls), AT-PS (Personnel Security, 2 controls), AT-RA (Risk Assessment, 3 controls), and AT-CA (Security Assessment, 4 controls — the SSP master document). Click the family card for any of these in the interactive browser to prompt the full page content.