Common Causes of Non-Conformities in ISO 27001

Download Your ISO 27001 (Information Security) Checklist Here

There are 17 clauses and 10 Annex A controls where it is a requirement to retain documented information or document something.

Missing mandatory documentation

The auditor will expect to see evidence of these and their absence will almost certainly result in a non-conformity. In addition there are some controls that don't mandate documentation but the intent is the same, such as the cryptographic policy, clear desk policy, event logs, and data transfer policies.

Failure to follow own procedures

Sometimes an ISMS is let down when the auditor visits the shop floor. Process operators reveal that either they're not following a defined information security procedure or they don't know that it exists. It could be sending sensitive emails insecurely, allowing people to tailgate, not reviewing system logs - there are many examples.

One of the causes of this maybe that the organization has not effectively communicated or integrated the ISMS into the organization - the auditor will try to find out why in order to determine where the management system has failed. Some people don't follow procedures because they don't have the resources needed to follow them properly. Again the auditor will pick up on this because it's a top management leadership requirement ensure the resources are available.

Clause 4

Almost half the NCs raised against Clause 4 by NQA were because the ISMS didn't adequately define the external and internal issues affecting the organization's purpose. Why do you need to list the issues? Well, unless you know the issues affecting your organization you won't be able to integrate risk management into your operations - you can't manage risk if you don't understand your organization and its context. 

What does it mean, issues? External issues are the environment in which the organization operates. They're determined by what the organization does and how they affect its objectives. For example, a web retailer's external issues will be very different from a school's. Whilst internal issues also affect the organization's objectives, they're self-imposed, such as the culture and structure.

Scope is the next most common NC, where it's either missing entirely from the ISMS or is incomplete. Clause 4.3 exactly defines what is required, but note the dependencies on clauses 4.1 and 4.2. Scope is important because it defines the boundaries of the ISMS.

Sometimes it becomes apparent during an audit, as the auditor becomes familiar with the organization, that something is missing from the scope. Or perhaps the risk assessment lists information assets that are outside the scope. Or which are clearly in scope but haven't been included.
 
Understanding the needs and expectations of interested parties from Clause 4.2 often catches people out. But the standard wants you to explicitly consider interested parties information security requirements. It then helpfully notes that their requirements could be legal, regulatory or contractual, which essentially tells you what is required. 
 
Our experienced auditors have frequently spotted some essential legislation is missing - there are many statutes that have an information security implication, even if it's not obvious at first glance. Note also that during the Stage 2 audit the auditor will also look at Annex A-18 which explicitly requires all relevant legal, regulatory and contractual requirements to be documented.

Clause 5

In common with all the Annex SL standards leadership is fundamental to operating a successful management system. All the Annex SL standards require top management to set policy and assign resources. This is no different to what top management would be doing for the overall organization. It’s in everyone's interest that top management is well versed in the requirements of Clause 5.

Clause 5 is where top management demonstrate their commitment to the ISMS, even if they have delegated its management. Demonstrate is the key word here - 8% of the Non-Conformities (NC) in Clause 5 arise because our auditors didn't have confidence that top management were committed to the ISMS. 

This was usually because the ISMS policy was not approved by top management, they didn't make themselves available for interview, or when interviewed knew little about the ISMS.

The auditor will need to interview top management (or top management at an appropriate level) and will discover if the top management is committed to information security. 

You'll need to make sure that everything is lined up for the top management interview: 14% of the NCs were caused by the ISMS policy not being compatible with the organization's strategy, which could suggest a lack of top management involvement. It's worth considering what the auditor typically sees in those circumstances.

Clauses 5.1a and 5.2a both require the policy to fit with the organization. Having already reviewed the organization under Clause 4 the auditor will have a good understanding of the organization, what it does and why it does it. The auditor will require that top management describe the organization's strategic direction. It will be obvious to our auditor if the information security policy doesn't support the overall purpose of the organization.

Information security objectives don't appear until Clause 6.2, yet your top management is expected to know them. This in turn implies that your top management should be aware of your risk assessment and risk treatments. They then should be able to discuss objectives with authority.

