Compliance

The first question in compliance is typically WHO is owns compliance?


Is it the head of the legal department? The CIO? The Line of business GM? The CEO? Or the Chief Compliance Officer (CCO)? You might jump to the conclusion if there is a CCO and say it is them, but then you would only be partially right. More on this later.

The second question is to what regulations does the organization need to comply?

Well there are over 10,000 regulations worldwide and depending upon where your organization does business and what industry they are in the response will be different. Some common answers might be:

SOX, SEC17a, HIPAA, GLPA, PIPEDA or J-SOX.

The third question is what data is subject to the regulation?

This question might seem trivial at first but it can be one of the most complex questions to answer. Generally the regulation will spell out the data subject to regulation. What if multiple regulations are applicable to certain data? If 'ALL" data in a class is subject to a regulation then life gets easier, but what if only certain data within a class of data is needed? For example: CEO communication (email or power point presentations) may be subject to both SOX and SEC regulations that have different requirements.

The fourth question is what is required to comply?

A policy should be established that answers this question, otherwise the process to comply will be difficult to enforce. A typical policy might be "certain data (email) must be archived and retained for some period of time (7 years) and accessible to eDiscovery in a reasonable period of time at a reasonable cost and then once the retention period is past the data must be expunged from the archive."

The fifth question is can the organization develop a process and a system to adhere to the policy that was defined to meet the requirements of the government regulation? This question has both technical and social angles. First, can IT capture some data and then retain it and then as some defined time get rid of it? The second and more problematic problem comes in when Records Managers and IT staff sit down and discuss this issue. The problem is nomenclature and intent. You see IT is tasked with providing a service, but they are measured on: 1) did they deliver the service by a certain date 2) were then on or under budget. They gain informal power by not putting all the cards on the table. So the meeting typically goes like this.

RM says to IT we need to meet this rule and keep this data for some period of time. And IT says no problem. RM says I need to audit the process and verity that it works. IT says no problem (knowing that RMs have no earthly clue on how to do this outside of their paper world). So the meeting ends and everybody thinks it was a success. BUT since RMs are not use to defining their requirements in terms that IT needs, IT ends of taking liberties in meeting the specs. For example data that needs to be retained for 5 years can put on a magnetic tape (LTO-4) and stuffed in a closet. And the IT staffer can post a meeting note to destroy the tape in 5 years and presto they delivered what they said and under budget that can now be spend on something cool like VM technology. You see the RM didn't specify any SLA terms around recovery time. A year later when the RM goes to IT and says I need to verify your process, IT produces a vizio drawing showing a line going from the application to the storage system and then to the tape library and presto they are done. Once again both parties are happy, but something is seriously wrong. What if users actually deleted the files from the storage system because the WORM requirement wasn't provided to IT? Anyways the point is that it would be wise to have a cross functional team to define the requirements, process and SLAs. And it is always helpful to have some industry best practice documentation. Also you might appoint one IT person to be the advocate of the RMs and measure them differently.

The sixth question is how much does it cost to comply?

This is one of those 7 headed dragon answers...depends upon a lot of things.


The seventh question is what is the penalty for not complying?

In reality this should be question #2.

The SEC fined Morgan Stanly $15M and that is one of the biggest fines to date. ( http://www.ediscoverylaw.com/2006/05/articles/news-updates/morgan-stanley-to-pay-15-million-fi neto-

settle-ediscovery-charges/)



The eight question is WHO cares?

The answer is the same answer as question #1. I met with a bank that had a trading arm and one of their VPs commented that the cost of compliance would be many multiples above the largest fine levied in their industry. Based upon that factoid the and the low risk of getting busted they decided that although compliance is a good thing it was not what they were going to do. Their shareholders would be much better off if they didn't comply and got busted by the government every year many times.

So although Compliance is a hot topic in the media the reality is Compliance is all about RISK. Not technical risk, not compliance risk - just plain old business risk. And if RISK can be structured it can be managed. And this logic is the norm not the exception. Until the toothless lion (aka government oversight) gets replaced not much will change. Having said that many companies are concerned about good governance and actually do a good job implementing a good solution.

Back to question #1 - who owns compliance? In reality the question is usually who is responsible for compliance. There is a difference between responsible and ownership. Which is why it is typically a good idea to have a cross-funcitonal team of the previous mentioned roles and make them ALL owners, otherwise you get the politics. And unless the CEO and CFO and BOD recognize the RISKs of compliance and assign a budget, the typical shell politics will be played.

Governance

