ISO27001

Introduction and scope

ISO/IEC 27000 “provides an overview of information security
management systems” (and hence the ISO27k standards), and
“defines related terms” (i.e. a glossary that formally and explicitly
defines many of the specialist terms as they are used and should
be interpreted within the ISO27k standards).
 

ISMS/ISO27k vocabulary section

The vocabulary or glossary of carefully-worded formal
definitions covers most of the specialist information security-
related terms used in the ISO27k standards. Information security,
like most technical subjects, uses a complex web of terminology
that is continually evolving. Several core terms in information
security (such as “risk”) have different meanings or
interpretations according to the context, the author’s intention
and the reader’s preconceptions. Few authors take the trouble to
define precisely what they mean but such ambiguity is distinctly
unhelpful in the standards arena as it leads to confusion. Apart
from anything else, it would be awkward to assess and certify
compliance with ISO/IEC 27001 if the specialist terms meant
different things to the assessors and the assessed!
The vocabulary in ISO/IEC 27000 is gradually spreading
throughout the global information security profession although
some individuals and groups differ, sometimes with good reason,
creating occasional misunderstandings, clashes, and conceptual
chasms. Even if you happen to disagree with the definitions here,
it’s well worth getting familiar with them as some of your
professional contacts will implicitly accept the ISO/IEC versions.
ISO/IEC 27000 largely supersedes ISO/IEC Guide 2:1996
“Standardization and related activities – General vocabulary”, ISO
Guide 73:2009 “Risk management – Vocabulary – Guidelines for
use in standards”, and ISO/IEC 2382-8: “Information
technology - Vocabulary Part 8: Security”. It also includes
definitions taken from a few non-ISO27k ISO standards. Terms
that are reproduced unchanged from other ISO standards such
as ISO 9000 are not always entirely appropriate as such in the
information security context. They are not necessarily used in the
ISO27k standards in full accordance with the original definitions
or intended meanings. However, as the definitions are gradually
updated or superseded, the lexicon is evolving into
a reasonably coherent and consistent state across the whole
ISO27k suite - a remarkable achievement in its own right given
the practical difficulties of coordinating the effort across a loose
collection of separate committees, editing projects, editors and
managers, developing the language and the concepts as we go.
 

ISMS/ISO27k overview section

The overview of Information Security Management Systems
(ISMSs) introduces information security, risk and security
management, and management systems. It is a reasonably clear
if rather wordy description of the ISO27k approach and standards,
from the perspective of the committee that wrote them. There’s
only one diagram, unfortunately, and all that does is group similar
types of ISO27k standards together, but, hey, that leaves room
for sites such as this one!
 

Status of the standard

ISO/IEC 27000, first published in 2009, was updated in 2012,
2014, 2016 and 2018.
 The 2018 fifth edition is available legitimately from ITTF as
a free download (a single-user PDF) in English and French.
This was a minor revision of the 2016 edition with a section on
abbreviations, and a rationalization of the metrics-related
definitions following the re-write of ISO/IEC 27004.
 Work has commenced on a sixth edition of ‘27000. A change
of ISO policy re incorporating definitions within the standards
implies that the sixth edition may drop the glossary, leaving just
the ISMS/ISO27k overview ... but we’ll see how that pans out.
 

