In my last post, I talked about authority documents and the need to abstract the specific requirements as being the first step in being “compliant." Once we have identified the specific requirements that we need to comply to, we need to be able to provide evidence of that compliance. That is where controls come into play. In its simplest terms, a control is a process or procedure designed to provide reasonable assurance regarding the achievement of a specific requirement. Before we go any further, let's discuss “control objectives" vs. “controls." Often these terms are used interchangeably but we see them as distinct and you actually need both to be in compliance. Basically, the control objective is the what and why nature of the evidence. Controls answer the who, where and when. Generally control objectives are more abstract in nature. For example, if the requirement is: Establish a process to identify newly discovered security vulnerabilities, the control objective would be: Vulnerability identification. The control would define who is responsible for performing the identification process, what systems should be scanned and how often. Usually control objectives can be abstracted by somebody who understands compliance and does not need to be a subject matter expert. Defining controls usually requires intimate knowledge of the processes, assets or systems that are being “controlled." For the rest of this post, we will discuss control objectives.

As discussed last time, the authority document is the best source for identifying control objectives. Sometimes the authors are very specific about what they consider to be evidence of compliance. The Payment Card Industry Security Standards (PCI) provides detailed control information required for compliance. Sometimes you need to go beyond the authority document to identify your control objectives. For example, the Public Company Accounting Oversight Board (PCAOB) has documented many of the control objectives necessary for compliance to the Sarbanes-Oxley Act of 2002. Fortunately, it is only occasionally necessary to determine a control objective yourself.

Examining the specific requirement, you want to provide a clear context of what demonstrates the achievement of the specific requirement. No matter how you abstract the control information, you will want to note the source and citation of the control objective for your auditors and examiners. In order to abstract a control objective, each control objective can be broken down into two parts:

• the action or demonstrable outcome being called for (the basis of the control objective)
• the parameters associated with the action

So as an example, § 11.4 of the PCI Data Security Standards version 1.2.1 authority document states the following requirement:

Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines up-to-date.

So in building our control objective, the action would be:

Maintain intrusion detection and incident monitoring and response capabilities

And the parameters would be:

• For all traffic in the cardholder data environment
• Alert personnel to suspected compromises
• Keep it up-to-date

They key point about developing your control objectives is making sure that they are demonstrable. There are many resources available to help you abstract the information necessary for demonstrating compliance. The first resource to check is through the authors or editors of the authority document in question. Many of the authoritative sources have websites with additional information that helps clarify the source document. You might also want to check with your internal and external audit organizations. They likely belong to audit groups and would be able to share what they are being told to examine and test when checking for compliance. Industry groups such as ISACA and OCEG  have resources available to members, as well. In addition to doing the abstraction yourself, you can purchase control libraries. The Unified Compliance Framework (UCF) provides a database of controls that are mapped to large number of regulations, standards and guidelines. Once we have our requirements laid out and identified what we need to demonstrate reasonable assurance that those requirements are being met (our control objectives) we are ready to move on and take the next steps (designing and implementing our controls) in our goal of being “compliant."