Susan Trombley, Director, Iron
Mountain Consulting Services
“That’s why the information map we develop for our
clients is valuable,” says Trombley. An information map
helps clients locate electronically stored information for
records typically involved in highly litigated or regulated functions within their organization, such as human
resources, finance or compliance.
Results from Iron Mountain’s Compliance Benchmark
Report regarding the disposal and destruction of eRecords
revealed that customers were better at committing time
and resources to retention than at developing schedules
to determine when records can be destroyed.
Deciding how to dispose of a record is the follow-through on retention, and just as stringently mandated. For
example, the Health Insurance Portability and Accountability Act imposes overwriting or physically destroying
magnetic media that are no longer in use. The Fair and
Accurate Credit Transactions Act requires banking agencies to develop policies for the destruction of consumer
information, both paper and electronic. Finally, Section 501
of the Gramm-Leach-Bliley Act mandates the destruction
of stored customer data, such as credit card information,
as a measure against internal or external threats from
employees or hackers.
Fear and Complexity
Enterprises assume that in order to pinpoint records for
rapid and accurate retrieval, they must be meticulously
categorized. Yet granular classifications, each with its own
retention rule, can be painstaking to create and use. Such
a complex system fosters noncompliance and misclassification.
Regulatory complexity and stringency also foster infinite retention. What is the incentive for destroying records
when stringent requirements exist for keeping them?
First, there is the cost of storing hard-copy records.
Most Iron Mountain customers can immediately dispose
of 35 percent to 40 percent of hard-copy records when they
first apply retention rules to their existing records inventories, Trombley says. But in the case of eRecords, she says,
terabytes are far more economical than physical storage,
making destruction seem unnecessary, even unsafe, given
the chance of a misclassified record.
As convenient as eRecords are to retain, they also
add a layer of complexity with what are called “
unstructured” records—chiefly email, but also other desktop files
like spreadsheets. Trombley estimates that, on average,
between 5 and 7 percent of email messages are business
records, according to Sarbanes-Oxley, HIPAA, GLB and
other definitions. Those emails, and every copy of those
emails, must be accounted for and managed according to
the organization’s retention schedule.
“Big Buckets” Records Classification
Electronic storage of records can vastly simplify their
retention, discovery and ultimately, destruction. Among
databases, search tools, enterprise systems and business
intelligence applications, eRecords can be retrieved efficiently using keyword searches by customer name, contract
number or other such parameters, making granular classifications unnecessary.
Thus, eRecords require fewer and broader retention
categories, known as big buckets. Organizing retention
schedules using fewer buckets helps to accurately and consistently retain critical records, reducing an organization’s
risk of keeping them too long or not long enough.
Big Buckets are broader classifications than most companies have employed to date. In the 1960s and 1970s, retention schedules were based on department structures and
substructures, which in a large organization could mean
hundreds of overlapping categories and subcategories. In
the 1980s, companies migrated toward functional retention
schedules based on job function or business processes.
“The average number of records classes for a functional records retention schedule is between 200 and 300,”
Trombley says. “These categories of information are used
by all departments and business units across the client’s
enterprise to manage their records, both hard copy and
electronic.”
“A Big Bucket retention schedule is still functional in
orientation,” she continues, “with classes falling beneath
the functions—just fewer classes.” For example, accounts
