ISO/IEC 27028:2026

• Abstract:

  This document provides guidance on the use of information security control attributes specified in ISO/IEC 27002. The guidance given in this document is generic and is intended to be applicable to all organizations, regardless of type, size, or nature.

• Status: Published
• Publication Date: 10-Nov-2026
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Current Stage: 6060 - International Standard published
• Start Date: 11-Nov-2026
• Completion Date: 11-Nov-2026

ISO/IEC 27028 is an ISO/IEC guidance document on using information security control attributes. It explains how organizations can classify, compare, and select controls by attributes such as assurance, cost, strength, transparency, and other characteristics. The guidance is generic and is intended for organizations of any type, size, or nature.

What does ISO/IEC 27028 specify?

ISO/IEC 27028 specifies guidance on the use of information security control attributes from ISO/IEC 27002. The document is about how to use attributes to create different views of controls, build or refine risk treatment plans, and identify gaps or overlaps in a control set.

The document is organized into these main parts:

• Clause 1 - scope
• Clause 2 - normative references
• Clause 3 - terms and definitions
• Clause 4 - abbreviated terms
• Clause 5 - overview on attribute approach
• Clause 6 - additional attributes
• Bibliography

Clause 5 explains the attribute approach, including the concept of attributes, custom attributes, and practical benefits from using them. Clause 6 gives example attributes and example attribute values that organizations can adapt to their own context.

What are the key requirements of ISO/IEC 27028?

ISO/IEC 27028 is guidance, but it still sets out a clear way to use attributes in control selection and risk treatment. The main message is that organizations should define an attribute set that fits their own risks, context, and resources, then use it consistently when selecting, reviewing, and prioritizing controls.

Use attributes as a control selection tool

Clause 5 explains that ISO/IEC 27002 attributes let organizations filter and group controls in different ways, beyond the four broad themes in ISO/IEC 27002. In practice, this means a team can search for controls that match a specific goal, such as confidentiality, detectability, or a particular operational capability.

Clause 5.1 also shows that attribute values are independent of the organization’s context in ISO/IEC 27002, while the additional attributes in this document are context dependent. That matters because a control can be suitable in one setting and less suitable in another.

Develop custom attributes when needed

Clause 5.2 says organizations can define custom attributes by modifying the values used in ISO/IEC 27002. The methods named are integrating values, dividing a value, refining a value, renaming a value, or adding a new value.

This matters because organizations often need categories that fit their own business, technology, or regulatory environment. The document also gives an alternative method based on event-consequence scenarios, which helps teams design attributes around how a risk starts, how it is detected, and how its effects are limited.

Build controls around event-consequence scenarios

Clause 5.2.2 describes an event-consequence scenario method. The organization first chooses an event of concern, identifies the consequences, estimates likelihood and impact, and then develops a risk treatment plan. It then maps suitable controls, including preventive, detective, and corrective controls, and fills any gaps with custom controls.

In practice, this gives a structured way to check whether the control set covers prevention, detection, and impact reduction. It also helps teams see when the same risk scenario applies to more than one event, such as loss or theft of a laptop.

Use attributes to strengthen risk treatment plans

Clause 5.3 explains that attributes can help improve risk treatment plans, reveal missing controls, and make the suite of controls more balanced. The document says organizations should establish a reference set of standard and custom attributes and set priorities for them based on business, operational, regulatory, risk appetite, and budget factors.

Clause 5.3.2.3 emphasizes that a resilient risk treatment plan should combine preventive, detective, and corrective controls. That matters because if one control fails, another can still reduce the risk.

Select controls by fit, balance, and value

Clauses 5.3.4 to 5.3.6 show how attributes help compare controls by strength, balance, and usefulness. The document discusses using attributes to avoid overreliance on one control type, to identify redundant controls, and to find supplementary or complementary controls.

For a reader, the practical point is that a control set should not be chosen only because a control is familiar or available. It should fit the risk, the architecture, and the business objective.

Support assessment, audience views, and privacy work

Clause 5.3.7 says attributes can guide control assessment, including depth and coverage. Clause 5.3.8 says attributes can be used to present controls differently for different audiences, such as technologists, senior management, auditors, procurement, HR, and finance.

