In a previous blog post, I outlined the relationship between information security and information management, making the case that there’s a direct correlation between how well you manage your data and how well you can protect your business.
Essentially, good data security powered by effective data management has an impact on every area of a business. When you look at security through an information management lens, not only is your vulnerability footprint smaller, you end up with a more productive and efficient set of business processes.
But how do you actually go about integrating information management and information security? How do you reduce your risk surface?
Doculabs recommends these five steps:
- Analyze and understand your information.
- Build policies and guardrails.
- Create a Center of Experts.
- Tackle the low-hanging fruit.
- Engage in full-on cleanup.
In this post, we’ll take up the first two steps in detail.
Analyze and Understand Your Information
When I wrote about the overall importance of cleaning data, I pointed out how the first step you should take revolves around understanding and analyzing the information you currently have. This is where you look at risks and figure out your greatest areas of vulnerability, from the perspective of your data and the content across the enterprise.
This analysis should take into account three key things:
- Whether your organization is undertaking a data migration (e.g. to Office 365 or to another ECM system)
- The kinds of rules by which your organization currently manages its information
- How your information management effort aligns to corporate priorities
If your organization has well-established rules regarding data governance (e.g. emails automatically deleted in 90 days, unless otherwise flagged as records), you can use software to help restructure your information. Some products to consider are from FileFacets Inc. (which focuses on unstructured data), Nuix Pty Ltd, or Active Navigation, Inc.
Then there are file analytics solutions, such as those offered by Varonis Systems Inc., STEALTHBits Technologies Inc., and Veritas Inc., which can help you undertake a full content scan and identification process to help identify content within the file. (Note that the Varonis product is a broader, meta-data information management tool that’s more focused on duplication and insider threats. For our take on the current files analytics market space, check out Rich Medina's blog post, "Which File Analytics Product Should You Use?")
Build Policies and Guardrails
My previous post also mentioned building a set of guardrails, or policies, to help take action on the various types of data you discover in the first, analysis phase. Policies create a structure for your organization to take action moving forward. If you recently bought new ECM or security tools, reviewing and aligning your policies is essential for continued success.
Here’s where it’s important to understand the policies you already have in place. What is your records retention schedule? Do you know your legal hold process and strategy? How do you manage disposition and deletion?
It’s also important to have—or to build—a corporate data map so that you know where information lives. What’s the nature of your repository? How many systems work within one business function?
You then need to understand who owns the data. What are the business, IT, and legal implications if you change your disposition schedules?
Why You Need an Orphaned Data Policy
Speaking of data ownership, “orphaned” data is data that has no identifiable owner—whether from employee retirement or attrition, or the absence of information that would help identify ownership. It’s important to have in place a policy for how such data is to be managed—e.g. if your organization needs to keep data in support of tax filing for 7 years.
But for how long do you keep supporting information if that information has no immediate business relevance or value after 2 years? What happens to tax-related information in Years 3, 4, 5, or 6? Is that information a record? Is there a legal hold on the information? Can you keep that data in “dark storage,” in a stand-alone repository?
Note that you may have a scenario where data automatically transitions to dark storage repositories. The stored information exists—it hasn’t been deleted—but it’s no longer visible to users. From the user’s perspective, the data’s been deleted, but is still recoverable.
The Defensible Disposition Playbook
Good, clean data management relies upon having a defensible disposition playbook—the go-to source of the legal standards that either a data purge or a data migration needs to meet to be defensible, along with defined criteria, rulesets, test scripts, etc. (See my colleague Joe Shepley’s blog post on what constitutes an effective disposition playbook.) Because it’s not only what you delete, but doing so according to the appropriate schedule, and in a repeatable way that’s defensible in the future.
Walk through a set methodology. Build a policy and a repeatable process. If content meets Criterion X, you might review, say, two key factors: Is this a record? Is the information on legal hold? If the answer to both questions is “no,” then you can delete the file per policy.
A “yes” answer elicits a different response. It can be moved to an appropriate repository under the ownership of the Records Management or Legal folks, until those records are subject to deletion, per the corporate records management policy.
A playbook, bordered by those guardrails, explains how and when you delete information. It outlines a consistent process that can be applied across the information of an entire department, business unit, and/or enterprise. For organizations that have historically kept all their information, primarily because deleting anything was controversial or problematic for certain user groups. The defensible disposition playbook provides a defined, consistent, “keep-or-delete” framework for managing an organization’s information, demonstrating to anyone who asks—courts, regulators, or that user who’s been squirreling away draft versions of documents that went final in February 2012—that the deletion wasn’t a one-off action, but part of an enterprise policy.
In my next post, I’ll take up the last three items on our list of recommendations: the Center of Experts, addressing low-hanging fruit, and what’s involved in full cleanup. Until then, take a look at our white paper, “The CISO’s Six-Step Guide to Managing Application Risk,” which puts all these concepts into context.