Personal comments
I wish the committee would replace “information security risk”
throughout ISO27k with the simpler and more appropriate term
“information risk”. “Information security risk” is not formally
defined as a complete phrase and doesn’t even make sense: it is
presumably trying to indicate that we are talking about risk in the
context of information security, but it could be interpreted as
“risk to information security” which I guess would including things
such as failing to identify novel risks, and lack of management
support for the function: those are risks, but they are not the
focus of ISO27k. “Information risk”, in contrast, is self-evident
but, if the committee feels the desperate need for an explicit
definition, I suggest something as simple as “risk relating to or
involving information” or even “risk pertaining to information”,
where both risk and information are adequately defined in
dictionaries (whereas the ISO27k definition of risk is unhelpful).
The future of ISO/IEC 27000 - the glossary section at least - is in
question, partly due to ISO directives that (for some curious
reason) evidently prohibit the standard containing both definitions
and narrative. A proposal has been made to revert to the older
mechanism whereby each ISO27k standard contains its own set
of definitions, maintained by the respective editorial teams. That
approach didn’t work very well before and I have no reason to
think it has mysteriously improved. Another suggestion is to
publish the glossary outside the ISO/IEC/ITTF system, which has
the advantage of speeding-up the process: ISO appears to be
suggesting online glossaries, perhaps based on the
ISO Online Browsing Platform and/or the IEC’s
equivalent International Electrotechnical Vocabulary (a.k.a.
Electropedia).
By the way, the abbreviation “ITTF” is not expanded anywhere
obvious on the ISO website. Somehow I doubt it stands
for International Table Tennis Foundation
or I Think That’s Funny.  So that
leaves Information Technology Task Force.  Presumably.

 
ISO/IEC 27001:2013   — Information
technology — Security techniques
— Information security management
systems — Requirements (second
edition)
 

Abstract
“This International Standard specifies the requirements for establishing,
implementing, operating, monitoring, reviewing, maintaining and improving a
documented information security management system within the context of the
business activities of the organization and the risks it faces.”

[Source: SC27 Standing Document 11 (2021)]

Introduction
ISO/IEC 27001 formally specifies
an Information Security Management System, a governance arrangement
comprising a structured suite of activities with which to manage
information risks (called ‘information security risks’ in the standard).
The ISMS is an overarching framework through which management
identifies, evaluates and treats (addresses) the organisation’s information
risks. The ISMS ensures that the security arrangements are fine-tuned to
keep pace with changes to the security threats, vulnerabilities and
business impacts - an important aspect in such a dynamic field, and a key
advantage of ISO27k’s flexible risk-driven approach as compared to, say,
PCI-DSS.
The standard covers all types of organizations (e.g. commercial
enterprises, government agencies, non-profits) of all sizes (from micro-
businesses to huge multinationals) in all industries (e.g. retail, banking,
defense, healthcare, education and government). This is clearly a very
wide brief.
ISO/IEC 27001 does not formally mandate specific information
security controls since the controls that are required vary markedly
across the wide range of organizations adopting the standard. The
information security controls from ISO/IEC 27002 are summarised in
annex A to ISO/IEC 27001, rather like a menu. Organizations adopting
ISO/IEC 27001 are free to choose whichever specific information security
controls are applicable to their particular information risks, drawing on
those listed in the menu and potentially supplementing them with other a
la carte options (sometimes known as extended control sets). As
with ISO/IEC 27002, the key to selecting applicable controls is to
undertake a comprehensive assessment of the organization’s information
risks, which is one vital part of the ISMS.
Furthermore, management may elect to avoid, share or accept
information risks rather than mitigate them through controls - a risk
treatment decision within the risk management process.

History
ISO/IEC 27001 is derived from BS 7799 Part 2, first published as such by
the British Standards Institute in 1999.
BS 7799 Part 2 was revised in 2002, explicitly incorporating the Deming-
style Plan-Do-Check-Act cycle.
BS 7799 part 2 was adopted as the first edition of ISO/IEC 27001
in 2005 with various changes to reflect its new custodians.
The second edition of ISO/IEC 27001 was published in 2013, having
been extensively revised to align with the other ISO management systems
standards. PDCA is no longer explicit, but the concept of continuous
refinement and systematic improvement remains, for sure.

Structure of the standard