Clause 5.3.9 extends the approach to privacy-related attributes. That matters because privacy risk can be related to, but not limited by, information security risk.

Use the example attributes in Clause 6 as starting points

Clause 6 gives example attributes such as assurance, complexity, contextual-fit, control environment, failure modes, formality, integration, maturity, measurability, multi-functionality, origin, regulation, strength, reduction-focused, transparency, and cost. These examples help organizations define their own attribute sets and decide what to measure or compare.

What terms does ISO/IEC 27028 define?

• Attribute - a quality or feature of something, used here as a way to describe a control.
• Attribute value - the particular form, quantity, category, or range assigned to an attribute.
• Custom attribute - an attribute developed or adopted by the organization that differs from those in ISO/IEC 27002.
• Risk treatment plan (RTP) - the plan that records how the organization will respond to identified risk.
• Information security management system (ISMS) - the management system used to govern and improve information security controls and risk treatment.
• Preventive control - a control intended to prevent an information security event from occurring.
• Detective control - a control intended to detect an information security event when it occurs.
• Corrective control - a control intended to limit the consequences of an information security event.

Who uses ISO/IEC 27028?

ISO/IEC 27028 is used by organizations that manage information security, cybersecurity, and privacy risk and want a structured way to compare controls. It is relevant to risk owners, control designers, ISMS managers, security architects, auditors, assessors, and governance teams.

It is also useful for procurement, HR, finance, and other specialists who need different views of controls for operational or policy decisions. In practice, users apply it when selecting controls, checking control coverage, reviewing a risk treatment plan, assessing controls, and tailoring controls to a specific environment.

Which standards are used with ISO/IEC 27028?

ISO/IEC 27028 is built around ISO/IEC 27002:2022, which provides the control catalogue and the original attribute concept. ISO/IEC 27001:2022 provides the ISMS context and Annex A controls that the document refers to when building risk treatment plans.

ISO/IEC 27005:2022 contributes the event-consequence approach to risk assessment and risk treatment. ISO/IEC/TS 27008 supports assessment of information security controls, especially when using assurance or depth-of-assessment views.

ISO/IEC/TS 27110 is cited as a way to develop a similarly structured cybersecurity framework. ISO/IEC 27701:2025 is referenced for privacy-related attributes and privacy risk management.

What does the ISO/IEC 27028 document contain?

ISO/IEC 27028 contains a conceptual explanation of the attribute approach, followed by a set of example attributes and example attribute values. It includes a worked discussion of how attributes can be used to search, classify, compare, and select controls.

The document also contains Figure 1, which maps typical uses of attributes across the information security risk management process, and Table 1, which shows how five control attributes and their values classify a threat intelligence control. Those parts are used to support control selection, risk treatment planning, and communication with different audiences.

Clause 6 provides practical descriptions of attribute types such as assurance, complexity, maturity, measurability, strength, transparency, and cost. These examples are meant to help organizations design their own control catalogue, improve control assessment, and adapt controls to their operational and regulatory context.

