Who owns compliance?

For some weeks now on the ISO27k Forum we've been vigorously and passionately debating whether an Information Security Management System should, or should not, include the organization's compliance with "information security-related" laws, regulations and other obligations such as contractual clauses specifying compliance with PCI-DSS.

The issue arises because:
  • The relevant infosec compliance section is tucked away at the end of ISO/IEC 27001 Annex A, which has an ambiguous status with respect to '27001 certification. Although Annex A is discretionary rather than mandatory, certifiable organizations must use Annex A as a checklist to confirm that their ISMS incorporates all the information security controls necessary to address the information risks within scope of the ISMS. Interpret that paradox as you will ... and hope that the certification auditors take the same line;
  • It could be argued that, in a very broad sense, all the laws, regs, contracts, standards, ethical codes etc. which apply to the organization are "information security-related". The requirements are all forms of information with associated information risks. Therefore, they fall at least partially within the remit of an ISMS;
  • Likewise, "compliance", as a whole, could be seen as an information security control, a suite of organizational activities and measures to both satisfy and be able to demonstrate conformance with requirements, plus the associated assurance, reinforcement (awareness, acceptance) and enforcement aspects. In philosophical terms, compliance is an integrity issue, and integrity is part of information security, therefore compliance is part of infosec; 
  • However, most organizations either fail to identify and manage some of these risks and opportunities, or choose to manage them in other ways, for example through Legal and Compliance or Internal Audit departments. In practice, compliance with, say, the accounting and tax laws, or the health and safety regs, falls largely to the respective departments, teams and individuals who specialize in those areas. There is limited involvement of the information risk and security pro's, for example advising on the need for integrity, access and backup controls for the financial systems. In the event of conflict among the specialists, issues should be escalated to management, hopefully without blood being drawn, even if heads need to be knocked together to get things resolved.
The “mandatory ISMS documents” paper in the free ISO27k Toolkit draws distinctions between documentation that is:
  1. Formally and explicitly required by '27001 - the documentation that is clearly mandatory for certification, reading the standard as strictly as I guess a lawyer might read it [IANAL!]; 
  2. Informally implied by ‘27001 - additional evidence that, in practice, is typically used to demonstrate to the certification auditors that all the standard's requirements are fully satisfied;
  3. Potentially required by the organization, not by the standard as such, to direct, operate and control the ISMS according to business objectives.
    At one end of the scale, the ‘keep it simple’ approach to designing and implementing an ISMS emphasizes (1): if ‘being certified’ is the prime focus, the purpose of having an ISMS at all, then doing the absolute bare minimum to achieve that with as little as possible of (2) and (3) helps achieve that specific aim as quickly and cheaply as possible. The end result, as I see it, is a minimalist ISMS that satisfies the standard but only just. The business value to the organization arises more from having the compliance certificate than from the ISMS itself. For some organizations, that’s good enough, job done. Well OK it's a starting point: it may evolve from there.

    At the other end of the scale, the pure ‘business-driven’ approach emphasizes (3): regardless of what the standard demands or expects, the purpose of a business-driven ISMS is to support and enable the business to manage its information risks and security controls. The end result, as I see it, could be a bloated ISMS, bigger and more complex than the minimalist version.

    There are risks associated with both approaches:
    • An extremely minimalist ISMS might run into trouble with certain certification auditors who interpret the standard differently and hence demand more of (2) and (3) than what the organization believes it needs to do for compliance. It also might not earn its keep and fail, for example if the compliance certificate turns out to be an asset of little value, perhaps even a liability if the limitations of the extreme minimalist approach come to light. It could be a dog!
    • A bloated ISMS might experience conflict between ‘doing what’s best for the business’ and ‘doing what is demanded by the standard’, and hence might not be certifiable. Being bigger and more complex also implies greater risks: the ISMS might lose focus and direction. It too might fail. It could be a monster!
    So, personally, I prefer an approach part way between those extremes: do whatever the standard requires or implies, plus whatever extras suit the organization’s objectives and can be justified on business grounds. It seems to me a pragmatic ISMS should:
    • Sail through the certification audit, since it more than satisfies the mandatory requirements; 
    • Exploit the sage advice offered by '27001 and other standards (ISO27k plus whatever); 
    • Exploit and supplement/support the expertise elsewhere in the organization, building effective working relationships with assorted experts and managers on compliance and other matters; 
    • Incorporate joint rather than sole control in areas where the ISMS scope overlaps other functions, working collaboratively together towards shared business goals, addressing the bigger picture (a governance issue); 
    • Have a long-term future, since it also addresses broader business objectives relating to the systematic management of information risk and security; 
    • Do all that in a businesslike manner - cost-effectively, with strong governance and priorities that align with the organization's objectives and values. 
    Business alignment is, as I see it, key to the long-term success of the ISMS and, naturally, I have plenty more to say on that!

    For now I'll end by mentioning three other specialist areas that intersect the ISMS scope: IT, risk and business continuity. The issues are much the same as with compliance.