It isn’t unusual for large enterprises, even in "unregulated" industries, to grapple with dozens of regulations involving IT governance, privacy and information security issues. Regulated firms, particularly those in financial services,
Many of these rules have overlapping requirements, with some even in conflict with each other when firms operate in multiple countries. For example, the U.S. and European Union privacy rules have different fundamental assumptions.
The big question is this: How do you build compliance programs that accommodate a world of ever- changing regulations in complex environments? Sometimes a new regulation appears to be focused on one department such as finance, but a detailed analysis of the requirements reveals that there’s an impact across several departments.
When it comes to compliance planning, the legal department usually takes the lead, with the IT department being an afterthought. But among more enlightened companies, IT is now being brought into the planning process much sooner. With this in mind, we offer a three-step approach to integrating IT responses to changing requirements:
• Catalog your regulations, framework objectives and IT controls as they exist today;
• Map requirements for each regulation to the framework objectives and look for missing or duplicate objectives;
• Map from framework objectives to IT controls and look for missing or duplicated controls.
These tasks can be simplified with a database of rules, predefined mappings from ISACA, larger audit firms and security vendors that offer mappings from frameworks to the controls built into the software.
With mappings established and IT controls in place, adapting to new regulations becomes a formulaic process of updating the catalogs and maps, rather than starting with a clean slate. This makes it easier to find and correct errors and update rules to reflect new policies. Establishing a repeatable process for compliance programs based on catalogs and maps saves countless hours when the rules change. It will pay for itself when the auditors can see where each requirement is met and measured.
In the chart below, we see a simplified mapping for a company that must comply with both the Health Insurance Portability and Accountability Act and the Sarbanes Oxley Act (SOX). In this example, we have focused on just a few of the requirements for each that deal with privacy and security. A careful reading of the regulations can facilitate manual production of a catalog of requirements, but tools are now emerging to do this work, such as those from The Privacy Place, a nonprofit privacy rules think tank. For most major regulations, it’s more cost effective to use a list from a vendor or service provider.
The center column lists some objectives from the Control Objectives for Information and related Technology (COBIT) framework available from ISACA. This is the most popular framework for SOX compliance, although others, such as the IT Infrastructure Library and ISO 17799, are often adopted for software development or security teams, respectively. Firms can mix and match objectives from different frameworks, but they generally select one to be their primary approach.
When it comes to compliance, legal usually takes the lead, with IT typically being an afterthought. But among more enlightened companies, IT is now brought in much sooner.
Finally, the right column lists specific internal controls that provide the results required for audits. Again, we show only a small sample, whereas a real installation may have hundreds or even thousands of such controls.
The key to this diagram is in the mapping among the columns. By thinking of the IT compliance problem as a mapping problem, one can ensure that all requirements are “covered” by controls. A firm can add more objectives than required for compliance. For example, additional ITIL objectives used to make project management or disaster recovery more efficient or effective.
By using this approach, complying with a new regulation is a matter of identifying the specific clauses that apply to your firm. You also gain assurance that all clauses are mapped to existing or new objectives. Once this is done, any new objectives must be mapped to new controls. If regulations expire, then a similar exercise can be used to identify out-of-date or unnecessary objectives and controls.
In application development terms, we are simply providing bidirectional mapping between requirements and code controls to ensure that the impact of changes to either can be seen quickly, particularly missing or redundant code.
Let us know what you think about the story; email firstname.lastname@example.org.
This was first published in November 2010