International
Standard
ISO/IEC 27028
First edition
Information security, cybersecurity
2026-11
and privacy protection — Guidance
on using information security
control attributes
Sécurité de l'information, cybersécurité et protection de la vie
privée — Recommandations sur l'utilisation des attributs de
contrôle de la sécurité de l'information
Reference number
© ISO/IEC 2026
All rights reserved.
This ISO publication is protected by copyright and is owned by ISO and/or its licensors.
The content of this ISO publication is provided under licence, not sold. Use is subject to the applicable licence terms issued by ISO,
an ISO member body, or an authorized third-party distributor.
Except as required for implementation or expressly permitted by a separate licence, no part of this ISO publication may be
reproduced, distributed, modified, used, or made available in any form or by any means – electronic or mechanical, including
photocopying, scanning, recording, or posting on internal or external digital platforms.
Any use beyond the scope of the granted rights is prohibited and may result in legal action.
ISO copyright office
CP 401 • CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Overview on attribute approach . . 2
5.1 Concept of attribute .2
5.1.1 General .2
5.1.2 Attributes given in ISO/IEC 27002 .2
5.1.3 Additional attributes introduced in this document .3
5.2 Custom attributes .3
5.2.1 General .3
5.2.2 Event-consequence scenario method .4
5.3 Benefits from using attributes .5
5.3.1 General .5
5.3.2 Creating robust risk treatment plans .6
5.3.3 Defining the relationship between this document and both ISO/IEC 27002 and
ISO/IEC 27005 . . .8
5.3.4 Strengthening information security .8
5.3.5 Achieving a balanced suite of controls .9
5.3.6 Maximizing the value of existing and proposed controls .9
5.3.7 Reviewing and assessing controls .9
5.3.8 Viewing controls from the audience’s perspective .10
5.3.9 Improving privacy through attributes .10
6 Additional attributes . 10
6.1 General .10
6.2 Assurance attribute .11
6.3 Complexity attribute .11
6.4 Contextual-fit attribute. 12
6.5 Control environment attribute . 12
6.6 Failure modes attribute . 13
6.7 Formality attribute . 13
6.8 Integration attribute . 13
6.9 Mature attribute .14
6.10 Measurability attribute .14
6.11 Multi-functionality attribute . 15
6.12 Origin attribute . 15
6.13 Regulation attribute .16
6.14 Strength attribute .16
6.15 Reduction-focused attribute .16
6.16 Transparency attribute.17
6.17 Cost attribute .17
6.18 Other custom controls and other custom attributes.18
Bibliography . 19

© ISO/IEC 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
iv
Introduction
ISO/IEC 27002:2022, 4.2 and Annex A, define the concept of attributes. ISO/IEC 27002 also explains that
an organization can develop its own attributes (with the corresponding attribute values) to describe how
controls are used or how to determine where they are applicable.
In addition to the attributes and themes presented in ISO/IEC 27002, information security controls can also
be characterized in other ways which can be relevant and helpful in particular situations when determining
or designing controls.
This document provides guidance on the use of information security control attributes. It introduces a
method to help organizations develop their own custom attributes based on event-consequence scenarios
and describes how attributes can be used to discover gaps within the organization’s risk treatment plan(s)
and to check if such plans are tolerant of control failures.
It also describes how attributes can be used as criteria to set controls to mitigate the risk within an
organization’s information security management system (ISMS).
ISO/IEC 27002 provides a set of information security controls that:
— mitigate risk associated with the preservation of confidentiality, integrity, and availability of information
within the scope of the ISMS, that is the stated purpose of ISO/IEC 27001;
— prevent, or detect the occurrence of information security events, or mitigate the effects of such events;
— mitigate risk associated with a variety of risk contexts.
This document is specifically concerned with the attributes of information security controls, but the concept
and approach can be applied to attributes of other types of controls, e.g. privacy controls, health and safety
controls, environmental protection controls and financial controls.
In principle, such an application of attributes can be applied to other information security issues. If the
attributes given in ISO/IEC 27002 are undesirable for the organization’s purpose, the organization can
create its own, as exemplified by the guidance provided in this document.

