Rules, Standards and Models

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in October 2009

Is there really a difference between rules, standards and models, and does it matter to IT governance? From 28-30 September I attended the ISACA Information Security and Risk Management Conference in Las Vegas. I shared my ideas on integration of the IT governance, risk, security and compliance functions. More importantly for this article, I had the time to attend presentations from other experts in the field. This gave me a number of new insights; “good stuff” for future articles. One of the presentations was titled “Harmonization of Standards” by Todd Fitzgerald. Todd is a well known figure in ISACA circles and I attended his presentation with serious expectations. As in the past, I was not disappointed. During his presentation Todd made one remark that stuck with me. He basically said that there is a lot of discussion about the difference between rules, regulations, standards and models and that in his opinion the difference was academic and of no particular interest in real life. I have seen a similar attitude with tool vendors. It is not uncommon to read claims like “tool X describes CobiT, ITIL, ISO 27000, SOX, PCI, etc.” or something to that effect. Basically I think that treating rules, standards, and models as more of the same is wrong and here comes the reason why. But first, to Todd: if I misunderstood your comment - my apologies.

These days organizations, including their IT departments, have to comply with a multitude of rules and regulations. Looking at the regulation ‘spaghetti’ allows three questions when addressing any (new) regulation:

1. What is the subject of regulation? For instance SOX is concerned with the financial information submitted to the Security Exchange Committee; PCI is concerned with protecting information regarding Credit Card transactions.

2. What are the compliance requirements? What is it I need to do, stop doing, control and/ or measure so I can claim compliance?

3. How does the regulator want me to assure compliance? For top level management to assure compliance with performance controls, it might be enough for lower level managers to fill out a self-assessment questionnaire. SOX, on the other hand, has very strict requirements for proving compliance; this includes sample-based testing of controls, internal and external audits.

The first question is important for a number of reasons. The subject of control will help us establish the primary accountability in the organization: if the financial data is the subject, the finance department would logically be accountable for achieving compliance; if data privacy of personal information is the topic of interest, the sales/marketing department might be accountable for customer information; if it concerns data privacy of employee data, it might be the responsibility of HR. The second example shows that regulation might apply to different types of data owned by different stakeholders in one and the same organization. Failure to answer the first question will have obvious consequences: without a clear subject of regulation it will be that much harder to establish ownership and compliance accountability. This in turn might lead to vague or non-existent business sponsorship for the effort to achieve compliance. Since almost all compliance efforts involve implementing unpopular measures and controls without clear sponsorship, any effort to achieve and maintain compliance can easily turn into an unachievable up-hill battle.

Furthermore if we do not know the subject of compliance the only way to ensure we cover all that needs to be covered is to apply our measures “across the board”. For a small company without the resources or organization to manage a differentiated control approach this is not an issue. But let’s assume a global corporation wants to do business in the middle-east. Within that region there are a number of countries that are the subject of stringent EU and US export regulations. If the organization has no idea which resources, processes, information, etc. are actually used in this region they would have no alternative but to apply all the export controls to the entire organization. This in turn would probable cripple the ability of the organization to conduct business competitively elsewhere in the world. Conversely, a properly conducted compliance effort can actually offer competitive advantages since it will allow the organization “to go and conduct business were the competition just cannot follow”.

Once we answered the first question the second question is ‘what are the compliance requirements?’ This is when the difference between rules and models becomes most apparent: rules set requirements. To keep the primary accountable satisfied we need to prove we meet the requirements. Trying to do so means that we need to design and implement a solution. For the design of these solutions we might use a model or best practice. For standards it depends on the way we use them. If a stakeholder decides it is important to comply with one or more standards (and maybe even get the compliance certified), the standard, in effect, becomes a rule. On the other hand we may want to use the standard as a starting point to achieve compliance with other regulations. For instance ISO 27000, as a standard, can be used as the basis of the IT General Control framework needed to achieve SOX compliance. In this example ISO 27000 implementation is not the requirement or goal it is just a tool to meet another goal.

The third question makes the difference between rules and models even more apparent. Use of a model should never be the goal, just the means to an end. The answer to the question ’did we meet the goal?’ will tell us whether we implemented the model correctly. For compliance to (internal or external) rules and regulations, however, it should be clear upfront how the organization is supposed to proof their compliance with the rules. As many organizations have learned, the assurance requirements for the regulations might lead to a different solution. SOX, for instance, has very strict assurance rules which includes sample-based testing in many cases. When sample-based testing is required it is often worthwhile to build automated controls where proof-of-control execution is automatically generated and stored for easy access by the control testers when the time is right. If on the other hand a management assessment is considered adequate assurance there might not be a business case for automating controls.

So, on the one hand, given the growing complexity of the rules, regulation, standards and models jungle out there it becomes more and more important to clearly split between the rules and regulations that tell us what we need to accomplish. On the other hand the models, best practices, examples, etc. can guide us in designing solutions that actually meet those compliance requirements/ goals.