This section analyses data from 2018 on information security management system audits to ISO/IEC 27001 by DNV GL on certified companies. By quantitatively and qualitatively analyzing the data, it provides insights into the aggregated performance of companies’ management systems.
The aim is to provide targeted insight to what process areas, sub-processes or activities cause the most issues in organizations seeking to achieve and/or maintain certification to an information security management system standard. The results came from analyzing audits conducted worldwide by DNV GL on more than 1,700 companies certified to ISO/IEC 27001.
Classification of findings
The statistics are based on audit findings. For the purpose of this analysis, a distinction is made between “severe” and “non-severe” findings. Severe findings include major and minor non-conformities. Non-severe findings include observations and opportunities for improvement.
A total of 78% of companies audited to ISO/IEC 27001 experienced at least one finding (any category) whilst 40% concluded the audit with at least one severe finding, i.e. with a major non-conformity (Cat1) or a minor non-conformity (Cat2). Almost the 40% of the companies had findings related to section A.12, where we find IT system management and, partially, IT network requirements.
The requirements in a nutshell
For the top-three most frequent severe failures (excluding 9.2 and 9.3 that are common to all management systems, and hence less relevant here), an in-depth qualitative analysis has been conducted aimed at categorizing the root-causes behind the non-conformities and the corrective actions put in place by companies to manage the issue and preventing it from recurring.
ISO/IEC 27001The following issues are specifically relevant to companies certified ISO/IEC 27001:
6.1.2 Information security risk assessment
The organization shall define and apply an information security risk assessment process. This shall include the establishment of an approach for the information security risk management, information security risk acceptance criteria, the identification, the analysis and the evaluation of risks. A total of 27% of organizations do not meet the requirements, usually for 2 reasons: the first is that the approach does not ensure the consistency and the validity of results, e.g. a lack of scales for assigning values to likelihood and consequences of risks; the second is that not all relevant risks are identified (usually organizations focus on IT risks and risks from external origins). Corrective actions usually include the review of the risk assessment approach and a review of relevant risks.
6.1.3 Information security risk treatment
The organization shall formulate a risk treatment plan and produce a statement of applicability that considers the controls in the Annex A of the standard. Usually the findings are the following: the risk treatment plan does not include deadlines and responsibilities for the actions or some exclusions of the controls in Annex A of the standard are not correctly justified (for example, many organizations exclude the use of control A.12.1.1 because they think it is only applicable to the software development and not to the software acquisition). Corrective actions require a better planning of the risk treatment actions or a consistent justification for the accepted risks or require a better understanding of the controls in the Annex A of the standards, because sometimes they are implemented but the organizations, because of lack of understanding, considered them as not applicable.
A.9.2.5 Review of user access rights
The organization shall review users’ access rights at regular intervals. The 3% of audited organizations don’t meet the requirement because the review is not performed or is partially performed. The root cause usually lies in the lack of awareness by the owners of the relevant systems and in the complexity of the task, due to the complexity of current IT systems and the variety of authorizations given to users. Corrective actions usually require to correctly plan and perform the review. In some cases, they initiate a project for an evolution of software for the automatic generation of authorization reports or for the automatic analysis of authorizations set in a system and the roles listed in the IT software used for the HR management.
A.8.1.1 Inventory of assets
Assets shall be identified and listed in an asset inventory. The asset inventory shall be maintained. The 3% of audited organizations don’t meet the requirement because not all assets are in the asset inventory. This is basically due to the number and complexity of assets, to the use of inadequate tools for the inventory (e.g. a list in a spreadsheet or in a document) or to the wrong definition of “asset” (this may lead to an inventory with too many and not relevant assets, such as mouses or keyboards, or not enough detailed for the needs of the organization). Usually corrective actions are limited to the correction of the asset inventory, but they should lead to a review of the tools used for the asset inventory (and should also consider the use of a discovery tool for IT systems and the correct appointment of relevant functions in the organization) and the type of assets that must be inventoried for their correct management.