Data Sanitization Policy Template (Free, NIST 800-88 Rev. 2)

A data sanitization policy template gives you the written rules for clearing storage before it leaves your hands: which method each kind of data needs, who does the work, who checks it, and what you keep as proof. Ours is free, in Word and PDF. Each section is built on a section of NIST SP 800-88 Rev. 2, and where NIST leaves a choice to you, the template leaves a highlighted blank.

Below we walk through each section: what NIST says, what you have to decide, and the traps.

---

1. What a data sanitization policy is for

Sanitization means making data on storage media unrecoverable. A policy is the part that decides things before anyone touches a drive. NIST is blunt about why it matters: "The presence or absence of a storage sanitization policy can significantly impact the effectiveness of an organization's storage sanitization activities" (NIST SP 800-88 Rev. 2, Sec. 4.1).

People often mix up three documents. They do different jobs:

The policy comes first. Without it, the procedure has no rules to follow and the certificate has nothing to be measured against.

2. What NIST says a policy should cover

NIST SP 800-88 Rev. 2 was published in September 2025. Its Section 4 describes a whole sanitization program, and Section 4.1 lists what the policy itself "should address". The template has a section for each item:

The other sections (scope, verification, validation, exceptions, review) come from the rest of Section 4. The template's last page lists them all.

3. The sections, one by one

Scope: every drive, and all of each drive

Say which media the policy covers, whose data it holds, and which sites it applies to. Two rules from NIST are worth keeping as written. First, look for every storage part in a device: "a desktop computer can contain a hard drive, motherboard, RAM, and ROM" (Sec. 4.3.1). Second, sanitize the whole drive, not part of it. NIST prefers whole-device sanitization because data on part of a drive can spill into areas you can't reach, "remapped bad blocks or overprovisioning" (Sec. 4.2).

Roles: name a second person

NIST's roles (Sec. 4.7) use US government titles. The template turns them into the jobs an ITAD or IT team actually has: policy owner, technician, validator, asset manager, records owner and privacy lead. Fill in a name or job title for each.

The one rule that matters most: the validator can't be the technician who did the work. One person runs the wipe, someone else accepts it. That split is what makes the record believable.

Classify the data first

This is the step most people skip. NIST: "The decision process is based on the confidentiality of the information rather than the type of media" (Sec. 4.3). So you decide the category (Low, Moderate, High) first, and the drive type only decides the technique later. The template has blanks for what each category means in your business, and for what happens when nobody tells you (we suggest treating unknown as High).

Minimum method by category and destination

NIST's decision flow (Figure 1) turns two questions into a method: how sensitive is the data, and will the media leave your control?

In plain words: Clear protects against recovery through the drive's normal interface, like an overwrite. Purge makes recovery infeasible even in a lab and can leave the drive reusable, like a drive's own sanitize command. Destroy also makes recovery infeasible, and the drive can't be used again (Sec. 3.1).

Media "leaves your control" when it is sold, donated, returned from a lease, swapped under warranty or sent to a recycler (Sec. 4.3.4). For an ITAD or refurbisher that is almost everything. So read the bottom row carefully: if a customer's data is High and you plan to resell the drives, NIST's flow says Destroy. Settle that in the contract before the drives arrive, not at the bench.

Techniques by media type

The method is the goal. The technique is how you reach it on a given drive. The template's table lists the usual techniques for hard drives, SSDs, USB media, phones and paper, with blanks for your own destruction equipment. Two warnings from NIST are built in:

• Overwriting an SSD doesn't reach its spare cells. Wear levelling makes it "infeasible for a user to sanitize all previous data using this approach" (Sec. 3.1.1).
• Never degauss flash. "A sanitization operation that degausses an SSD can complete successfully, but no sensitive data is sanitized" (Sec. 4.5.2).

NIST also asks that techniques comply with IEEE 2883, or another standard your policy accepts (Sec. 4.4). The template has a blank for the second option.

Tools

List every tool and machine you allow, with its version and when it was last tested or calibrated. A new version goes through the same test before use. Versions matter because the certificate has to name the "tool used, including version" (Sec. 4.6).

Verification: did it complete?

Verification checks that the technique finished. For Clear and Purge, NIST's baseline is the tool's completion status, errors, anomalies and the drive's health. For Destroy, it is inspecting what's left (Sec. 4.5.1).