ISO/IEC 27001:2013 has the following sections:
0 Introduction - the standard describes a process for
systematically managing information risks.
1 Scope - it specifies generic ISMS requirements suitable for
organizations of any type, size or nature.
2 Normative references - only ISO/IEC 27000 is considered
absolutely essential to users of ’27001: the remaining ISO27k
standards are optional.
3 Terms and definitions - see ISO/IEC 27000.
4 Context of the organization - understanding the organizational
context, the needs and expectations of ‘interested parties’ and
defining the scope of the ISMS. Section 4.4 states very plainly that
“The organization shall establish, implement, maintain and
continually improve” the ISMS.
5 Leadership - top management must demonstrate leadership and
commitment to the ISMS, mandate policy, and assign information
security roles, responsibilities and authorities.
6 Planning - outlines the process to identify, analyze and plan to
treat information risks, and clarify the objectives of information
security.
7 Support - adequate, competent resources must be assigned,
awareness raised, documentation prepared and controlled.
 8 Operation - a bit more detail about assessing and treating
information risks, managing changes, and documenting things
(partly so that they can be audited by the certification auditors).
9 Performance evaluation - monitor, measure, analyze and
evaluate/audit/review the information security controls, processes
and management system, systematically improving things where
necessary.
10 Improvement - address the findings of audits and reviews
(e.g. nonconformities and corrective actions), make continual
refinements to the ISMS.
Annex A Reference control objectives and controls - little more
in fact than a list of titles of the control sections in ISO/IEC 27002.
The annex is ‘normative’, implying that certified organizations are
expected to use it, but the main body says they are free to deviate
from or supplement it in order to address their particular
information risks. Annex A alone is hard to interpret. Please refer
to ISO/IEC 27002 for more useful detail on the controls, including
implementation guidance.
Bibliography - points readers to five related standards, plus part 1
of the ISO/IEC directives, for more information. In addition, ISO/IEC
27000 is identified in the body of the standard as a normative
(i.e. essential) standard and there are several references to ISO
31000 on risk management.

Mandatory requirements for certification

ISO/IEC 27001 is a formalized specification for an ISMS with two distinct
purposes:
1. It lays out the design for an ISMS, describing the important parts at a
fairly high level;

2. It can (optionally) be used as the basis for formal compliance assessment

by accredited certification auditors in order to certify an organization
compliant.

The following mandatory documentation is explicitly required for

certification:
1. ISMS scope (as per clause 4.3)

2. Information security policy (clause 5.2)

3. Information risk assessment process (clause 6.1.2)

4. Information risk treatment process (clause 6.1.3)

5. Information security objectives (clause 6.2)

6. Evidence of the competence of the people working in information security

(clause 7.2)
 7. Other ISMS-related documents deemed necessary by the organization
(clause 7.5.1b)

8. Operational planning and control documents (clause 8.1)

9. The results of the [information] risk assessments (clause 8.2)

10. The decisions regarding [information] risk treatment (clause 8.3)

11. Evidence of the monitoring and measurement of information security

(clause 9.1)

12. The ISMS internal audit program and the results of audits conducted
(clause 9.2)

13. Evidence of top management reviews of the ISMS (clause 9.3)

14. Evidence of nonconformities identified and corrective actions arising

(clause 10.1)

15. Various others: Annex A mentions but does not fully specify further
documentation including the rules for acceptable use of assets, access
control policy, operating procedures, confidentiality or non-disclosure
agreements, secure system engineering principles, information security
policy for supplier relationships, information security incident response
procedures, relevant laws, regulations and contractual obligations plus the
associated compliance procedures and information security continuity
procedures. However, despite Annex A being normative, organizations
are not formally required to adopt and comply with Annex A: they can use
other structures and approaches to treat their information risks.

Certification auditors will almost certainly check that these fifteen types of
documentation are both present and fit for purpose.
The standard does not specify precisely what form the documentation
should take, but section 7.5.2 talks about aspects such as the titles,
authors, formats, media, review and approval, while 7.5.3 concerns
document control, implying a fairly formal ISO 9000-style approach.
Electronic documentation (such as intranet pages) are just as good as
paper documents, in fact better in the sense that they are easier to
control and update.

