Data destruction policy: the decisions it has to make before anyone needs it

Most organizations have a data retention policy that says how long data is kept. Fewer have a data destruction policy that says what happens to the media once data is no longer needed or the equipment is retired. The second is the one an auditor asks for after a decommission, and the one a project team needs before it starts.

Scope: every device that stores data

Servers and storage arrays are obvious. Network switches and routers with configuration, printers and copiers with internal drives, laptops, phones, tapes, USB drives and the failed drives sitting in a drawer are less so. A policy that names only hard drives leaves the rest to individual judgment. List the media types explicitly, and add a catch all for anything that stores data.

Method per media type and sensitivity

The core of the policy is a table: for each media type and each data classification, the acceptable methods. Many organizations use the categories of NIST SP 800-88, clear, purge and destroy, as the vocabulary, as described on NIST 800-88. The table should state that flash media cannot be degaussed and that failed devices are destroyed physically.

Who decides and who signs

Name the roles: who classifies the data on a device, who approves the method, who witnesses or verifies, and who signs off the record. Without names or roles, a decommission team under deadline pressure will choose the fastest method available, which is not always the one the data requires.

Chain of custody

From the moment a device is removed from service until it is sanitized or destroyed, the policy should say how it is tracked: serial numbers, sealed containers, transfer signatures. The weak point is transport. If devices leave the site before sanitization, the policy should say under what conditions, and what record of each handoff is required.

Verification and records

The policy should require verification appropriate to the method, and a record per device: serial number, method, date, operator, verification result. It should also state how long those records are kept, which is often longer than people expect, since questions can arise years after the equipment is gone. The record itself is covered in the certificate article.

Vendors are bound by your policy, not theirs

When a vendor does the work, the contract should incorporate the policy’s requirements: methods, records, chain of custody, right to audit, and what happens if a device is lost. A vendor’s own policy describes what it is prepared to do. Your policy describes what you need, and the contract is where the two are reconciled.

Exceptions and legal holds

Data under a legal hold must not be destroyed, whatever the retention schedule says. The policy should require a check against active holds before any destruction, and say who can approve an exception. A short procedure for this prevents the worst outcome, destroying data that a court or regulator expected to be preserved.

Finally, keep the policy short enough to be read. A two page document that says what happens to each media type, who signs and what record is kept will be followed. A forty page document that nobody opens will be replaced, on the day, by whatever the team on the loading dock thinks is reasonable.

Linking the policy to the exit project

A data center exit is where a destruction policy is tested at scale. Before the project starts, check the policy against the inventory: is every media type on the register covered, does every classification map to a method, and is the record the policy requires the same one the vendor will produce? Gaps found at that stage are a meeting. Gaps found during the removal are a delay, and gaps found after it are an audit finding. The decommissioning checklist puts this check at the start of the sequence for that reason.

Review the policy after each major project as well. The equipment, the vendors and the regulations change, and a policy that matched the last exit may not match the next one.