© ISO/IEC 2026 – All rights reserved
v
International Standard ISO/IEC 27028:2026(en)
Information security, cybersecurity and privacy protection —
Guidance on using information security control attributes
1 Scope
This document provides guidance on the use of information security control attributes specified in
ISO/IEC 27002. The guidance given in this document is generic and is intended to be applicable to all
organizations, regardless of type, size, or nature.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security
controls
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 27002 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
attribute
quality or feature of something or somebody
Note 1 to entry: An attribute is a quality or feature regarded as a characteristic or inherent part of something.
Note 2 to entry: An attribute can include information about the intended use.
3.2
attribute value
particular form or quantity, or a category or range of quantities, for a given attribute (3.1)
3.3
custom attribute
attribute (3.1) developed or adopted by the organization or the users which differs from those given in
ISO/IEC 27002
4 Abbreviated terms
RTP risk treatment plan
© ISO/IEC 2026 – All rights reserved
5 Overview on attribute approach
5.1 Concept of attribute
5.1.1 General
ISO/IEC 27002:2022, 4.2 states that the organization can use attributes to create different views. These
views are different categorizations of controls. This document provides additional attributes to address
specific needs identified by the organization.
5.1.2 Attributes given in ISO/IEC 27002
The concept of attribute was adopted by ISO/IEC 27002 to group the controls in ways other than the four
themes: organizational, people, physical and technological. See ISO/IEC 27002:2022, 4.2 for five examples of
the attributes with attribute values given for each of the 93 controls of ISO/IEC 27002.
EXAMPLE In the case of ISO/IEC 27002:2022, 5.1 “Policies for information security”, the attribute value(s)
identified for the attribute “Control type” is “#Preventive”.
This type of attribute with attribute values can be used to search ISO/IEC 27002 for controls which have the
attribute values that the risk owner or other personnel of an organization is looking for.
The attribute values are independent of the organizations and the context within an organization where the
control is applied.
ISO/IEC 27002 is a catalogue of controls, i.e. a collection of information security controls. ISO/IEC 27002 can
show factors relevant to an organization’s information security risks that had not been entirely identified
and analysed, including those relating to the attributes identified in, or those omitted from ISO/IEC 27002.
ISO/IEC 27002 can show factors relevant to an organization's information security risks through the
attributes and their values identified for each control. Analysing the attribute value of the control can help
organizations understand the controls in ISO/IEC 27002 and seek additional controls if necessary.
For example, the control for threat intelligence (see ISO/IEC 27002:2022, 5.7) involves feeding information
about threats through the organization’s risk analyses in order to improve understanding, and thus leads
to better informed decision-making. The five control attributes and their attribute values are identified as
shown in Table 1.
Table 1 — Five control attributes and their attribute values
Information security Cybersecurity con- Operational capabil-
Control type properties cepts ities Security domains
#Preventive #Confidentiality #Identify #Threat and vulnera- #Defence
bility management
#Detective #Integrity #Detect #Resilience
#Corrective #Availability #Respond
The two columns on the left (“Control type” and “Information security properties”) state that the threat
intelligence control is relevant to all possible values of those two attributes listed in ISO/IEC 27002:2022,
4.2. However, several attribute values of the "cybersecurity concepts", "operational capabilities" and
"security domains" attributes listed in ISO/IEC 27002:2022, 4.2 are not used for this control. Answering the
question of why they are not listed involves exploring the control in some depth. Therefore, considering any
control’s attributes or characteristics can lead to developing innovative approaches, e.g. searching for other
controls with similar, complementary or contrasting attributes, or additional attributes that are relevant to
the necessary controls.
© ISO/IEC 2026 – All rights reserved
5.1.3 Additional attributes introduced in this document
Most of the additional attributes introduced in this document are related to finer controls, which can be an
implementation of the ISO/IEC 27002 controls. Examples of such controls are:
— a rule for restricting the use of privately owned devices;
— employment of information security specialists;
— use of online education tools;
— use of mechanical or smart locks of doors;
— use of network firewalls, intrusion detection and prevention systems (IDPSs) or security appliance
systems;
— application of a system development method.
Examples of additional attributes with potential attribute values are given in Clause 6.
This type of attributes with attribute values are typically used in information security risk treatment
processes. The attribute values of an attribute in relation to a control can indicate:
— to what extent the control modifies the risk;
— the level of cost in implementing the control;
— other characteristics of the control in relation to the risk treatment process.
In contrast to the attributes and attribute values given in ISO/IEC 27002, the attributes and attribute values
introduced in this document are context dependent. An example is a “cost attribute” with potential attribute
values #low, #moderate, #elevated (see 6.17). A control “use of mechanical or smart locks of doors” can have
different values depending upon where the control is implemented in the organization’s facilities.
5.2 Custom attributes
5.2.1 General
Organizations can define their own custom attributes by setting some attribute values to an attribute that
they want to monitor or measure, due to the specific needs of the organization. These custom attributes can
be defined by modifying the attribute values provided in ISO/IEC 27002. Attribute values can be modified
using the following methods:
— integrating attribute values;
— dividing an attribute value;
— refining an attribute value;
— renaming an attribute value;
— adding a new attribute value.
For example, for the organization operating a key information infrastructure, the following custom attribute
values can be developed based on the values of “cybersecurity concepts” given in ISO/IEC 27002:2022, 4.2
c): analysis and identification, security protection, testing and evaluation, monitoring and early warning,
proactive defence and incident handling.
More examples of custom attributes are provided in Clause 6.
An alternative way to construct custom attributes is to use the method based on the event-consequence
scenarios. This method is described below in 5.2.2.