ISMS scope and Statement of Applicability (SoA)
Whereas the standard is intended to drive the implementation of an
enterprise-wide ISMS, ensuring that all parts of the organization benefit
by addressing their information risks in an appropriate and systematically-
managed manner, organizations can scope their ISMS as broadly or as
narrowly as they wish - indeed scoping is a crucial decision for senior
management (clause 4.3). A documented ISMS scope is one of
the mandatory requirements for certification.
Although the  Statement of Applicability is not explicitly defined, it is
a mandatory requirement of section 6.1.3. SoA refers to the output from
the information risk assessments and, in particular, the decisions around
treating those risks. The SoA may, for instance, take the form of a matrix
identifying various types of information risks on one axis and risk
treatment options on the other, showing how the risks are to be treated in
the body, and perhaps who is accountable for them. It usually references
the relevant controls from ISO/IEC 27002 but the organization may use a
completely different framework such as NIST SP800-53, the ISF standard,
BMIS and/or COBIT or a custom approach. The information security
control objectives and controls from ISO/IEC 27002 are provided as a
checklist at Annex A in order to avoid ‘overlooking necessary controls’:
they are not required.
The ISMS scope and SoA are crucial if a third party intends to attach any
reliance to an organization’s ISO/IEC 27001 compliance certificate. If an
organization’s ISO/IEC 27001 scope only includes “Acme Ltd. Department
X”, for example, the associated certificate says absolutely nothing about
the state of information security in “Acme Ltd. Department Y” or indeed
“Acme Ltd.” as a whole. Similarly, if for some reason management decides
to accept malware risks without implementing conventional antivirus
controls, the certification auditors may well challenge such a bold
assertion but, provided the associated analyses and decisions were sound,
that alone would not be justification to refuse to certify the organization
since antivirus controls are not in fact mandatory.

Metrics
In effect (without actually using the term “metrics”), the 2013 edition of
the standard requires the use of metrics on the performance and
effectiveness of the organization’s ISMS and information security controls.
Section 9, “Performance evaluation”, requires the organization to
determine and implement suitable security metrics ... but gives only high-
level requirements.
ISO/IEC 27004 offers advice on what and how to measure in order to
satisfy the requirement and evaluate the performance of the ISMS - an
eminently sensible approach not dissimilar to that described
in PRAGMATIC Security Metrics.

Certification
Certified compliance with ISO/IEC 27001 by an accredited and respected
certification body is entirely optional but is increasingly being demanded
from suppliers and business partners by organizations that are (quite
rightly!) concerned about the security of their information, and about
information risks throughout the supply chain/supply network.
Certification brings a number of benefits above and beyond mere
compliance, in much the same way that an ISO 9000-series certificate
says more than just “We are a quality organization”. Independent
assessment necessarily brings some rigor and formality to the
implementation process (implying improvements to information security
and all the benefits that brings through risk reduction), and invariably
requires senior management approval (which is an advantage in security
awareness terms, at least!).
The certificate has marketing potential and brand value, demonstrating
that the organization takes information security management seriously.
However, as noted above, the assurance value of the certificate is highly
dependent on the ISMS scope and SoA - in other words, don’t put too
much faith in an organization’s ISO/IEC 27001 compliance
certificate if you are highly dependent on its information
security. In just the same way that certified PCI-DSS compliance
does not mean “We guarantee to secure credit card data and other
personal information”, certified ISO/IEC 27001 compliance is a positive
sign but not a cast-iron guarantee about an organization’s information
security. It says “We have a compliant ISMS in place”, not “We are
secure”, a subtle but important distinction.

Status of the standard

