What do you think of this logic: NIST 800-88 media sanitization standard
describes what data destruction is. The standard
measures destruction thoroughness on a scale of of 1 to 4 (i.e. hitting the
delete key, overwriting data 'clearing', overwriting data 'purging',
destruction of the media). That scale is a value judgement,
implying that more thorough destruction is better destruction. This is
implied throughout NIST 800-88. Therefore, leaving behind some metadata of
a destroyed record would be shoddy destruction.

Applying that same logic to paper records, the 'destruction certificates'
issued by storage vendors should therefore be destroyed quickly after the
destruction service is carried out.
Destruction certificates identify box numbers and some metadata about box
contents, although not time/date of destruction or method of destruction
(which I find puzzling).
The purpose of the destruction certificate should only be to allow the
records manager to reconcile the invoice from the vendor. Or maybe to allow
the records manager to confirm to record owners whether an item eligibile
for destruction this calendar year has been destroyed yet. But as long as
it is kept, the destruction certificate is vulnerable to discovery, i.e. to
the chain of production requests by attorneys gone wild (attorneys gone
fishing).

Then there's the problem of emailed destruction requests from the records
manager to the storage vendor. It's easier to email than to fax destruction
lists and nice to have 'sent' items if there's a need to track service
problems related to a vendor. If an email management system
retains everything and/or puts retention periods on everything, then the
destruction request carries the risk of the discovery avalanche, even
though any given destruction request was probably not exactly what
was carried out by the vendor (i.e the request is not the 'authoritative
format' that Gordy mentioned).

-- 
Maureen Cusack
San Francisco, CA
[log in to unmask]

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]