5.1d should be easy for the top management to demonstrate - your internal and supplier communications about the importance of information security is one way to show the auditor how you meet the requirement. Yet we do have awkward moments when the top management just don't know, usually because they've delegated it all to the ISMS manager.

5.2 Policy

There's some mandatory inclusions to the policy which are listed in 5.2b, c & d. Yet 25% of Clause 5 NCs occur because those requirements are missing from the policy.

5.3 Organizational roles, responsibilities and authorities

A failure to assign roles and responsibilities for information security frequently causes NCs. We usually uncover this when reviewing documentation and interviewing people. This is sometimes attributed to the policy not being communicated which is also a cause of NCs. 

It's important not to conflate information security with ISMS management. The usual mantra is that, like health and safety, everyone is responsible for information security. Whereas not everyone will be involved managing the ISMS.

Sometimes a lack of leadership commitment manifests in a different clause but is directly attributed to a Clause 5 failure. A failure to take action following the management review in Clause 9 can be an NC against Clause 5.1c - ensuring resources are available, or 5.1e - ensuring that the management system achieves its intended outcomes.

Clause 6

There are four distinct stages to Clause 6 and they’re at the heart of the standard. It’s important to understand the differences and nuances of each step, because they’re frequently conflated.

• 6.1.1: Identify risks and opportunities to the ISMS and have plans to address them. Note that this is about risks to the management system, which is common in all Annex SL standards, not to the security of information, which comes next. You don’t need to conduct a full risk assessment for 6.1.1. but you do need to have plans to treat the risks.

• 6.1.2: Assess security risks to information

• 6.1.3: Treat the security risks to information and have plans to treat them

• 6.2: Establish information security objectives and have plans to achieve them

So that’s two distinct risk assessments and three distinct sets of plans.

We often see the ISMS risks and the information security risks in the same risk assessment table, which is acceptable as long it is clear which risks they are. It isn’t acceptable to say that the risks identified in 6.1.2 are the same as those for 6.1.1. This is the most common cause for non-conformities against 6.1.1, followed by there being no identified risks and opportunities.

This table shows the most common causes of non-conformities in 6.1.2 and 6.1.3.

These can be broadly broken down into a lack of conformant documentation or not following the standard or your defined risk assessment/treatment processes. Whilst many of them are self-evident, calling out the 4 most common. Firstly, the RA-RT- SoA (Risk Assessment-Risk Treatment-Statement of Applicability) linkage broken.

There should be a flow from the identified risks, through treating those risks to selecting Annex A controls for the SoA. Sometimes it’s not obvious, or the client can’t explain it. If we can’t see it then it suggests the process hasn’t been followed.

The standard is specific about the minimum required steps for the information security risk assessment and treatment. Non-conformities arise when the organisation hasn’t implemented a conformant process. We often see some advanced risk assessment tools, which are good as long as they are operated correctly.

Then there’s the SoA content not being justified. 114 Annex A controls is a lot to go through so quite often one or two can slip through the net. But the standard doesn’t give any leeway – you must justify why controls are included or excluded and their state of implementation.

Finally, there’s missing risks. Having already audited Clause 4, the auditor will have a good understanding of your information security context so if obvious risks are missing they’ll be called out.

These are the most common causes of non-conformities in Clause 6.2:

• A complete lack of objectives

• They are business objectives, not information security objectives

• The objectives are not consistent with the Information Security Policy

• The objectives do not take into account the information security risks

• There is a lack of resources assigned to achieve the objectives or no ownership has been assigned

• There are no plans to achieve the objectives

• There are no targets or performance metrics to monitor progress towards achievement

• Performance monitoring is not taking place, such as with Key Performance Indicators or within the Management Review

Clause 7

The non-conformities in Clause 7 are fairly common across most Annex SL standards. 27001 has little to say about resources, other than organisations must make sure the ISMS is fully resourced. This is often understood during the Clause 5 audit, so very few NCs are raised.

Clause 7.2 can be summarised as: work out what competencies your organisation needs for information security performance, make sure your people have said competencies, and keep evidence of their competence. It's important to note that doesn't mean you need information security experts - paragraph a. states: 'determine the necessary competence of person(s) doing work under its [ISMS] control that affects its information security performance'.