After its development from/in parallel with British Standard BS 7799-2
and initial numbering as ISO/IEC 24743, ISO/IEC 27001 was first
published in mid-2005.
The standard was completely rewritten and published in 2013. This was
far more than just tweaking the content of the 2005 first edition since ISO
insisted on substantial changes to align this standard with other
management systems standards.
ISO/IEC 27002 was extensively revised and re-issued at the same time,
hence Annex A to ISO/IEC 27001 was completely updated too: see the
ISO/IEC 27002 page for more.
A 2014 technical corrigendum clarified that information is, after all, an
asset. Golly.
A second technical corrigendum in 2015 clarified that organizations are
formally required to identify the implementation status of their information
security controls in the SoA.
A proposed third technical corrigendum jumped the shark: SC 27 resisted
the urge to carry on tweaking the published standard unnecessarily with
changes that should have been proposed when it was in draft, and may
not have been accepted anyway. Despite not being addressed, the
concern is valid: the standard does indeed confuse information [security]
risk with risks relating to the management system. It should have
addressed the latter but instead took on the former. Ooops.
A Study Period looked at the value and purpose of Annex A in relation to
the SoA, concluding that Annex A is a useful link to ISO/IEC 27002 but the
main body wording should make it clear that Annex A is entirely
optional: organisations can adopt whatever set of controls (or indeed
other risk treatments) they deem suitable to treat their information
risks, provided the process of selecting, implementing, managing,
monitoring and maintaining the risk treatments fulfils the main body
requirements - in other words, the entire process falls within the ISMS.
An amendment to ISO/IEC 27001:2013 is on the  way, with a planned
publication date of Q2 2022. The main objective is simply to replace
Annex A, reflecting the forthcoming update to ISO/IEC 27002, and to
incorporate the existing corrigenda into the text. The amendment will not
address imminent ISO Annex SL changes (see below), clarify the main
body wording around Annex A being optional, or amend the section on
risks and opportunities to refer to the management system rather than to
information security, but such changes may follow after the amendment to
ISO/IEC 27001:2013 has been released, if and when a third edition is
approved.

Personal comments
Annex SL (previously known as “Draft Guide 83”, sometimes “Annex L”)
appendix 2 fornally specifies/mandates the boilerplate text and structure
common to all the ISO and ISO/IEC management systems standards
covering information security, quality assurance, environmental
protection etc. The idea is that people who are familiar with any one of the
management systems will understand the basic principles underpinning all
the others. Concepts such as certification, policy, nonconformance,
document control, internal audits and management reviews are common
to all the management systems standards. The common processes and
similar governance arrangements can, to some extent, be standardized
within an organization.
When next updated, Annex SL appendix 2 will probably (if approved):
 Redefine risk as “effect of uncertainty” (dropping “of objectives” from the
definition used in the current version of ISO/IEC 27000) with 4 notes
(dropping the final 2 of 6 notes in the current definition). Whether that
simplification helps, harms or has no effect on ISO27k remains to be seen.

 Replace “outcomes” with “results” - a change made primarily for ease of

translation.

 Include “Planning of changes” i.e. any changes to the management

system must be performed ‘in a planned manner’. [I hope SC 27 won’t
misinterpret and re-purpose/hijack this clause to refer to the information
security aspects of change management, particularly IT change
management, as it has already done with the ‘risks and opportunities’
clause in the current ‘27001! To be clear, ISO’s intention is for
organizations to plan and manage changes to the management system/s.]

 Replace “outsourced” with “externally provided” to encompass

outsourcing, contracting and conventional purchasing.

 Separately specify general requirements for internal audits (9.2.1) and for

the internal audit programme (9.2.2).

 Separately specify general requirements for management reviews

(9.3.1) and for their inputs (9.3.2) and outputs (9.3.3).
  Re-emphasise the need for proactive improvement of the management
system in addition to reactive responses to shortcomings.

 Mandate various other wording changes to all the ISO management

systems standards.

SC 27’s confusion over the interpretation and intended meaning of “information

asset” lingers on: the decision to drop the definition of “information asset”
from ISO/IEC 27000 rather than truly bottom-out this issue may have been a
tactical error. Reverting to the term “asset”, defined very broadly as something
of value, leads to issues throughout ISO27k if the term is replaced by its literal
and explicit definition. A brick is an asset, whereas a bricked smartphone is a
liability. “Value” is a nebulous concept. It’s fair to ask “Of value to whom?” as
well, since the organisation acts as a custodian for some information belonging to
others, including personal and proprietary information that requires adequate
protection. Should that be covered by the ISMS, or not? This is a messy, unclear
and ultimately unsatisfactory situation for an international standard.