© ISO/IEC 2026 – All rights reserved
The custom attributes used in this method are applicable to the controls within the context of an identified
event-consequence scenario. They are not the same as the example attributes presented in ISO/IEC 27002,
which are independent of the event-consequence scenarios in which the control is used. For example, it is
possible to construct custom attributes through an event-consequence scenario and two controls.
The sample event-consequence scenario is:
a) a laptop is stolen (the event);
b) the new possessor extracts personally identifiable information from its storage device (the consequence).
The sample controls are:
c) a rule of the organization restricting taking laptops out of its premises;
d) encryption of the storage device in laptops.
The rule of the organization is a preventive control. It can reduce the risk of theft of a laptop and hence
reduce the possibility of the event-consequence scenario occurring.
Encryption of the storage device is a reactive control. It does nothing to prevent the theft of a laptop (a),
i.e. occurrence of the event-consequence scenario, but reduces the possibility of information leakage (b). A
reactive control is a control that does not reduce the possibility of the identified event-consequence scenario
being triggered, but reduces the risk associated with the scenario.
Similarly, the consequences that are associated with an event-consequence scenario are specific to
a given scenario and are not the same as the “information security properties” example attribute in
ISO/IEC 27002:2022, 4.2 b). In the event-consequence scenario context:
e) confidentiality (C), integrity (I), and availability (A) do not universally apply to all event-consequence
scenarios
f) an organization can wish to address consequences other than C, I, and A, e.g. cost.
For example:
g) Only C and A are associated with the theft of a laptop: the owner no longer has access to the information
on it (i.e. loss of availability), which can be revealed to the new possessor (i.e. loss of confidentiality).
The laptop has a value and therefore, cost can also be associated with it.
h) Only A is associated with loss of internet connectivity or other events that cause loss of information
access.
The preventive control stated in c) can only affect C, A, and other consequences (and do so simultaneously),
whereas the reactive control stated in d) affects in general one or other consequence (e.g. either C or A).
These gaps can be filled in by designing a custom control that has the required attributes. For example, if
there is a missing reactive control in an event concerning power failure, a custom control can be designed
to take effect following a power failure. The consequence of the non-availability of information following a
power failure can require additional controls including controls that cannot be readily available. Therefore,
controls should be designed and customized to reduce the risks caused by the missing control(s).
5.2.2 Event-consequence scenario method
The first step is to choose an event of concern. Positive benefits can arise from working on the following
process as a team. The method can include the following steps:
a) determining the consequences of the event;
b) estimating the likelihood of the occurrence of this event, the severity of the impact, and thus completing
the risk assessment for this event;

