News Stay informed about the latest enterprise technology news and product updates.

The importance of risk management in IT compliance

This is a guest post by Cass Brewer, the founder of Truth to Power Association.

John Rostern recently blogged here about the dangers of checkbox compliance, noting that regulatory compliance doesn’t always bring information security.

I’ll take that argument a step further: Especially in terms of PCI DSS, most companies might get better ROI and comparable outcomes if they simply lied on their PCI DSS self assessments and returned to sprinkling salt around their servers, or whatever (apparently) prevented system breaches before PCI DSS came along. As John so aptly notes, siloed, point-in-time compliance is generally inadequate — in terms of both control and cost.

Unfortunately, external mandates tend to pervert otherwise healthy plan-do-check-act operational strategies. In the rush to comply with regulatory panaceas for perceived pervasive risks, managers too often deprecate their own informed risk judgments.

This is a backward response. Enterprise risk management should be both an input and output of any compliance program. As an input, it lets managers “just say no” to immaterial audit recommendations, defines implementation priorities and ensures that relevant controls aren’t displaced by compliance checkboxes.

Management can operationally parse broad compliance requirements by aligning control responses with actual material and significant risks. Or it can limit the in-scope environment of specific controls to particularly critical or sensitive information: cardholder data, customer PII, systems logs, etc. Either way, the bulk of risk management should occur on the front (planning) end of compliance. The risk management output of compliance programs is generally limited to risk mitigation.

Defining and measuring risks up front is also a cost-containment strategy. Under the Sarbanes-Oxley Act and other rules, organizations can exclude irrelevant “compliance” activities aimed at immaterial and insignificant threats. Of course, concrete documentation (and lots of it) is the key to defending such exclusions against auditor challenges.

Risks characteristics including existence, criticality, likelihood and period can further hone appropriate control responses. If a particular risk arises only once a year and potentially impacts just one disconnected system, a siloed, periodic response might be adequate. Of course, most risks are more constant and/or pervasive. Control efforts should respond to those characteristics, hitting compliance goals incidentally.

A risk management approach to compliance has opportunity benefits, too. It’s difficult to measure risk value (or risk abatement value) without understanding business-process value. In many cases, key risk indicators (KRIs) are complements to key performance indicators (KPIs). Defining one provides a base line for defining the other; and that base line is, in turn, a costing base line that supports more broadly strategic business decisions.

How does this work? Learn how to factor risk management into compliance assessments at

Cass Brewer is the founder of Truth to Power, a free and open research community for better information governance. At T2P and in her previous role as director of the IT Compliance Institute (ITCi), Cass has worked with thousands of compliance, audit, business, and IT leaders to develop practical guidance for corporate compliance and risk management. She can be reached at

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Compliance is like being at all the rehearsals with a sharp pencil and playing your part perfectly - but not showing up to the gig. The problem is speaking plain language. Risk is not something that can be measured or estimated as the ERM systems would have us believe, risk is a dependent function of threats exploiting vulnerabilities in assets (which are worth money) less the mitigation of countermeasures (which cost money). I think that the security and compliance industry is approaching the point of a huge 10X change in the way business is conducted - the great financial crisis is proof that regulation doesn't work - i.e. that you can be formally compliant or sign off on client compliance (if you are an auditor at the Big 4) and not be punished. The first sign of any 10X change is a lack of clarity in my experience. When bad things happen, the first response is to find a rational explanation or political excuse. When a PCI-compliant institution loses PII in a data breach - this is the sort of thing we hear: 1. Compliance doesn’t require DLP technology, we need a product from (Verdasys, Fidelis Security Systems, McAfee or Symantec), then we can prevent data breaches in the future, or - 2. Some of the systems that interface with our business partners and payment processors are vulnerable to exploits (we were compliant but the other guys weren’t) or, 3. Our business process outsourcing vendor violated his non-disclosure agreement or, 4. At the time of our last PCI audit, we WERE compliant - but in the meantime, our marketing team installed a Microsoft Sharepoint application that was vulnerable to hackers, 5. Someone put some nasty spyware in our cash registers that were on the store WiFi network, 6. We’re working on encrypting all our credit card data and then it won’t happen again, 7. We’re upgrading our head office servers to Windows 2007, some of the Service Packs were not applied 8. We’re using an old version of Linux - Red Hat 4 - since our application vendor requires that version - we didn’t realize that Linux was vulnerable to Oracle database exploits It seems to me that we are at / or approaching a strategic inflection point in the risk and compliance industry. The compliance model is broken, data security/ERM vendors are adopting ERP style implementation models and pricing (pay me $1M for the software and another $1M for professional services for the implementation) but most of all there is a sense of confusion from reading the vendor collateral. Read what IBM says on their “Data Governance” (Whatever that means) page. If you understand the gobbledygook they write - drop me a note at Danny Lieberman [A href=""]Software Associates[a]