Policy Data Management in 3 Stages

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

I’m in the middle of doing a proactive audit program reinforcement effort (unbelievably, they do exist ), and I just completed overhauling the organization’s policies, so since that’s top of the brain for me today, I’d like to talk a little about policy management.

In my mind, a good policy is the glue that holds governance, risk, and compliance practices together, and crystallizes the process to an auditable format. As a data professional, once again you can really add value here to help your business users stay in control of their policies.

What is a Good Policy?

To put it into perspective, let’s take a look at where policies fit into the governance, risk, and compliance domain. If you’ll remember, the basic relationship between strategic goals, risk, and compliance is this. Strategic goals help the company obtain its strategic objectives. Governance is making sure the strategic objectives are being accomplished. These objectives have risks, which are uncertainties about what lies in the future, which will prevent your company from attaining its strategic objectives. Risks can also come from other parties (e.g. the US Government) that are concerned about the effects your strategic goals might have on its concerns (e.g. the investing public). To mitigate these risks, controls are put in place, and making sure these controls are being followed is compliance.

Now, think of a good policy (emphasis on good) as a document that clearly spells out your governance, risks, and compliance implementation in clear and unambiguous language, with step by step procedures that integrate the tasks necessary to accomplish both the strategic goals and the compliance activities. This is a document worth keeping track of!

Your company will have its own way of constructing policy, which you should become familiar with. Ask one of your business users to show you a policy document so you can study it. Pay attention to the section headings, and the way things are organized and itemized. As stated, not all policy formats are the same, but I’d like to extract some common section headings to set the stage for our policy management architecture.

• Purpose / Introduction. As you might expect, there’s usually a section that introduces the reader to what the policy is all about.
• Revision History. As its name implies, this is a record of all the changes that have been made to the policy, who did it, and why.
• Policy. The policy itself should be a general statement about what your company’s position is on certain details. It calls out your company’s goals, highlights the risks, and clearly spells out how those risks will be controlled. If the control is imposed (i.e. from a regulation), the source of the control should be available here. For instance there might be a policy that states, “It is our policy that expenses over $5000 shall be approved by a Vice President.” This is obviously a policy that controls for some sort of risk, which should be spelled out in the policy as well.
• Definitions. A good policy document will have definitions defined.
• Procedures. These are step by step instructions for how a process should execute.
• Evidence. Your company’s policy format might have an Evidence section, which outlines what sort of evidence or documentation you should expect to see as a result of this procedure.

Evolving the Policy Management System

When designing and / or implementing any sort of architecture like this, I’m a big proponent of starting with the simplest thing possible that can add value, and evolving from there. Consistent with that philosophy, I’d like to suggest these 3 stages to the effective design and architecture of your policy management system.

Stage 1 – Document Store

The first stage should be a simple document store. Create a simple database table that looks like this:

• POLICIES
  • POLICY_ID – Unique identifier
  • POLICY_DATE – Date policy was uploaded
  • POLICY_NAME – Name of the policy, should include version number
  • POLICY_DOCUMENT – A scanned image of the policy

This should be a piece of cake, and it will immediately add value to your business users. Anytime a policy is created, it’s scanned into the database. Do not try to over-scope this, as it’s an easy trap to fall into. Just keep it simple, and deliver it quickly.

Stage 2 – Structured Policy Management

In stage two, you evolve into a database that contains the text of the policy, and handles change management a little better. Remember, this is an evolution, so the original table still remains. The scanned policy is still very valuable –why get rid of it?

The new table will have more fields, based on the format of your company’s policies. For instance, you will have a PURPOSE field and a REVISION_HISTORY group of fields. Consider indexing the PURPOSE field for searchability, as this is a good place to find keywords about the policy. For REVISION_HISTORY, make sure you separate out who did the update, when they did it, and why they did it ( i.e. VERSION_NUMBER, REVISION_DATE, REVISION_WHO, REVISION_DETAILS  ). The POLICY_NAME should now stay the same through different versions of the policy, so you can quickly query policies. You may consider a CURRENT_FLAG to indicate the latest version of the policy. Another strategy is to keep revision histories in a separate table.

POLICY, PROCEDURE, DEFINITION, and EVIDENCE fields should be broken out into separate detail tables. They will contain itemized lists that you want to capture in separate detail table rows.

Stage 3 – Integrated Policy Management

This is where you really start integrating your policy management system into your larger compliance data system architecture. In the spirit of evolution, I suggest you take baby steps within this 3rd stage of development, taking small wins where you can.

Consider these ideas for integrating your policy management system:

• There’s a great leverage point between your procedures and your Automated Process Auditing system. Your policies set the stage for assertions which can be tracked during an audit. In the example above the policy was “It is our policy that expenses over $5000 shall be approved by a Vice President.” You could model this into a test that’s tracked through the execution of this procedure.
• You can abstract the people in the equation (i.e. person making revision to policy) into roles, and tie the actual person making the change to your HR management system. If you’ll remember in How To Keep Dead People Out of the Database we discussed some ways of avoiding an embarrassing situation where the auditor discovers people making changes to the database that shouldn’t be (i.e. somebody who has left the company, or worse yet deceased!) This is a good place to tie into that architecture.
• Definitions are a good place to start a data governance effort. Build a data dictionary of terms, and empower the users with good data governance strategies. You can then leverage your data dictionary to all areas of the compliance data system, not just policy management.

These are just some ideas. I’m sure once you get started, you’ll come up with a lot more ways to leverage your new component of the compliance data system. Good policy management is another great way for your business to demonstrate effective control over processes and procedures to an auditor.

Take some time today to understand your company’s policy format, and build a simple database like the one I described in Stage 1. It shouldn’t take long, and it will add a lot of value to your businesses compliance operation.

...read the article on ToadWorld

Comments

[Chip Council]

This is a great post. I am going to link to it. :)