Handling ISMS nonconformities reported by audit

A new member of the ISO27k Forum asked how long they have to resolve a minor nonconformity reported by the certification auditors.

I didn't know the answer so I looked it up in ISO/IEC 27006. Clause 9.6.3.1 says (in part):

"The time allowed to implement corrective action shall be consistent with the severity of the nonconformity and the associated information security risk." 

Significant risks should be addressed as a priority, whereas minor risks may be addressed 'in due course', perhaps as part of other planned changes or when the opportunity arises. Furthermore, complex issues are bound to take some time to resolve, whereas simple things may be resolved more or less on the spot. 

I suggested the reported nonconformity should be addressed in the normal way, using the organisation's documented ISMS processes along these lines:

1. Identify and explore the information risks, preferably digging all the way down to the root cause/s (e.g. why did the reported nonconformity arise in the first place?) and the full impacts (e.g. if not resolved, might this result in certification being refused or withdrawn? What other problems are likely/possible?);
   
   
2. Evaluate and decide how to treat the risks: are they unacceptable? If so, what needs to be done to bring them down to an acceptable level?;
   
   
3. Plan, authorise, resource and complete whatever changes are necessary to implement the risk treatment/s, preferably addressing the root cause/s and not just the superficial symptoms;
   
   
4. Confirm that the nonconformity and the associated information risks are, in fact, adequately resolved, and that no new information risks etc. have been created as a result of the changes.

Documented ISMS processes for handling nonconformities, issues, risks, corrective actions, improvement opportunities, changes etc. typically involve maintaining contact with whoever noticed, reported or suggested them and other stakeholders throughout the process e.g. the  'communicate risks' blob on the left of this process flow diagram: 

It may therefore be appropriate to keep in touch with the certification auditors as you work through the process, for example:

1. Acknowledging receipt of the nonconformity report, letting the auditors know that the nonconformity is being processed;
   
   
2. Checking your understanding of the issue, specifically the basis and rationale for the nonconformity report (e.g. exploring the original audit evidence of the issue and the auditors' analysis that this was a reportable nonconformity, making sure that you know what the actual issues or risk/s were; perhaps looking for further evidence to clarify the full extent and nature of the problem/s);
   
   
3. Possibly letting the auditors know what you are planning to do about them and when, and perhaps even seeking advice if there are different options (the auditors may choose not to get involved in order to maintain their independence, but no worries - there are other sources of advice);
   
   
4. Possibly discussing/negotiating/agreeing the details with the auditors, ensuring that the proposed actions will, in fact, resolve the nonconformity if completed as planned (again, the auditors may stay at arm's length);
   
   
5. Confirming that the nonconformity and (at least as importantly) the information risk/s have been resolved, offering appropriate assurance of that e.g. providing evidence or inviting the auditors to review the situation and close-off the nonconformity;
   
   
6. Politely thanking the auditors for helping you improve your ISMS, giving you the latitude and time necessary to clarify and address the root cause/s etc.  and maintaining an effective working relationship.

Clearly, the structured approach I have described is quite involved. It might be appropriate for a mature organization handing significant issues, or one suffering awkward relations with the auditors. Simpler, more pragmatic approaches or shortcuts would be cheaper and quicker (e.g. simply fixing the reported nonconformity without regard to the risks), but may not achieve the same results. As always with ISO27k, it all depends on the context. 

Contact me for advice and documentation tailored to your organization, or visit www.SecAware.com for generic ISMS policy and process templates to customise yourself.