© ISO/IEC 2026 – All rights reserved
c) assuming this risk is unacceptable, proceed to develop the associated risk treatment plan:
1) writing down the organization’s response (or what it should do) to,
2) preventing the occurrence of the event (i.e. the preventive controls),
3) detecting the occurrence of the event (i.e. the detective controls),
4) limiting the consequences of the event (i.e. the reactive/corrective controls);
d) referring to the controls in ISO/IEC 27001:2022, Annex A as well as the control text in ISO/IEC 27001:2022,
the purpose, the different guidance, the example attribute values in ISO/IEC 27002, and eventually
controls from other standards or frameworks ensuring organization-defined implementation are
captured;
e) if there are any gaps, designing a custom control to fill the gap. The purpose of the custom control should
be evident from the location of the gap (e.g. a gap in the detect section for some event XYZ implies that a
control must be designed to detect when XYZ occurs);
f) finalizing the plan as a story to make it easier to understand and review.
When designing and implementing the system, the team can consider options to mitigate the information
security risks to an acceptable level. As an example, for such design and implementation options, business
data can be located in different places:
g) the data can be stored on a server and shared through remote access among persons who need to use it.
h) the data may be downloaded from the server to the devices.
Option g) can give higher confidentiality, while option h) can provide higher availability and usability.
5.3 Benefits from using attributes
5.3.1 General
This subclause provides examples of identifying benefits from using attributes for controls and examples
of managing information security risk. Attributes provide different views through categorizations of the
ISO/IEC 27002 controls. Each attribute includes information about the intended use.
Organizations can elect to create additional attributes or further customize the attributes by using them for
other purposes. Organizations can use attributes to facilitate the selection of controls to be implemented
or verified. They can use attributes to facilitate control implementation or to facilitate the development of
potential automated solutions to either help implement the controls or verify their implementation, or both.
Typical activities involving control attributes throughout the organization's overall information security
risk management process, are shown in Figure 1, although others are also possible. These activities are
outlined in some detail in the following subclauses:
— determining control requirements (see 5.3.2.1);
— improving risk treatment plan (see 5.3.2.2);
— defining the relationship between standards (see 5.3.3);
— strengthening information security (see 5.3.4);
— achieving a balanced suite of controls (see 5.3.5);
— maximizing the value of existing and proposed controls (see 5.3.6);
— reviewing and assessing controls (see 5.3.7);
— viewing audience’s perspective (see 5.3.8);

© ISO/IEC 2026 – All rights reserved
— improving privacy through attributes (see 5.3.9).

Figure 1 — Example of benefits from using attributes
5.3.2 Creating robust risk treatment plans
5.3.2.1 General
Determining controls according to their attributes or attribute values can address particular requirements.
For example, if maintaining the confidentiality of sensitive information is a primary control objective arising
from the risk analysis, controls tagged with the “confidentiality” attribute value can be potential candidates
for selection.
The analysis required and discussion arising from determining attribute values has significant benefits. For
instance, the act of measuring the “architectural fit” for various controls shows that the security architecture
is intended to influence decisions about which controls are or are not appropriate for the organization.
This analysis considers the organization’s requirements as a whole, rather than considering each control
in isolation for specific situations. Given a choice between a control with a high degree of architectural fit
and one that would be a poor fit, the one with better architectural fit can carry more weight in the decision
subject to other relevant factors, i.e. other objectives or requirements and control attributes.
Reviewing controls categorized by other attributes can suggest alternatives or additional (supplementary
or complementary) controls, such as tamper-resistant enclosures (physical control) housing cryptographic
modules (technological control), plus key management and other associated processes (people, procedural
or administrative controls).
The converse also applies, in that controls can be de-selected or rejected from the necessary controls on
the basis of having undesirable attributes or attribute values. It is possible that organizations are unable
to implement certain controls due, for example, to the lack of resources to implement and maintain
them. If selected controls are not implemented, then an assessment of the risks associated with the non-
implementation of the controls is performed. Controls with similar attributes can be redundant and can be
candidates for rationalization, unless there are redeeming features. It is also important to bear in mind the
risk related to the de-selection or rejection of such controls.