Then comes the blank everyone asks about: how much of each drive to read back. NIST leaves it to you: "Unless explicitly required by organizational policy, elaborate sampling of an ISM's contents (e.g., full or representative) after clear or purge sanitization techniques is not necessary" (Sec. 4.5.1). So whatever number you write in the blank becomes your requirement, and auditors will hold you to it. Our guide to how much of a wiped drive to read back helps you pick one.

If you're R2v3 certified, there's a second, separate check. SERI's own guidance quotes requirement (13) of Appendix B: "A minimum of 5% of logically sanitized data storage media shall be routinely sampled by competent and independent party to demonstrate data is not recoverable by commercial software" (SERI, archived copy). The same page says the sample can drop to as low as 1% after continued clean results, and that a failed sample puts earlier devices in question. The template's quality-check line has blanks for your percentage and how often you sample.

Validation: is the result good enough?

Validation is the second person's decision to accept or reject. NIST lists reasons to reject (Sec. 4.5.2), and the template copies them as plain rules: errors or unreachable areas, the wrong technique for the media, an untrained person or an uncalibrated tool, a result below your minimum, or a scope that was too narrow. Rejected media is sanitized again with a different technique, or moved up to a stronger method.

Records

NIST says a certificate of sanitization "should be completed for each ISM that has been sanitized" (Sec. 4.6). ISM just means a storage device. The template lists the minimum fields. Our free certificate of sanitization template is the matching form.

NIST adds one thing many policies miss: track each device at three points, when it arrives, when it leaves its last place of use, and when it reaches its destination. Without the first point, your records show that some drives were sanitized, but "not whether the organization is effectively sanitizing all ISM" (Sec. 4.6).

Retention is a blank on purpose. NIST sets no retention period for these records. It gives a records management role the job of advising on "retention requirements so that the sanitization of media will not destroy records that should be preserved" (Sec. 4.7.8). Check your contracts, your certification scheme and the laws that apply to you, then write the longest period that applies.

Training, exceptions and review

Short sections, but auditors read them. Nobody sanitizes or validates until trained and signed off. Any departure from the policy is approved in writing before the work, with the risk written down. And the policy is reviewed on a schedule you set, plus whenever a new media type, tool version or failed quality check shows up. NIST notes that techniques "need to be updated on a regular basis" as storage changes (Sec. 3.1).

4. The blanks you have to fill

5. What reCore records against a policy like this

reCore is wipe and diagnostics software, so it covers the wiping parts of this policy and keeps the record of each one. Here's what it does, checked against the code:

• Picks the technique per drive. It uses the drive's own Purge command when the drive and the station support one, and falls back to a Clear overwrite when they don't.
• Enforces your read-back floor. Every wipe except a cryptographic erase is read back, at least 10% of the drive by default. You can set a stricter level for the whole organization or for one batch, which requires Purge with no fallback and a 100% read-back. Requests below the floor are raised to it. A certificate is refused if the wipe falls short of the level it ran under.
• Fills in the certificate. Drive make, model and serial, asset tag, method, technique (with its IEEE 2883 reference), tool and version, verification method and the coverage actually reached, location, and any hidden area found on the drive.
• Requires a second person. The person who ran the wipe can't approve its certificate. The approver records where the drive goes next: reuse, transfer or destroy.
• Tags every device at check-in, so tracking starts when the device arrives.

What stays your job: writing and approving the policy, deciding the data categories, physical destruction and inspecting what's left, the R2v3 recovery-software sample by an independent person, training records, and how long records are kept. See compliance features for the certificate side, or pricing for plans and the free trial.

Conclusion

A data sanitization policy is mostly decisions. NIST gives you the structure: classify the data, pick the method from the category and the destination, verify, have someone else validate, and keep a record per drive. The numbers are yours: the read-back percentage, the sample size, the retention period, the names. The template puts each of those decisions in front of you as a blank. Fill them in, have the policy approved, and then hold your floor to it. For background on the standard itself, see our NIST SP 800-88 overview.

---

Sources

• NIST, SP 800-88 Rev. 2, Guidelines for Media Sanitization, September 2025: Sec. 3.1 (methods), 4.1 (policy), 4.2 (scope), 4.3 and Figure 1 (decision flow), 4.4 (performing sanitization), 4.5 (verification and validation), 4.6 (documentation), 4.7 (roles).
• SERI, Verifying the Effectiveness of the Data Sanitization Process (R2v3 Appendix B, requirement 13), Wayback Machine copy of January 18, 2026.