CA Community






This Blog

Authority Documents: How to Use Them to Guide Compliance

Published: October 06 2009, 05:15 AM
by Bob Brown

The first step in compliance is to understand what we are complying to. When we say that we are “complying," we are saying that we are fulfilling the authoritative requirements that our organization is mandated, or volunteers, to follow. These authoritative requirements can come in the form of regulations, principles, standards, guidelines, best practices, policies, and procedures. These requirements are usually captured in an authority document. The good news is that most authority documents are available online, so access is simple. The bad news is these documents are sometimes difficult to interpret. Sometimes the information is vague or ambiguous (this seems to be especially true for regulations). Sometimes the same information is restated in multiple places in the documents, leaving you wondering if the authors really meant it to be the same or different.

So the first step is to locate the authority document. Once you have a copy of the document, you are ready to identify the specific requirements (these are the “Thou Shalts" and what you are complying to) that impact your organization. But before you do that, it is important to understand the authoritative source's interpretation of key terms, because you will find that some authority documents will use the same term to mean different things, and other authority documents will use different terms to mean the same thing. Most authority documents begin with some type of glossary where they define the key terms that they use within their authoritative document. Make sure you understand the author's definitions before you move on to the next step.

Now that you understand the definition of the terms used, you can begin to read the document to cull out the specific requirements. You should read through the entire document, looking for the action items that the authoritative source is mandating. The process of identifying requirements is more art than science. Look for action words such as “create", “implement", “identify", “control", etc. In addition to capturing the compliance action, you should note the citation information. In most cases, if an authority document is updated, the authoritative source will call out what citations have changed. Having this information captured in the beginning will make it easier to determine if the change will impact your organization.

At the same time as you are determining the requirements, you will want to identify what the authoritative source considers as evidence that you are adhering to the specific requirement. This evidence eventually becomes your controls. In its simplest terms, a control is a process/procedure designed to provide reasonable assurance regarding the achievement of a specific requirement. A control can be automated, manual or a combination of the two. The process for abstracting control information is a subject for another post. For now, you will want to note the citation containing the control requirements.

There are many resources available to help you abstract the requirements from authoritative documents. The first resource to check is through the authors or editors of the authority document in question. They might have additional information that helps clarify the source document. You might also want to check with your internal and external audit organizations. They would belong to audit groups and would be able to share what they are being told to examine, test, and whom to interview when checking for compliance. Industry groups such as ISACA and OCEG have resources available to its membership. You can also check out publishers like Compliance Week which provides compliance information on a subscription basis. If you want to take it beyond requirements, Unified Compliance Framework (UCF) provides a database of controls that are mapped to large number of regulations, standards and guidelines.

Abstracting the requirements contained in an authority document is just the first step of compliance but it is critical to get it right. It lays down the foundation and like building a home on a faulty foundation, missing or misinterpreting a requirement could lead to big problems down the road.

 

By: Bob Brown
Bob Brown has 20+years experience in the IT arena, working in application development, computer operations and product development and even did a short stint in HR. In his current role as Sr. Product Manager for CA, he is responsible for working with his customers and understanding their requirements...
Read More..

Comments:

No Comments

Leave a Comment

* An asterisk indicates a required field

* :  

:

* :  

 Submit