© ISO/IEC 2026 – All rights reserved
The organization, as a preliminary action, should clearly adopt its own set of control attributes, in a way that
is consistent with the overall information security risk management framework and process. These control
attributes can comprise standard and custom selected ones.
The organization should also set a priority to address attributes (depending on its own specific context, such
as business, operational, regulatory aspects, risk appetite, and budget limitations). That priority to address
attributes can be a scale and is fundamental in determining which controls are selected.
5.3.2.2 Improving risk treatment plan
Determining which attributes are relevant to a situation involves understanding the organization’s
information security risks, control objectives, risk appetite, risk tolerance and resources available to treat
the risks. The associated information gathering and analysis can involve someone preparing a brief outline
of the most relevant and useful attributes to prompt consideration of various aspects. This outline is a form
of a risk treatment plan (RTP). Workshops, discussion papers and brainstorming through collaborative
working and online tools can be appropriate for some organizations at different stages in the process. A
study or review can generate additional, deeper insight, but management is responsible for deciding whether
the benefits justify the investment and choose the most valuable approaches.
Approaches should be viewed in the context of ongoing activities to monitor and respond to ever-changing
information security risks. Approaches should maintain the organization’s information security controls.
This can be done through an information security management system as specified in ISO/IEC 27001 or a
similarly structured framework that can be developed using guidance such as ISO/IEC TS 27110 or the NIST
[9] [15]
Cybersecurity Framework or the NIST Risk Management Framework.
Risk assessment and corresponding risk treatment planning are processes with many functions and values
that differ based on a given situation. However, it is possible that necessary controls are not adequately
identified. Therefore, management can review the organization’s suite of information security controls
to determine whether the corresponding necessary controls are adequately understood, identified and
whether they are fully satisfied. A review of applicable control attributes can lead to reconsidering some of
the controls to avoid overlooking risks and to improve their suitability.
5.3.2.3 Aim of attributes using event consequence scenario
5.3.2.3.1 General
According to ISO/IEC 27005:2022, the way in which controls modify risk depends on whether they are:
— preventive, i.e. a control that is intended to prevent the occurrence of an information security event;
— detective, i.e. a control that is intended to detect the occurrence of an information security event;
— corrective, i.e. a control that is intended to limit the consequences of an information security event.
Thus, preventive and detective controls can reduce the likelihood of the occurrence of an information
security event but leave the severity of the consequence unchanged. In contrast, corrective controls cannot
modify the likelihood of the occurrence but can reduce the severity of the consequence. When designing an
RTP, it is important to use the correct type of control, depending on whether the intention is to modify either
likelihood or consequence, or both.
Moreover, RTPs can be made resilient to control failures if they use an appropriate mix of preventive,
detective and corrective controls, given that:
— detective controls can continue to mitigate the risk if the preventive controls fail;
— corrective controls can continue to mitigate the risk if the detective controls fail;
— preventive controls can reduce the likelihood before the corrective controls are used.
5.3.2.3.2 addresses some of these concerns.

© ISO/IEC 2026 – All rights reserved
5.3.2.3.2 Basic strategy
To start, an organization chooses an event of concern. It develops an RTP using the method described in
5.2.2. It then determines if RTPs can be used to mitigate similar risks, and if so, expands the RTP accordingly.
For example, if the organization chooses the loss of a laptop as its initial event, it can find that the same RTP
applies in the case when the event concerns the theft of a laptop, or the loss or theft of any mobile device.
The organization reviews controls not yet considered and proceeds in a similar manner until all the controls
in ISO/IEC 27001:2022, Annex A have been considered. Either they will have been included in one or more
RTPs or the organization will now be able to justify their exclusion.
5.3.3 Defining the relationship between this document and both ISO/IEC 27002 and ISO/IEC 27005
ISO/IEC 27002 provides a list of controls to be addressed through the risk treatment plan as described
in the controls in ISO/IEC 27001:2022, Annex A. The control purposes and control guidance specified in
ISO/IEC 27002 can also assist in the identification of related controls. ISO/IEC 27002 describes the control
attribute concept with examples and encourages organizations to develop and use its own custom attributes.
ISO/IEC 27005 describes the event-consequence approach to risk assessment and risk treatment and how
robust RTPs can be constructed.
The use of custom attributes presented in this subclause provides an important linkage between
ISO/IEC 27002 and ISO/IEC 27005, which supports the development of information security and risk
management policies. The implementation of custom attributes potentially results in a stronger information
security posture. In fact, using control attributes can help to build a consistent and robust information
security risk management framework and process, according to ISO/IEC 27005.
A reference set of control attributes, both standard and custom, should be clearly established in the
information security risk management context, and should be systematically applied, within the overall
chosen set of controls. These can act as a decision support for control selection in the information security
risk treatment, to build consistent and a robust RTP.
A priority scale for attributes should also be defined, based on the organization’s specific context, such as
business, operational, regulatory aspects, risk appetite and budget limitations. That priority attribute scale
is also a fundamental decision support for a consistent control selection.
Possible custom attributes that give value to a robust RTP can include:
— cost attribute (used mainly in a cost/benefit balance between prospective losses and the cost of control,
in a risk acceptance criterion);
— assurance attribute (related to control performance indicators for measuring control effectiveness);
— implementation attribute (related to control status, whether it is operational, in the course of development,
or awaiting financial support).
5.3.4 Strengthening information security
Understanding the controls and their requirements (i.e. security objectives, mitigation strategy, and
approach) can lead to better, more informed decision-making. These decisions are critical when determining,
implementing and managing controls.
Where some control descriptors use words with fixed characteristics, attributes can be modified or exploited
in order to enhance their utility and value in a specific application. For example, formalizing controls
typically involves analysing and documenting them in more detail. It can also involve reviewing, testing and
authorizing the controls, thereby increasing their quality, strength and robustness. Procedural controls can
be deliberately deformalized in order to improve overall effectiveness by giving personnel more latitude in
practice and making compliance less costly.
Organizations can group related controls together, perhaps distinguishing core from peripheral or
supporting controls. A security engineering approach can involve designing a control system with the