This means that the people within scope must be competent at their jobs where there is an information security aspect to it. For example, people in the IT department must know the implications of their activities on information security, whereas a call centre agent must be appropriately trained to validate the identity of customers.
 
It also means that Clause 7.3 Awareness is closely related, because everyone in scope has an information security role to play, through knowledge of the information security policies and procedures.

In order to comply the organisation must decide what the required competencies are, some of which are simply that staff know and follow the security policies. Although the standard doesn't require the required competencies to be documented, it is good practise to do so.

A common finding is that the organisation has not determined the required competencies. This is typically because it has not been done at all and/or it has been conflated with the listing of the existing competencies of the staff.

Again, work out what competencies you need and then if you have them, as per paragraph b. Paragraph d. mandates that there should be documented evidence of competence and this is also a place for repeated non-conformities.

Incomplete or inadequate training records, CVs not up to date, professional qualification certificates missing, induction training not carried out are typical examples. Our auditors find these non-conformities when looking for documented sources and when interviewing staff.

It's important to note that experience is just as important as qualifications and training, although harder to document - CVs, annual performance reviews and other job-related records such as mentoring can all serve as objective evidence.

Clause 7.3 Awareness

Almost all the organisations we audit define some form of awareness programme or regular communications to ensure staff are aware of the information security policy, their role in the ISMS and the implications of non-conformance. This often builds on the security elements of new joiners' induction programmes.

And almost all of the non-conformities arise during staff interviews. We ask client staff those three questions: their knowledge of the security policy, their role in the ISMS and the importance of it, and sometimes the staff just don't know. Sometimes they don't know where to find the policy and sometimes they just can't recall it.

This isn't a case of auditor's luck in finding non-conformities, instead it suggests that the awareness activities are not effective, which in itself presents a security risk to the organisation.

Clause 7.5 Documented Information

We find that organisations frequently struggle to follow their own policies for creating and updating documented information. In part this is due to the volumes of data processed and the pace at which business is conducted. Paragraph 7.5.2 lays out the mandatory requirements for creating and updating documented information and then Paragraph 7.5.3 talks about the security controls for it.

Typical non-conformities include incorrect or missing classification labels, inconsistent naming, versioning or dating conventions, out of date references to superceded documents, missing documents and incomplete documents. In some cases the asset and risk registers are found to be out of date, or that they have been updated but the date and version numbers have not.
 
A lack of information retention policy or the IRP not being followed e.g. we've found old documents left on file servers or emails going back many years, are also causes of non-conformities.

Clause 8

There are fewer non-conformities raised against Clause 8 because much of the risk assessment and risk treatment is covered in Clause 6. Nonetheless, Clause 8.1 is operating the security controls and implementing change management across information security. Non-conformities do arise, for example, when an organisation is undergoing a transformation or assimilation of a new acquisition, and there are no change management plans for information security.

Non-conformities can be raised if the organisation has undertaken a risk assessment in accordance with the criteria it defined in 6.1.2.a. For example, if one of your criteria is to conduct a risk assessment following the announcement of a critical software vulnerability on a key IT component, but you didn’t do it, then that would be a non-conformity.

Failure to drive the risk treatment plan can result in a non-conformity.

Clause 9

Since Annex SL (and indeed before then), evaluating performance has been common across all management system standards. These findings are also found in other Annex SL standards audits, the only difference being the audit and performance of Annex A controls which are unique to ISO 27001:2013.

Section 9 Performance Evaluation is the 'Check' step of the Plan Do Check Act (PDCA) cycle. This infographic shows the clauses of various Annex SL standards aligned to the PDCA steps. This is when the organisation checks the two most important factors:

• The performance of its information security

• The effectiveness of its ISMS

It is the time when the organisation gazes inward to check itself, and it needs to be as objective and as impartial as possible to get the most value from it. All organisations carry out checks on various business functions, such as sales targets and customer service, so security should be similarly scrutinised.

There are 3 parts to the clause:

9.1 Monitoring, Measurement, Analysis and Evaluation

