Data retention requirements are a reality for financial services companies, and in recent years many have boosted their storage capabilities to meet those requirements. Yet at a certain point business data outlives its usefulness, and a growing number of organizations are struggling with when and how to properly destroy data after it has served its purpose.
The problem stems from the sheer volume of data that is now stored and maintained on storage area networks (SANs) and network attached storage (NAS) devices. A survey of North American IT, business and records management professionals by Enterprise Strategy Group showed that digital archive capacity will increase nearly tenfold between 2005 and 2010 due to regulatory compliance, corporate governance, litigation support, records management, and data management requirements. The total worldwide digital archive capacity in the commercial and government sectors will grow to more than 27,000 petabytes (PB), or 27 exabytes, by 2010, according to Enterprise Strategy Group's 2006 study.
Additionally, now that so many types of electronic devices offer customization and personalization, items once thought as "dumb" must now be included in the evaluation process to determine if it is a candidate for appropriate destruction. Multi-function printers, faxes, phones and even ID badges can retain information that should be considered confidential or regulated in financial services organizations.
Below are six
Let the business define the requirements – Information security officers should work closely with legal, compliance, human resources, audit and business leaders to determine the requirements and build a company definition of the term "destruction." Assist the team in translating technology, capabilities and terms but work together to define the appropriate course of action for the organization. It is especially important to hash out the implementation details on classification labels and tracking where media has been stored during its lifespan.
From an information security standpoint, it may be clear how destruction should occur, but many of the requirements stem from Sarbanes-Oxley, HIPAA and other regulations that should be interpreted by legal or compliance experts. The information security team should be included in the discussion, but should not be looked upon or treated as data owners.
Cost-benefit the options – The notion of "pay now or pay later" plays an important part in setting expectations. Determine which approach your organization will use: whether it will have a default classification for all forms of electronic data (pay later); or will build the necessary capabilities to track physical media histories and classification labels (pay now).
As a practice, defaulting all the electronic data into a critical, confidential or classified classification removes the burden of making decisions that determine the appropriate level of destruction, but in the end increases the overall destruction costs. It can also require an organization to build a core competency in tracking the history of its electronic data and where the data has been stored since its inception. This scenario is not practical from both a cost and execution perspective, and will eventually end up on an audit finding.
Either way, it's an investment in overall data destruction costs to properly eliminate all data bundled under a default classification or to purchase the necessary capabilities in house to make the evaluation process dynamic and easier.
Set expectations early – No matter which way the organization chooses to implement data destruction, it is important during the design phase to communicate with senior leadership about the capabilities and expected costs associated with proper policy implementation. Building the proper process requires that senior leaders understand the definition and risks accepted by the organization at large. If a failure does occur in the future, this will ensure shared accountability across the organization.
Data retention schedule – Develop a schedule that outlines data classifications and the required or expected life of that data in the organization. Provide this document to the IT operation teams so it then becomes a requirement in configuring backup, archiving and destruction processes and cycles. Keep in mind that data destruction occurs in two locations: end of life and technology refreshes or repair. The schedule will be critical to determine how data must be treated during technology refreshes or repairs.
Destruction methodology – Develop organizational standards that outsourcers and internal associates must follow to destroy data. The methods used can be based on the classification of data or establish one method for all. Determine the requirements needed to prove that the methods are being followed operationally and to satisfy audit teams that will eventually review the process. Random audits, penetration tests or simply certificates of destruction can be used to ensure compliance.
Renew leadership commitment – Since the data retention schedule becomes a driver for your IT operations processes, determine a cycle in which you renew the commitment, terms, and definitions used in developing the initial capability. Regulations and requirements change frequently, so establish a renewal process to increase awareness surrounding the changes and to affirm that the policy and expectations still align properly. If new security risks emerge or audit data provides findings that should be discussed or explored further, use this process to facilitate necessary changes in the retention schedules.
By developing a close relationship with the business and providing their requirements to the operation teams, an organization will build a robust process that is effective in eliminating data at the appropriate time, utilizing the appropriate method, and able to demonstrate the appropriate compliance for audits and inquiries.
About the author:
Rick Lawhorn, CISPP, CISA, is the director of information security and compliance at PlanIT Technology Group and previously was CISO for GE Financial Assurance and Genworth Financial. He has more than 17 years of experience in information technology including extensive security experience, and has created a working group focused on developing meaningful metrics for CISOs. He can be reached at email@example.com.
This was first published in March 2008