Building an IT Control Library
- Written by: Dave Nelson
Mapping IT control objectives to specific standards or regulations is a daunting task. I’m currently working with an organization who wants to build their information security management program around the ISO 27001 and 270002 standards. On top of that they want to ensure compliance with Payment Card Industry – Data Security Standards (PCI-DSS) and Sarbanes-Oxley (SOX) at the same time.
In case you are wondering, there isn’t a 1:1 mapping for any of these standards and regulations. While the ISO standards are high level guidance, PCI gets pretty far into the weeds. There is however quite a bit of overlap.
Access controls is a good example. Each of these standards requires that users can be uniquely identified. A good beginning control for an organization could be something like this. “Each user of an information system must have a unique userid assigned to him or her.” This could then be placed in the organization’s control library and several compliance objectives can be satisfied and mapped to this one control. PCI may go deeper and require additional controls where the others are satisfied with this one control.
One of the problems is the sheer number of controls an organization will need just to satisfy one or two compliance frameworks. One could easily document 200 or more controls and only scratch the surface. As you are building your control library pick controls that are broad enough to encompass as much of the compliance requirement as you can. This will help limit the volume of control statements thus the amount of testing required to verify control effectiveness.
It’s important to remember that an organization may choose to implement controls in excess of the compliance requirements in order to reduce risk to levels deemed acceptable by business unit leadership. In this instance it is imperative that the risk and compliance teams clearly delineate these controls as out of scope for an audit.
Be careful not to let this become a “check the box” exercise. Developing controls should be done to mitigate risk first. If done correctly, adding controls to satisfy compliance objectives may not even be necessary. After all….PCI, SOX, HIPAA…weren’t they designed to mitigate risk?
