ISO/IEC 27001
ISO/IEC 27001:2013 – Information technology – Security techniques – Information security management systems – Requirements (2nd edition)
Introduction
In ISO/IEC 27001, an Information Security Management System is defined, a set of standardized procedures designed for managing information risks (known as “information security risks” in the standard).
Information security management systems serve as a framework for identifying, evaluating, and treating (addressing) the information risks faced by the organization. ISMSs ensure that the security arrangements are continually enhanced to keep pace with growing security threats, vulnerabilities, and business impacts, and for this reason are an attractive alternative to, for example, PCI-DSS.
Standardized procedures apply to all types of organizations (commercial enterprises, government agencies, non-profits) of all sizes (micro-businesses to massive multinationals), across all industries (e.g. retail, banking, defence, healthcare, education, government) and for all types of risks. There are many issues at play in this brief.
Since the controls required do vary widely across the wide range of organizations adopting ISO/IEC 27001, the standard does not formally mandate specific information security controls. Annex A of ISO/IEC 27001 summarizes the security controls specified in ISO/IEC 27002. Following ISO/IEC 27001, organizations can select whichever specific information security controls, best suit their particular information risks, relying on the menu of standard security controls and possibly supplementing them with optional additional controls (sometimes referred to as extended control sets). An important part of ISMS is evaluating an organization’s information risks, as ISO/IEC 27002 requires.
The management may also elect to avoid, share, or accept information risks instead of mitigating them – as part of the risk management procedure.
Historical perspective
The ISO/IEC 27001 standard is a derivative of BS 7799 Part 2, first released by the British Standards Institute in 1999.
In 2002, BS 7799 Part 2 was revised and specifically incorporated Deming’s Plan-Do-Check-Act methodology.
ISO/IEC 27001 is a revised version of BS 7799 part 2, with several changes made to reflect the new custodians in 2005.
This edition of ISO/IEC 27001, the second of the ISO management systems standards, was published in 2013. Several revisions have been made to ensure compliance with other ISO management systems standards. While PDCA is no longer explicitly defined, continuous refinement and systematic improvement remain very real concepts.
Standard’s structure
The following sections are found in ISO/IEC 27001:2013:
0 Introduction – the standard defines a method for managing information risk systematically.
1 Scope – the document specifies generic ISMS requirements applicable to all types and sizes of organizations.
2 Normative references – the use of ISO/IEC 27001 is considered essential; all other ISO27k standards are optional.
3 A glossary of terms is available – see ISO/IEC 27000.
4 Organizational context – Identifying needs and expectations of business stakeholders and defining the ISMS’ scope. The ISMS is required to be created, implemented, maintained and continually improved according to section 4.4 of the document.
5 Leadership – The management must show leadership, mandate policy, and assign information security roles, responsibilities, and authority.
6 Planning – describes the process of identifying, analyzing, and planning to treat information risks, and clarifies the goals of information security.
7 Support – competent resources must be assigned, awareness must be raised and detailed documentation must be prepared.
8 Operation – explains how to assess and treat information risks, manage changes, and document your process (partly for certification auditors to verify).
9 Performance evaluation – compile data and analyze it, then perform an evaluation of, or audit of, rules, processes, and management system to find the weak points and adjust accordingly.
10 Improvement – respond to audit findings (i.e. non-conformities and corrective actions), refine and enhance the ISMS as necessary.
Annexe A Reference control objectives & controls – basically just a list of ISO/IEC 27002’s sections on controls. While the annexe is a normative document, certified organizations are free to deviate from it or add to it if that is what is necessary to address their particular information risks. Analyzing Annex A alone is challenging. More details on controls, including how to implement them, can be found in ISO/IEC 27002.
Bibliography – provides readers with links to five related standards and part 1 of the ISO/IEC directives. Also, ISO 27000 is identified as a normative (or essential) standard and ISO 31000 is referred to several times in the standard.
Qualifications for certification
A formalized model for an ISMS is ISO/IEC 27001, with two distinct aims:
1. An ISMS is described at a fairly high level, with descriptions of the important parts;
2. Accredited certification auditors may use it for formal compliance assessment, to certify that an organization is compliant.
Explicitly required for certification is the following documentation:
1. ISMS scope (as per clause 4.3)
2. The information security policy (clause 5.2)
3. The information risk assessment process (clause 6.1.2)
4. The information risk treatment process (clause 6.1.3)
5. Information security objectives (clause 6.2)
6. Validation of the competence of the employees (clause 7.2)
7. Documents related to information security management that the organization deems necessary (clause 7.5.1b)
8. Control and planning documents for operational activities (clause 8.1)
9. Information risk assessment results (clause 8.2)
10. Decisions about the information risk treatment (clause 8.3)
11. Data showing that information security is monitored and measured (clause 9.1)
12. The ISMS internal auditing program and audit results (clause 9.2)
13. Evidence of ISMS top management reviews (clause 9.3)
14. Documentation of identified nonconformities and the corrective action is taken (clause 10.1)
15. Various others: Annex A refers to these documents; however, it does not fully describe them, for instance, the acceptable use of assets policy, the access control policy, the operating procedures, the nondisclosure agreements, guidelines for secure system engineering, supplier information security policies, information security incident response protocols, laws, regulations, as well as the associated compliance procedures and continuity procedures for information security. It should be noted, however, that Annex A is not a statutory requirement for organizations to adopt and comply with: organizations have the freedom to take other measures to address their information risk.
These fifteen types of documentation will almost certainly be checked by certification auditors for both presence and suitability.
The standard does not specify exactly how documentation should be formatted, but section 7.5.2 mentions things like titles, authors, formats, media, and approvals, while section 7.5.3 mentions document control, which implies an ISO 9000-style process. Quite often, electronic documentation (like intranet pages) is better than paper documentation in that it is easier to update and control.
ISMS Framework and Statement of Applicability (SOA)
The standard is intended to ensure that companies implement an enterprise-wide ISMS that addresses their information risks appropriately and systematically; however, companies can choose to scope their ISMS as broadly or narrowly as they wish (clause 4.3). One of the requirements for certification is that an ISMS scope is documented.
Section 6.1.3 requires the Statement of Applicability, even though it isn’t explicitly defined. SOA describes the output of an information risk assessment, especially the decisions made about how to deal with the risk. For instance, the SOA may comprise a matrix that shows various forms of information risk one way and treatment options the other, illustrating how each is treated in the body, and perhaps who is responsible. Controls from ISO/IEC 27002 are most commonly referenced, but different approaches can be used as well, such as NIST SP800-53, the ISF standard, BMIS or COBIT. As a precaution against “overlooking necessary controls,” ISO/IEC 27002 provides a checklist at Annex A to avoid such a risk. These controls are not required.
For a third party to put any trust in the ISO/IEC 27001 compliance certificate of an organization, the ISMS scope and SOA must be clearly defined. The scope of an organization’s ISO/IEC 27001 certification covers the department that is being certified alone, for example. If that department happens to be “Acme Ltd. Department X,” then the certificate certifies nothing about information security across the rest of the company. If management decided to accept malware risks by foregoing conventional antivirus controls for some reason, certification auditors may challenge the bold assertion, but if the underlying analysis and decision were sound, this alone would not constitute grounds for refusing certification since antivirus capabilities are not required by law.
The metrics
Although it doesn’t use the term “metrics”, the 2013 edition of the standard requires organizations to consider metrics to determine how effectively their ISMSs and information security controls work. Section 9, “Performance evaluation”, requires organizations to identify and implement an appropriate security metric, but it merely provides high-level guidelines.
A key feature of ISO/IEC 27004 is its advice on how to measure what and how to evaluate the performance of an ISMS – a straightforward and sensible approach similar to that in PRAGMATIC Security Metrics.
Certification
The certification of compliance with ISO/IEC 27001 by an accredited and respected certification body is entirely optional; however, it is increasingly being requested from suppliers and strategic partners by organizations who are concerned about information safety and security.
As with ISO 9000-series certificates, certification can provide benefits that go beyond mere compliance. As part of the implementation process, independent assessments bring rigour and formality (implicating improved information security and all the associated benefits), and they require senior management approval, at the very least in terms of security awareness.
A certificate shows the organization is committed to information security management, which will enhance marketing potential and brand value. Nonetheless, as noted above, the certification’s assurance value is determined by its ISMS scope and its Statement of Activities – meaning you shouldn’t give too much consideration to an organization’s ISO/IEC 27001 compliance certificate if your business relies heavily on information security. Just like PCI DSS certification does not guarantee a secure environment for credit card data, ISO 27001 certification is a positive sign but not a guarantee that a company’s information is secure. There is a subtle but significant distinction between saying “We are secure” and saying “We have an ISMS in place”.
The standard’s status
First published in 2005, ISO/IEC 27001 is a standard for information security.
The standard was rewritten completely in 2013 and published. ISO insisted on substantial amendments to align this standard with other management systems standards, more than just tweaking the content of the 2005 edition.
Annex A of ISO/IEC 27001 was fully updated as well, following the extensive revision of ISO/IEC 27002. Read more about ISO/IEC 27002 on our ISO/IEC 27002 page.
The technical correction of 2014 clarified that information most definitely is an asset.
An additional technical corrigendum in 2015 clarified the need for organizations to specify the status of their information security controls in the Statement of Activities.
A third technical correction was thrown to the birds after SC 27 rejected the urge to make unnecessary amendments to the published standard which should have been discussed at the time of development and were likely to be rejected anyway. This concern is valid despite not being addressed: the standard confuses information [security] risks with risks related to the management system. Instead of addressing the latter, it addressed the former.
In a Study Period, we considered Annex A’s value and purpose concerning the SoA, stating that Annex A is an appropriate link to ISO/IEC 27002, but the main body wording should emphasize that Annex A is an optional section: the organisation may adopt whichever set of controls, or other risk treatments it considers appropriate to manage the information risk, as long as the selection, implementation, management, monitoring, and maintenance of the risk treatments satisfy the requirements of the main body – therefore, all steps are covered within the ISMS.
In April 2021, work on amending ISO/IEC 27001 began, and the amendment is expected to be published in Q2 2022. Annex A is simply being replaced to reflect the upcoming update to ISO/IEC 27002 and to incorporate the existing corrigenda. SC27 doesn’t appear to have any plans to address imminent ISO Annex SL changes (outlined below), to clarify the optional nature of Annex A, or to change the section on risks and opportunities to refer to management systems instead of information security, but that could happen or follow after ISO/IEC 27001:2022 is released … or not, depending on how things develop.
Commentary
Annex SL (formerly Draft Guide 83, sometimes referred to by the abbreviation “Annex L”) appendix 2 describes the boilerplate text and structure of the ISO and ISO/IEC management systems standards, including quality assurance, safety, and environmental protection. Any manager familiar with one of the management systems will be able to comprehend the core principles underlying all the others. Management systems standards have certain concepts in common, such as certification, policies, nonconformance, document control, internal audits and management reviews. Within an organization, common processes can be standardized to a large extent.
In the next update, Annex SL Appendix 2 may (after approval):
– Risk is defined as the result of uncertainty (do without “of objectives” from the definition used in ISO 27000 for its current version) with four notes (do without the final 2 of 6 notes). Whether that simplification helps, harms or has no effect on ISO27k is still to be determined.
– Change “outcomes” to “results” – primarily so it can be translated more easily.
– Include the phrase “Planning of changes” i.e. management system modifications should be planned out beforehand. In SC 27, it is hoped that this provision will not be misinterpreted and misused to refer to traditional aspects of IT change management as information security, as it already has with the clause “risks and opportunities” in the current standard ‘27001! Specifically, ISO is focusing on planning and managing changes to management systems.
– Change “outsourced” to “externally provided” to include outsourcing, contracting, and traditional procurement.
– Establish separate requirements for internal auditing (9.2.1) as well as the internal audit program (9.2.2).
– Indicate separately the general requirements for management reviews (9.3.1) as well as their inputs (9.3.2) and outputs (9.3.3).
– It is imperative to emphasize the necessity of proactive management improvement along with reactionary approaches to shortcomings.
– Other wording changes should be made to all ISO management system standards.
A key issue with ISO/IEC 27000 is the definition of information asset: the decision to leave out the definition of “information asset” rather than resolving the issue bottom-up may have been a tactical mistake. It is clear, however, that reverting to the term “assets”, which is defined as anything of value in a very broad sense, causes significant issues throughout ISO27k if it is used in its literal and explicit sense. While brick is an asset, a bricked smartphone is not. “Value” is an ambiguous concept. “Of value to whom?” may be a reasonable question” as well, since the organization acts as a custodian of some information belonging to others, including personal and proprietary data. Is that something that ISMS should cover? The situation for an international standard is complicated, unclear, and ultimately unsatisfying.