Our customers come to us with a dizzying array and variety of Information Governance challenges. Many customers have unique needs… for example, one of our European customers has asked that we help them govern specific set of physical records: prototype parts created by their suppliers and R&D division, and stored away somewhere in crates in a large warehouse. (After all, not all physical records are documents.) We've also been asked to provide a governance solution for CAD Designs, Audio / Visual Records, and multi-component records comprised of many forms and supporting documents (discrete records in their own right).

Although there are often unique requirements such as these, there is also a consistent set of challenges voiced by nearly every customer and prospect we visit. These include:

• Multi-jurisdictional policy development
• Repository-agnostic policy enforcement
• Cross-repository search and records access

A significant percentage of our customers and prospects (95% or more) tell us that at least two of these issues are high-visibility challenges they must solve in the next year. RSD GLASS represents a unique approach companies are using today to address these problems. Customers, partners, and friends of RSD already know this, so I won’t go into much detail today* on how we solve these Information Governance challenges. 

* - That said, if you are new here, why not take a look at our webinars and other resources. Lots of good stuff there.

Rather, there is a common request I am hearing these days, and I would like to take a moment to explore it in depth. The question goes something like this: “Can you help us govern our content on our network and file shares?”

Peel That Onion, Try Not To Cry

On its face, the requirement seems harmless enough. The organization has some "stuff" on its network, network-addressable storage devices, and local C: drives. They want to apply their retention schedule to it. Unfortunately, when I start asking questions, and they look at the problem a little more closely, they often realize there are some unspoken requirements behind this request:

1. Little-to-no disruption. They usually want to govern the content in place. After all, legal and business users know where to find things on the network. (Don’t they?)
2. They want to automatically classify content. This means scrubbing metadata (which is file system metadata, not record metadata) and document content to infer whether it is a record or not. If a given document or file is a record, classify it according to the corporate taxonomy of records, and apply and enforce the appropriate retention. This is an especially important requirement for customers who have a poor sense as to what records are on their network.
3. Once a document is declared as a record, they want to block attempts to edit or delete the record outside of our governance platform. That is, they want to prohibit a user or system administrator from accidentally (or not) modifying or deleting the record from within the file system itself.

At this point in the conversation, the innocuous little request to govern content on file shares is now revealed to be a much more complex problem than first thought. On the one hand, the customer wants to employ all the necessary governance controls to meet regulatory and legal obligations. On the other hand, they want things to be exactly as they are today. What's so hard about that?

“One Word Can Really Bring You Round – Changes”

 The complexity behind the problem is the same problem ECM originally was supposed to help solve: the network / file share environment is inherently un-governable, from a Records Management perspective. Without specific and potentially very costly IT project work and ongoing administration, the required governance controls to identify, classify, and manage records is simply not possible at a technical level. More simply, a document or folder on a network can be changed or deleted. A record residing on a network or C: drive is not immutable. If it is not immutable, it is not a record.

And the Court will not admit it as such.

So Can This Be Done?

Thankfully, there are solutions. I’ve already suggested the most common solution: ask IT to solve it. IT defines and administers a set of permissions that describe who can read / write / access various drives and network directories where records may reside. They then trust their users (or their chosen auto-categorization technology) properly classify records. IT then applies the appropriate retention periods to these records, using a very small number of categories. To help, the network directory may mirror the taxonomy of corporate records. Enforcement is manual, entrusted to the IT / Network Administrator who periodically purges records with expired retention periods. The Audit Trail is the network log.

I’ve met a customers who have taken this approach; a few can make it work. Cost and complexity of administering such a program increase exponentially as they incorporate more than a few record types, business units, and / or jurisdictions. It can only work in relatively simple, localized, highly-cohesive environments, whose records are rarely, if ever subject to e-Discovery requests or litigation holds.

Most of the companies we talk to don’t fall in any of these categories. The records environment is complex. They lack unlimited IT and network administration budgets. IT and Records Management do not always work in lockstep. They are in highly regulated or litigious verticals. Their needs make it impractical or outrageously expensive to employ network technology as the RM enforcement mechanism. They know this; that’s why they bring us in.

From our perspective, we prefer to take a step back, and examine this question as a business / cultrual one, not a technology one. We examine why they want to maintain records on the network. We remind our customers that, in all likelihood, much of what resides on the network is probably not a record. Then we focus on the small subset of documents that truly are records, and develop an Information Governance program that:

• Prevents the unwanted or unintentional editing or deletion of records
• Allows authorized access
• Automatically (if desired) enforces appropriate lifecycle actions, including declaration, disposition, and a whole host of intermediate actions between these milestones as required by privacy statutes and other policies
• Provides corporate counsel with defensible disposition, showing when, how, and why records were disposed
• Allows litigation holds to be placed on records, thereby freezing the lifecycle of potentially relevant records
• Maintains an audit trail of all actions

The specifics of how these benefits are achieved differ from one implementation to the next. It may be necessary to move records (or a subset of records) to a traditional repository that supports these types of governance controls. RSD GLASS includes a component specifically designed for providing business and legal users the secure cross-repository search and access they expect.

In other environments, the benefit of this kind of migration does not justify the cost of moving records. Instead, these customers ask us to leave those records in place, but still calculate and transmit lifecycle action messages that are then manually enforced by the relevant administrator. To ensure appropriate governance, we can require to manually verify that they have performed the required actions, and record this verification in the Audit Trail.

Often, we take a blended approach: migrating some records to be governed in a repository, and enabling manual governance on the remainder of records left on the network. The openness of our platform and repository-agnostic approach gives us great flexibility to architect the right solution. In the end, we can meet the needs and govern records currently residing on the network.

It’s just a little more complicated than it first seems.