The recently updated North Carolina Administrative Code, as amended and effective June 1st of this year, has two new provisions of interest for records custodians who deal with electronic records. Kelly Eubank wrote an excellent overview of the changes but I would like to, in this post, explore in more detail how a records custodian may comply with the Code.
As you may be aware, destruction of records once they have met their retention period is a vital aspect of a properly functioning records management program, and electronic records are not exempt from this necessity. Even though they do not take up filing cabinet space or boxes in your warehouse, electronic records in a very real sense are more difficult and expensive for an agency to maintain for long periods of time. Therefore destruction of electronic records will make your records management job easier, your agency’s budget more flexible, and — as an added bonus — your IT department will love you.
The relevant portion of the Administrative Code is found in Section 7 – Methods of Destruction. Let us cast our attention upon sub-section (b) which deals with plain vanilla electronic records without confidential portions:
(b) When used in an approved records retention and disposition schedule, the provision that electronic records are to be destroyed means that the data and metadata are to be overwritten, deleted, and unlinked so the data and metadata may not be practicably reconstructed.
If before the publication of the new Administrative Code you felt you didn’t know what to do with your electronic records in order to dispose of them this should help, right. It does tell us to delete the records, so that’s good, but what about the overwritten and unlinked parts – why are they added? The types of electronic records that you will typically come into contact with will exist either as a file found in a file system, or as a set of data managed by a database. Each requires a slightly different approach in order to ensure proper destruction.
To make this discussion a little more digestible, I will cover each part in different blog posts. To begin, I will discuss file system files. In my forthcoming blog posts, I’ll go over database records, and finally, how sub-section (c) poses significant management and technical problems given current trends in network and database architecture.
File System Files
The file system file is most common and most easily dealt with. When a file in a file system is deleted by a user, the data is almost never destroyed immediately. What happens is that the operating system removes it’s memory of the file. The data still exists, but the operating system has given itself permission to overwrite the physical disk space where the binary data that comprised the file was stored. In a sense this is unlinking the data, but it really is an obfuscation of data. If there were sensitive material in the deleted records they could be reconstructed using either off the self software or advanced forensic data recovery techniques.
The Code, thus, instructs records custodians to overwrite the file. Overwriting, or shredding, the file requires special software that writes either a series of 0s then 1s in the place of the original file, randomly generated “noise” data, or both. The file is then unlinked and is effectively destroyed.
Excellent, we have now complied with the Administrative Code. Well, not quite. What about metadata? In most cases a file’s metadata is encapsulated in the file, so the previous operation will destroy the metadata as well. However, it is possible to have what is known as “sidecar” file that contains the metadata about the files you are destroying. These sidecar files are usually user generated and should be known to the records custodian. In this case, simply perform the same shredding operations on the sidecar files. Some sidecars however are not quite so obvious. Sometimes your operating system will create them for its own internal needs. The most common non-user generated sidecar file in a Windows environment is a thumbnail cache. Windows versions from Vista and above, automatically generate a thumbcache.db file that contains reference images of the files in a directory. Not much information is stored in them, but depending on the types of files in the folder they could hold sensitive information and should be destroyed when the records are destroyed. If, for example, a folder contained images of W2s, the thumbnail cache might have an image with enough resolution to obtain information. Below is an example from my computer.
As you can see, the text from this previously deleted image is fuzzy, but still legible. If your agency or department handles images with sensitive information contained in them, good practice would be to disable this functionality in windows. These operations should meet the “practicably reconstructed” language of the code, but be aware, if the files you are destroying existed on drives that are backed up, the deleted files can still be recovered until those backups have aged out based on your backup plan.
Come back in a month or so for a rollicking discussion of electronic records destruction focused on database records. See you then.