A funny thing happened at the recent Information Governance Conference (InfoGovCon): An attendee talked about the...
need to tie records retention schedules to business processes.
What's funny about this isn't the comment itself, as that is actually spot-on. What struck me is how seldom the words "process" and "retention" appear in the same sentence, or in the same business process context discussion -- especially where cloud computing is concerned. In the cloud, in particular, the notion of keeping everything associated with a workflow seems to outweigh that of "deleting everything," frequently because people think that "storage is cheap or free, so why not?"
The short answer to that question is that retaining data because you can invites computing costs -- associated with both machines and people -- and legal and compliance liabilities -- e.g., increased security vulnerabilities, exposure to privacy violations -- that you would otherwise choose to avoid.
Getting rid of it all, on the other hand, risks dumping data that some people in your organization still need to do their jobs, thereby disrupting otherwise solid business processes and diluting your ability to make well-grounded business decisions.
Because neither of these options is a good idea, what's an organization to do? Drawing on my business process management (BPM) consulting experience, I suggest these data retention best practices: Establish the business process context, ensure security and recovery, and then build departmental bridges.
1. Establish the business process context
The first step among data retention best practices is to gain a thorough understanding of what your critical business information is used for, by whom and under what circumstances. Without establishing this business process context, you'll never know how long to keep something or whether you need to keep it at all.
Not doing so can be expensive, as well as inefficient. Just shy of a couple of years ago, for instance, the Financial Industry Regulatory Authority fined Barclays Capital Inc. $3.75 million for "systemic failures to preserve electronic records and certain emails and instant messages in the manner required for a period of at least 10 years." The key phrase here is "systemic failure," which says to me that the underlying process lacked certain relevant business rules, and the resulting lack of compliance was left to propagate.
In a similar vein, inadequate procedures for updating energy-plant equipment manuals can lead to safety violations that, in turn, can trigger a temporary shutdown of the facility -- and in serious enough cases, a longer-term suspension of the plant's license to operate. This scenario is a financial, as well as operational nightmare, for every day in which no energy is produced is a day in which no revenue is being earned; all potentially because no one took the time to determine what would happen if the critical safety information was not properly and systematically maintained.
2. Prepare the safety nets
The second step is to develop a firm grasp on where your information is hosted, who's responsible for it and what happens to your business processes if it goes away. In this era of mobile applications and the cloud, much of what you need lives "out there," rather than "in here," and thus is under someone else's control. Although most organizations do a decent job of addressing the likes of guaranteed uptime and disaster recovery before signing a service-level agreement, many don't think about what could happen if their provider actually goes out of business -- which is a shame, because this, and things like it, happens often enough to be problematic.
For example, about one-third of the IT leaders responding to a recent IDG QuickPulse survey said they had licensed a software as a service application from an outside vendor that did not meet its expectation for application support. In such cases, actions taken included finding a tactical solution until a long-term strategic solution could be put in place, building in-house solutions as workarounds, transferring the workload to another vendor and filing a lawsuit against the offending provider -- all expensive outcomes and a legal case unlikely to result in any kind of make-good.
The time to think about this is before you sign a service contract. Do you receive regular backups of the critical information your provider holds for you? Is there a mechanism in place by which you can retrieve that information yourself should the provider's staff suddenly disappear? Is there a provision in place that says the service will continue to operate for a specified period following a closure or a merger?
3. Build departmental bridges
BPM, information governance and the cloud are each so complex that the quest to get them right often leads organizations to deal with them individually, rather than as connected parts of a unified whole. In addition, BPM and the cloud tend to be the bailiwick of the IT staff, while infogov -- where it exists at all -- is typically the responsibility of records, legal or compliance professionals. So, it's no wonder that business process concerns about retaining data so often are dealt with separately.
The answer is to build bridges between these departments, so you can manage your information in sync with the process needs of your business units and support the entire effort with an infrastructure that also directly aligns. Failing to do so only sets you up to incur unnecessary computing costs and compliance-related transgressions. And there's nothing funny about that.
Data retention policy best practices
Compliance-ready records retention
Keeping track of IT assets