The Chief Compliance Officer (CCO), CIO, VP of Legal or some other senior executive is generally deemed responsible for deciding what data is important to the organization and establishing policies for managing that data over its lifecycle. Governance requirements are simply those retention/disposition requirements that are not mandated by the government but are internally imposed, generally as part of best practices.

Generally it is easy to decide what needs to be retained. Data such contracts, customer invoices, financial records, customer lists, hr employee records, etc. Once this decision is made there are two big problems to deal with and they are deciding upon the retention duration and disposition execution.

Retention is simply how long to keep a class of data. For instance how long should an employee’s HR record be kept once the employee leaves the organization? How long after the execution of a contract does it need to be retained? In some cases there are government regulations or industry norms to follow and in others it boils down to a benefit versus cost versus risk equation. Email is by far the thorniest of all content to decide retention a retention period.

The second problem is how to enforce the retention policy with data disposition. Courts frown on corporate policies that are not consistency enforced. If you are not using an archiving system with retention and disposition automated capability this is a thorny issue. How will IT capture, monitor and execute the policy? How will the records management staff validate that the records management policies are being followed? It has been my experience that this is dialogue is like having a classical music critic talk to a rap artist. Even through they CAN speak the same phonetic language they CAN’T understand each other – and this is one of the tar pit issues that corporations are neglecting to address.

The organization’s policies for retention, disposition and legal hold need to be understood PRIOR to buying an archival storage system. This requires getting the stakeholders and implementers into a room and hashing it out. Many times in my career I have been called by customers after they purchased something asking why they can’t do a particular task with their 6-9 month old archive system. For example most archival storage systems enable the setting of retention at either the archive, volume or directory level. Therefore, ALL files in that container have the same exact identical settings.

Buyer Alert: The question to ask the vendor is whether the retention clock is triggered by the original file create date attribute or the date when the file will be ingested into the system. If the retention policy is 7 years for a class of data and the file is 5 years old when the new archive system is installed the remaining retention time is 2 years. Thus if the archive system manages retention based upon ingest date it should not be comingled with new files in that class of data. Rather a second archive, volume, etc needs to be setup with retention of 2 years and one for 1 year, etc.

How to manage this issue needs to be taken into consideration when planning the migration of the data from the legacy system to the new archival storage system. Can your migration project apply filters to data so that based upon the filter policy it gets directed to different target locations?

Just because Governance Rules are internally decreed does not mean that adhering to them will be easy. Therefore it is advisable for the person or group that is responsible for establishing the retention policies to publish a draft proposal. Then have a candid discussion with IT and other stakeholders as to the practicality of executing the policies prior to publishing the final policies.

The Bucket List

It is a ritual around our house, on your birthday you get measured and it gets recorded. Today is my son’s birthday and he grew 3 and 5/8 inches in the past year, which in absolute terms is his largest year to year increase. Tomorrow is my birthday and I guarantee that my height didn’t change. But then again the metric that is important to me is my weight, not my height. This just serves as a reminder that not all data is of equal value.

This leads me to the "A word" and the topic archiving. It cost real money, in terms of both CAPEX and OPEX to archive data so the decision should not be made lightly. We know that some data has real value and needs to be protected. We also know that other data has no value and needs to be purged. And there is a lot of data in between. So this begs the question of how should an organization categorize their static data? I tend to put non-production data into one of the following five buckets:

1. Clear Business Value
2. Governance Mandate
3. Compliance Requirement
4. Deer in headlights
5. No value

By far the simplest item to deal with is the data has no value. Common sense would suggest that .MP3, .MOV, .FLV; etc files don’t belong in a long term archive unless perhaps you are an entertainment company. Three years ago I was in NYC meeting with a company thinking about implementing an archiving strategy. We scanned their shared network storage and applied a filter that only looks at files not accessed in the past 18 months. They were surprised that over 2TBs of these personal entertainment files were being stored on enterprise class NAS despite policies against this activity. Good news is that their problem is easy to fix, just follow the steps below:

1. Establish and publish policies giving people a timeline to adhere to them.
2. Work with the groups that have valid reasons to save audio and video materials to store them in designated areas.
3. Enforce the policy on a quarterly basis. If you don’t enforce policies nobody will adhere to them, including others in IT.
4. Establish a feedback loop by reporting aggregate level details to management on a quarterly. After all you are reducing expenses and improving efficiency.

Political and personal landmines can be avoided by asking yourself "who gives a crap" about the impact of what I'm about to do. For instance you don't want to delete the VP of PRs audioboos without giving them plenty of notice otherwise you could find your being called a lot of "A words" and your IT career on a fast track to doing thankless tasks like monitoring a long data migration project.

In the next blog posting we will continue to deal with the remaining bucket list items.