How does this work in regards to calculating risk-based compliance? As a brief example, let's consider one of the trickier compliance-value connections: information security's value to business operations. Here's a conventional information security risk equation:
A more complete risk equation also considers the operational value of information on the system:
+ Revenue value of system operations ($/period)
+ Business value of system availability ($/period) + User hours * User cost/hour ($)
And factor in degradation of information assets in the case of an information breach:
+ Business value of information confidentiality ($)
+ Business value of information integrity ($)
And, finally, liability costs associated with public notification of data loss:
+ Legal costs + Litigation costs + Potential regulatory penalties ($)
+ Labor costs + resource opportunity costs + forensics and other service fees ($)
+ Customer communications + credit monitoring + other remuneration ($)
+ Stock devaluation -- generally 1.5% to 5% over at least six months ($)
(As a side note, one incidental benefit of virtualization is the challenge it poses to the calculation of risks based on individual computer costs. Since a single machine may contain parts of many processes or just one part of a larger process, risk managers will increasingly be forced to valuate IT processes in terms of the business processes they support, not the information systems they run on.)
Note that some of the additional factors I mention above are business risk equations. Revenue value of systems operations is a KRI; however, the value of those operations is derived from KPIs tied to the business process that the system supports.
This is a simplified example, of course. The risk and business intelligence required to quantify factors such as operational risk or the confidentiality value of information can be magnificently complex -- more complex than regulatory deadlines might allow. Managers can still derive a general sense of KPIs and KRIs by using specific business-case models and analyzing existing data from transactional and source systems.
While you might not want to base major business changes on such limited case models and limited data sources, the results of even broad-stroke risk analyses can be sufficient grounds for intelligent, risk-based compliance scoping.
If a particular scoping decision seems questionable based on known risk characteristics, management can decide whether further analysis or simply moving ahead with an indicated control is a better use of organizational resources. Either response would still be an improvement on checkbox compliance.
Cass Brewer is founder of Truth to Power Association, a research and advisory community that lets business, IT, audit and legal professionals collectively improve individual corporate governance, risk management and compliance practices. Let us know what you think about the story; email: email@example.com
This was first published in January 2009