That risky Annex A

Having seen yet another comment on social media this morning along the lines of "I'm petrified that the certification auditor will raise a nonconformity if we don't adopt specific Annex A controls", I've added an ISO27k FAQ under the assurance section.

This is one of the most frequent of Frequently Asked Questions, a frustratingly persistent concern relating to the natural anxieties about being audited.

I've been audited. I've been an auditor. Audits are challenging, stressful activities. I get it.

The FAQ addresses this commonplace concern as an information risk since, at its core, there is uncertainty.

We don't know, for sure, whether the certification auditor will or will not:

• Expect to find a nice neat selection of Annex A controls in the SoA;

• Express surprise or mild shock if various Annex A controls are not employed;

• Doggedly insist that specific Annex A controls are applicable and thus are 'clearly necessary' because ... because ... well because he/she says so;

• Suggest, imply, assert, claim or flatly state that the client's management must be totally incompetent, stupid, inept or plain wrong if they choose to accept risks "that everybody else accepts must be controlled" or prefers 'other' controls, even slightly-reworded versions of the Annex A controls or those from well-respected sources such as NIST, GDPR, CSA, ISACA, ISC2, FBI, CIA, NSA, IEC, IEEE, World Bank ... or indeed ISO itself, let alone fully custom controls, expressly specified and designed specifically to suit the client's particular situation;

• Misinterpret any of the requirements in any of the standards (27001, 27005, 27006, 27007, 27008, 17021-1 ...);

• Get the grumps if anything unusual, awkward, unexpected or time-consuming comes up, causing an adverse reaction ranging from 'a bit of a fuss' and extra intense auditing to a minor implosion with toys being tossed out of prams;

• Raise a nonconformity;

• Refuse certification;

• Prompt a load of re-work and a change of approach;

• Lead to additional expense and delays;

• Piss-off management who anxiously anticipate certification;

• Piss-off prospective clients, authorities or other stakeholders, causing business problems;

• Damage the company's reputation and brand;

• Damage the reputations and job prospects for those involved in designing, operating and managing the ISMS;

• Lead to a total global melt-down followed by supernova ...

Well OK, so I'm exaggerating just a little for comic effect but that crazy escalation mirrors the thought processes of people under stress, especially for those of us who are naturally risk-averse security pros. We assume the worst. We fear failure. We want our mummies.

The fact remains that this situation is a readily-forseeable information risk, one that can therefore be considered, analysed, evaluated and treated just like other information risks.

It's as much an opportunity as a risk - an opportunity to use the policies and procedures in the fledgling ISMS, reducing the stress and preparing to deal with the situation in advance, in your own sweet time rather than in the heat of the moment, in a mad panic.

The FAQ suggests a dozen risk-treatment options to think and talk about. Some might be modified or combined, and you can probably come up with others, especially working in conjunction with colleagues in, say, a risk workshop, risk management exercise, management meeting or training course. Fantastic!

I commend it to the house.