© ISO/IEC 2026 – All rights reserved
appropriate combination of controls from scratch, or reviewing and redesigning an existing arrangement
(e.g. following one or more incidents caused by control inadequacies).
It is reasonable to expect that information security risk levels are reflected in the strength, robustness and
assurance of the mitigating controls. Significant information security risks typically require mitigation
with a level of protection commensurate with the risks. Conversely, mitigation controls for relatively
minor information security risks are not necessary if other forms of risk treatment are more appropriate.
The strength-related control attributes should broadly align with the risk levels. Obvious anomalies (e.g.
highly robust controls addressing negligible risks) can be investigated, potentially leading to updates in
the controls framework. This can be a powerful approach, both from the information security risk and
information security management perspective and from the business perspective.
5.3.5 Achieving a balanced suite of controls
Categorizing and reviewing sets of controls by analysing the various attributes can be adopted in order
to satisfy a particular requirement in some areas and excesses elsewhere, which have been previously
overlooked.
ISO/IEC 27002 notes that the control types attribute (#Preventive, #Detective, #Corrective) can be used as a
means for the organization to check the balance of determined controls; for example, there can be adequate
controls to detect information security events but insufficient controls to prevent information security
incidents.
Technological controls with rather few physical and procedural controls can indicate a bias in the way
controls have been selected, leading to weaknesses in the control framework and opportunities for
improvement.
Analysis can reveal gaps in the organization’s information security control suite, such as over-reliance on
necessary controls required for compliance with imposed obligations and a lack of discretionary controls
satisfying the organization’s own internal/business objectives.
Seeking balance illustrates the value of considering the organization’s information security controls as a
whole.
5.3.6 Maximizing the value of existing and proposed controls
Whereas a given information security control can be adopted in order to satisfy a particular requirement,
its attributes can suggest other potential applications. For example, an organization can be using a public
key infrastructure (PKI), principally for authentication purposes, categorizing it as a technological integrity
control. But the same PKI can also have value for encryption, categorizing it as a technological confidentiality
control.
Some information security controls have very specific purposes that mitigate a particular aspect of a specific
information security risk. Multi-purpose or multi-functional controls, in contrast, can potentially be applied
to mitigate various aspects of numerous information security risks. Applying multi-functional controls in a
wider range of applicable scenarios can yield more value from them where it makes business sense to do so.
The organization gains expertise and experience in the process, becoming more familiar with the control’s
strengths and weaknesses in practice.
Applying certain controls for the same or different purposes leads to standardization, emphasizing
and exploiting their similarities, whereas the contexts and control requirements vary. The controls in
ISO/IEC 27002 for instance, are commonplace but not universally applicable. In a situation where some of
the standard controls can be inappropriate, some can be more valuable if modified to suit the circumstances,
and additional supplementary custom controls not listed by the standard can be required. Using control
attributes to clarify the requirements and select the most appropriate controls can be a valuable approach.
5.3.7 Review
...