Annex SL are process and risk-based standards. This means that the performance monitoring of the information security must be:

• Based on the interacting processes within the scope of the management system

• Biased towards those processes and information assets which matter most to the organisation e.g. are higher risk.

The standard requires the organisation to consider what needs to be monitored and measured, how it's going to be monitored, when and who shall do the monitoring and when and who shall do the results evaluation. In some cases major non-conformities have been raised because there is no evidence that 9.1 has been adhered to.
 
But typically non-conformities arise because there are very few measurement requirements defined. Coupled with this our auditors often see that the items identified have inappropriate metrics or KPIs. This may also suggest that information security objectives have not been fully defined, because there is a requirement to measure progress towards them (6.3).

Because this is risk-based there should be a link between the risks identified in Clause 6 and the information security controls and processes to be monitored. For example, if there are some security controls that are important for mitigating a high risk then it's in the organisation's interest to be closely monitoring the performance of those controls. Whereas it might reasonably choose not to closely monitor controls that address lower risks.

We also see cases where management system performance measurement has been defined but nothing for the security controls, and vice versa. And finally, we often see that comprehensive performance measurement metrics are in place but there is no measurement taking place.

9.2 Internal Audit

More non-conformities are raised against internal auditing than against any other clause in ISO 27001:2013. Not carrying out internal auditing or missing out in-scope locations raises major non-conformities. This can be due to the organisation not planning any audits or has planned them but not carried them out. A lack of internal audits can prevent an organisation progressing from a Stage 1 to a Stage 2 and prevent certification being awarded after a Stage 2.

The standard states that internal audits shall be conducted at planned intervals, but it doesn't suggest an appropriate frequency. However, management system certification operates in a three year cycle so we expect all the management system requirements covered and the Statement of Applicability controls sampled on a risk basis.

Minor non-conformities arise when the audit programme is not appropriate to the risks or lacks sufficient coverage for the scope. In particular, all the physical locations in scope must be audited and it's not unknown for remote facilities to be missed off the programme.

We sometimes see audit programmes for all the management system but without the Annex A controls and vice versa. Missing out elements of the programme without rescheduling them within the three year cycle can also raise findings.

Quite often the audit records are inadequate, in that they don't adequately record the audit observations and any findings that arose. Finally, we sometimes find that the impartiality of the auditor is inappropriate. Finding an impartial auditor in a small organisation can be difficult, but the principle is someone shouldn't be marking their own homework, so more than one auditor might be required to ensure there's no conflict of interest.

9.3 Management Review

The standard lists all the mandatory items to be considered during the management review. The biggest cause of non-conformities is due to some of the mandatory items not being discussed. Having them as standing agenda items will ensure they are always discussed.

Major non-conformities arise when no management reviews have taken place.
 
The quality and accuracy of the minutes are very important. If our auditor can't determine what was discussed and the outcome of the discussion then they don't have objective evidence. For example, simply recording 'N/A' against a mandatory item will raise a non-conformity.

Auditors will usually review the internal audit programme before the management review. They will expect to see the internal audit discussed at the management review where it will be fresh in memory.

The status of actions and their traceability or progress to closure is important. Long term unclosed actions may be indicative of a lack of continual improvement. Therefore it's important to manage actions - some may be long term projects and so require less frequent review or even moved out of actions altogether, but these decisions need to be recorded.

Clause 10

When things go wrong they have to be addressed – that is, corrected and then steps taken to prevent them reoccurring: this is fundamental to management system standards and the PDCA cycle. Most organisations maintain a corrective action register and it’s where auditors will first go for evidence that there is an active non-conformity process.

Gaps in the register, such as no root-cause analysis, missing corrective actions, reviews of corrective action effectiveness and missing dates are typical causes of non-conformities. Similarly, a complete absence of any records can suggest that the process is not operating.

Quite often during audits information security incidents are discussed with the auditor, only for these not to have been recorded in the corrective action log. Some organisations use a centralized ticketing system for recording non-conformities, which is fine as long all the requirements of the standard are met.

Authored by: Tim Pinnell, NQA Information Security Assurance Manager