Adsic ND 133684 en PDF

Information Security Standards
Abu Dhabi Government

Ve r s i o n 2 . 0
This document is developed by:
Information Security Standards
Abu Dhabi Government
Version 2.0
H.H. Sheikh Khalifa Bin Zayed Al Nahyan
President of the United Arab Emirates - Ruler of Abu Dhabi
H.H. General Sheikh Mohamed Bin Zayed Al Nahyan
Crown Prince of Abu Dhabi - Deputy Supreme Commander of the UAE Armed Forces
Chairman of Executive Council - Abu Dhabi
Document Control
Version Release Date Summary of Changes
1 15 March 2009 Initial Publication Release
2 23 January 2013 Revisions as per Section 7
Summary of Key Changes
This document has been developed and is maintained by the Information Security
Programme of the Abu Dhabi Systems and Information Centre.
Question and Comments should be directed to:
ad-infosec@adsic.abudhabi.ae
Contents
Document Control

1 Executive Summary 2
2 Introduction 4
2.1.1 Overview 4
2.1.2 Purpose 5
2.1.3 Scope 5
2.1.4 Applicability 6
3 Information Security Framework 8
4 Compliance and Enforcement 13
5 Application of this Version 14
6 Related Documents 15
6.1 Alignment with Related Government Standards 15
6.2 Supporting Documents 15

7 Summary of Key Changes to these
Standards Since the Last Version 16
7.1 Changes to Control Standard Structure 19
8 Implementation Priorities - When & How to Apply Controls 25

8.1 When to Apply Controls 25
8.2 How to Apply Controls 27
Contents
9 Mandatory vs. Recommended vs. Suggested Controls 28
9.1 Areas Requring Entity Interpretation 31
10 Common vs Tailored Security Controls 31
11 Alignment to International Standards 33
12 Abu Dhabi Information Security Standards 34

12.1 Information Security Governance 34
12.2 Information Security Risk Management 62
12.3 Human Resources Security 85
12.4 Third Party Supplier Security 96
12.5 Information Security Training, Awareness & Communication 104
12.6 Information Asset Management 114
12.7 Physical And Environmental Security 132
12.8 Information Systems Design, Development & Testing 147
12.9 Identity & Access Management 193
12.10 Information Operations Management 214
12.11 Information Security Incident Management 280
12.12 Information Systems Continuity Management 305
Appendicies 319
Appendix A – Acronyms 321
Appendix B – Definitions 323
Appendix C – Classification Matrix 329
Appendix D – V1 to V2 Standards Mapping 331
Appendix E – V2 to V1 Standards Mapping 347
1 Executive Summary
Information Security is a real-word concern, not a theoretical construct. The
discipline is not an end itself – it serves a much wider and more significant purpose.
Implemented effectively, it can be instrumental in government delivering better
quality, more robust and higher value services that citizens and residents can place
their trust in.
This second version of the Abu Dhabi Information Security Standards is part of the
Government’s on-going journey of learning and improvement. Since the launch of
the Information Security Programme in June 2009, government Entities have made
progress in making Information Security part of their management toolset.
On-the-ground insights have been gained by Abu Dhabi Government Entities

(ADGEs) following deployment of the first version. This cycle of learning has been
reflected in this substantially revised and updated version. The standards have been
reengineered with the following ten principles in mind:
1. Executive level ownership and oversight of Entity Information Security

programmes should drive success.
2. Ambitious but realistic goals should be set for Entity Information Security
programmes. Ones that allow for discernible and lasting improvements in the
management of government information assets.
3. Entity Information Security Programmes should be resourced in a manner, and

to a level, that makes the achievement of programme objectives practical.
4. Information Owners should assume an informed position concerning the security

of their information assets.
5. A holistic view of Information Security controls should be taken that reflects

key inputs i.e. risks applicable to the Entity, its compliance obligations and its
business requirements.
2 Information Security Standards

6. Entities should be informed as to what they should tangibly be doing in
implementing Information Security. They should be provided clear, real-world,
practitioner-oriented inputs, ahead of abstract theories.
7. Control Standards should be given a suggested prioritisation that recognises that

Entities have finite time and resources to expend on Information Security.
8. Entities should implement a range of control types (e.g. preventive and detective)
to ensure that a balance and harmony is achieved in the Entity’s control set; and
an accurate picture of the Entity’s security and risk profile is achieved.
9. Emphasis should be given by Entities to ‘designing in’ security, rather than

retrofitting it after the fact.
10. The classification of information assets should shape the prioritisation and design
for Information Security Controls.
The executive management teams of all Abu Dhabi Government Entities are asked
to recognise that their vision, leadership and commitment will be the ultimate
determinants in whether their organisations effectively embrace the aims of these
Standards; and whether they achieves effective protection of assets given into
their trust. The stewardship of government services is a significant and privileged
responsibility. It is a responsibility that can be effectively realised by executives, staff
and suppliers being committed to Information Security best practice.
These Standards function in support of the Abu Dhabi Information Security Policy.
The Policy is approved by the General Secretariat of Abu Dhabi, confirming its
sponsorship of the Abu Dhabi Information Security Programme.
3
2 Introduction
2.1.1 Overview
Information Security provides protection to the information assets owned and
managed by the government of Abu Dhabi. It seeks to support the government’s
vision of delivering services that are effective, efficient and which add tangible value
to the emirate. The application of Information Security allows the government to
promote an environment of trust that supports the transaction of the government’s
business. The achievement of effective Information Security requires active
awareness and on-going participation on the part of government Entities, citizens,
residents and business partners.
The modern world is one in which there is an ever growing use of information assets
and an ever increasing dependency on the information systems on which those
assets reside. The government of Abu Dhabi has actively embraced that reality via
a continuing programme of e-Government initiatives. Such initiatives present a
range of potential benefits but also bring with them new, complex risks that must be
identified in a timely way and managed effectively.
The Control Standards contained within this document provide an expression of

the Information Security expectations that the government has upon Entities and
business partners handling classified government data. The Control Standards
are expressed in twelve domains of Information Security that are interrelated and
mutually supportive.
Entities have the responsibility of understanding the Control Standards defined

within this document and applying them effectively in the protection of the
confidentiality, integrity and availability of their information assets.
This version of the Abu Dhabi Information Security Standards contains Control
Standards that are new or changed from the earlier version. Consequentially, each
Entity is obligated to fully inform itself as to these changes and to make adjustments
as appropriate to their Information Security programme.

2.1.2 Purpose
The Abu Dhabi Information Security Standards document is intended to guide
Entities and business partners in areas requiring focus for the application of
Information Security controls. Adherence to the Control Standards supports
Information Security controls being deployed consistently across Abu Dhabi
Government Entities (ADGEs).
The Abu Dhabi Information Security Standards document is supported by

accompanying guidance documentation (see Section 6 Related Documents for an
overview of these items). The Standards should be read in conjunction with these
supporting materials.
2.1.3 Scope
The Abu Dhabi Information Security Standards provide definition of both
management and technically oriented control standards across twelve domains,
these being as show below.
Information Security Governance
Information Security Risk Management
Human Resources Third Party

Security Security
Information Security Information Asset

Training, Awareness Management
and Communication
Physical & Information Systems

Environmental Design, Development
Security & Testing
Identity and Access Information Systems

Management Operations
Management
Information Security Information Systems

Incident Continuity
Management Management
Figure 1: Abu Dhabi Information Security Domains
The functional scope of this document extends beyond Information Technology,

to address the broader scope of Information Security. The disciplines shown above
are assumed to be interrelated and interdependent.
5
2.1.4 Applicability
Control Standards defined within this document have applicability to Abu Dhabi
government personnel, contractors and other third-party organisations with
responsibility for the creation, handling, storage, transmission and destruction of
Abu Dhabi government information assets, including information systems and other
equipment.
Entities have the responsibility for ensuring that controls are deployed in sufficient
depth and range to ensure Control Standards are achieved effectively, in relation to
the information assets for which they (or their nominated suppliers) have a custodial
responsibility. This shall include assets that are provided by, or managed for, the
Entity by third-party organisations.
Government Entities are required to use security controls to meet Information

Security requirements. Selecting, designing, implementing and managing an
appropriate set of controls is critical in the effective management of risk.
Three levels of categorisation of information systems have been defined that have
a bearing upon control applicability. The following definitions of categorisation are
used when selecting a level of control to apply.
Low The information system is categorised as LOW if the loss

of confidentiality, integrity, or availability is expected to
have limited adverse effect on the Entity’s operations,
assets, or personnel. Although the Entity would be able to
perform its primary functions, it would do so in a noticeably
reduced capacity. This degradation in mission capability
could also result in minor loss of organisational assets and
possible loss of personal privacy.

Medium The information system is categorised as MODERATE
if the loss of confidentiality, integrity, or availability is
expected to have a serious adverse effect on the Entity’s
operations, assets, or personnel. This translates to a
significant degradation in the organisation’s mission
capability and ability to perform primary functions, and
could result in significant financial loss and damage to
organisational assets.
High The information system is categorised as HIGH if the loss

of confidentiality, integrity, or availability is expected to
have a severe or catastrophic adverse effect on the Entity’s
operations, assets, or personnel. In the event of a security
breach, the organisation would be unable to perform one
or more of its primary functions, resulting in major financial
loss or severe damage to organisational assets.
7
3 Information Security Framework
The Abu Dhabi Information Security Standards are intended to support government
Entities in implementing and embedding an Information Security framework. The
framework benefits Entities in achieving an integrated perspective on Information
Security capabilities that need to be deployed and maintained.
The diagram below defines the key elements of such a framework.
A summarised definition of the concepts is given in the table below. The individual
components are then expanded upon in more detail within relevant areas of the
Control Standards section of this document.
Abu Dhabi Other Entity

Information External Enterprise
Security Obligations Architecture
Standards
Programme Level
3 5 8 9 10
Entity
Activities
Information Entity Enterprise Domain- Common

Security Security Security Specific Control
Programme Policy Architecture Plans Catalogue
Plan
4 6
Key Information
Security Asset
Indicators Inventory
(System+Data)
System Level
Design & Implementation Methodology

Activities
11 12 13 14 15
System System System System
Information Security
Security Security Security Authorisation
Requirements Security Implementation Testing
Design
16 17 18
Activities
Ongoing
Risk Management - Change Management - Continuous Monitoring
Figure 2: Abu Dhabi Information Security Framework

Item Framework Component Description Primary
No. Level Related
Control
Standard(s)
1 Programme Abu Dhabi This document – it provides All

Information definition of Information Security
Security Control Standards that an Abu
Standards Dhabi Government Entity (ADGE)
is expected to follow.
2 Programme Other External In addition to the Information SG.5
Obligations Security Standards, Entities
are obligated to consider other
external authorities that will have
a bearing upon their Information
Security programmes i.e. laws
and regulations of the U.A.E and
the emirate of Abu Dhabi.
3 Programme Entity The Entity’s high-level plan SG.1

Information outlining its long term (multi-year)
Security approach for implementing and
Programme managing Information Security.
Plan The Plan will address both
how the Entity will achieve its
compliance obligations and also
how it will address the risks and
requirements that are unique to
its own environment.
The Programme Plan should

articulate specific, measurable
goals and the key initiatives that
will be resourced and undertaken
to achieve them.
4 Programme Key Security Performance indicators that SG.9
Indicators allow an Entity-level Information
Security Governance Committee
(ISGC) to determine how well
the objectives set within the
Information Security Programme
Plan are being met.
9
No. Level Related
Control
Standard(s)
5 Programme Entity The documented expression SG.8

Information of management intention and
Security Policy the communication of expected
behaviours in support of the
Entity’s Information Security
Programme.
6 Programme Information Information assets will encompass AM.1/
Asset both information systems and AM.6
Inventory data. Information assets may be
housed on information systems
and also held in other forms (e.g.
on paper).
The asset inventory confirms

key attributes of the information
asset that aid its secure
management.
7 Programme Enterprise Where the Entity has implemented SG.7
Information Enterprise Architecture, this
Security will serve as a key input to the
Architecture formulation of its design for
Information Security controls.
8 Programme Enterprise A blueprint for the Information SG.7
Information Security controls not specific
Security to any individual information
Architecture system.
9 Programme Domain- Delivery-oriented plans that relate SG.1
Specific Imple- to building out control capabilities
mentation in specific disciplines. These plans
Plans will provide the specifics for how
individual capability areas defined
within the Enterprise Information
Security Architecture will be
implemented.

No. Level Related
Control
Standard(s)
9 Programme Domain- Depending on the size of the SG.1

(Cont.) Specific Imple- Entity and the complexity of its
mentation Information Security programme,
Plans these plans may be rendered as
either free-standing documents or
as appendices to the Information
Security programme plan.
10 Programme Common A summary of the current SG.11
Control implementation status of non-
Catalogue system specific Information
Security Controls available within
the Entity.
The Enterprise Information

Security Architecture referred to
above communicates the target
state for the common controls;
the Catalogue indicates their
present status. (It is possible
for both items to be rendered
in a single document, so long as
target vs. actual state are clearly
delineated).
11 System Security The security expectations that IS.1
Requirements apply that are specific to the
of Information target information system (e.g.
Systems specific business requirements for
confidentiality of the data being
hosted).
12 System Information The design confirms the IS.2
Security Information Security controls that
Design will be applied to meet the agreed
requirements for the information
system. The design will call
upon elements from either the
Common Control Catalogue or
tailored controls that are unique
to the target information system.
11
No. Level Related
Control
Standard(s)
13 System System Entities are required to implement IS.3-IS.12

Security information systems in a manner
Implementa- that it is consistent with the
tion approved Information Security
Design for that information
system.
14 System System Security testing should confirm IS.13
Security that the information system
Testing meets requirements (including
compliance obligations) and that
the deployed security controls
cannot be by-passed or subverted.
A test plan, prepared before
implementation, should guide the
testing activity to ensure that the
information system’s functioning
and security control set perform
in a manner consistent with the
approved Information Security
design.
15 System System Approval from the Entity’s IS.13
Security Authorising Official that
Authorisation testing has confirmed that the
information system’s security
design adequately addresses
requirements and relevant risks
have been adequately responded
to in order to permit the transition
of the information system to
‘production’ status.
16 Ongoing Risk Identifying, analysing and RM.1-
Management responding to risk needs to occur RM.5
throughout the information
asset’s lifecycle to ensure the
optimum configuration and
placement of Information Security
controls.

No. Level Related
Control
Standard(s)
17 Ongoing Change With its potential to introduce SG.4/

Management new risks, to alter control OM.2
requirements or modify control
specifications, change needs to be
overseen effectively throughout
the information lifecycle.
18 Ongoing Continuous Entities need to have in place SG.1/
Monitoring mechanisms that verify that SG.9/
Information Security programme OM.5
objectives are being met and that
security controls continue to be
fit for purpose. Where monitoring
identifies unacceptable deviation,
corrective action measures need
to be applied.
4 Compliance and Enforcement

All Abu Dhabi Government Entities are expected to adhere with these Standards,
in support of achieving compliance with the Abu Dhabi Information Security Policy.
Conformance with Control Standards needs to be achieved on a prioritised basis,
with the Entity making a determination of which Control Standards it will achieve
compliance with first, on the basis of:
a) its own risk profile
and
b) its available resources.
A ‘Suggested Priority’ is offered for each Control Standard within this document.
However, this is only offered as a suggestion – the Entity is still obligated to prioritise
the application its controls, in the context of it understanding its own remit, business
processes, risk profile, management decision making and capabilities.
13
Once the Entity has reached the point of addressing a specific Control Standard,
Control Specifications associated with that Control Standard are assigned one of
three designations: Mandatory, Recommended or Suggested. These designations
guide the Entity as to the expected level of compliance. They are explained in
Section 7.1 of this document.
The Entity should maintain its own self-assessment capabilities to determine if

compliance is being maintained. It is anticipated that this capability will be achieved
via role of the Entity’s Chief Information Security Officer (CISO), with their work
being overseen by the Entity’s Information Security Governance Committee (ISGC).
The Abu Dhabi Systems and Information Centre (ADSIC) has the primary and
definitive responsibility for determining if compliance to these Standards has been
achieved. Personnel and Entities found to be non-compliant with these standards
may have their access to information systems and data revoked. They may also
be subject to disciplinary and/or criminal actions, as determined by government
policies, regulations and the laws of the United Arab Emirates.
Information systems (including network devices) found to be non-compliant with

these Standards may be restricted from processing government data and from
connecting to government networks.
Abu Dhabi Government Entities are responsible for ensuring that third-party
suppliers engaged on their behalf are acquainted with, and contractually committed
adhering to relevant elements of these Standards and the Entity’s Information
Security programme.
5 Application of this Version

This is the second version of the Abu Dhabi Information Security Standards. A number
of Entities have already embarked on their Information Security programme aligning
to the first version of this document.
Appendix D of this document provides a mapping of content from version 1 of the

standards to version 2 and Appendix E provides a mapping in the other direction.
These resources should aid Entities in determining their level of compliance with the
new version of the control standards.
Following release of this version of the Standards, future ‘point’ releases will occur
to provide minor updates ahead of the next full version i.e. version 3. Updates to
Control Standards will be shown within the ‘Control Version History’ field of the
impacted Control Standard.

6 Related Documents
6.1 Alignment with Related Government Standards

The Abu Dhabi Information Security programme is one of a number of initiatives
sponsored by the Executive Council of Abu Dhabi.
These Standards are intended to provide a coherent perspective on multiple

disciplines relevant to the management of Information Security by Abu Dhabi
Government Entities. The Standards do not have the intention of replacing or
replicating other government standards.
Where government-wide Policies and Standards exist in related areas then these
should be regard as the predominant reference and any contradictions should
be resolved in their favour. Examples of potential government-wide Standards
including:
• Enterprise Risk Management

• Audit Management
• Incident Management
• Business Continuity Management
Absent government-wide Standards in any associated areas, then Entities may

reasonably assume that these Information Security Standards serve as a predominant
reference until such time as such other materials are approved and published.
6.2 Supporting Documents

The Information Security Standards are one Abu Dhabi
Information
component within the wider Abu Dhabi Information Security Policy
Security Programme. The Standards have an
interface to, and dependencies upon, other
key publications within the government-wide Information
Security Standards
programme. The diagram illustrates the key
publication types that have a relationship
with the Information Security Standards. Information
Information
The publications supporting these Security Guides
Security Templates
Standards can be requested via the & Checklists
following email address:
AD-InfoSec@adsic.abudhabi.ae Figure 3: Abu Dhabi Information
Security Programme Publications
15
7 Summary of Key Changes to these
Standards since the Last Version
Since the publication of the first version in June 2009, the Abu Dhabi Information
Security Standards have been adopted across a range of government Entities. The
learning taken from these deployments, changes in Information Security best
practice and assessment by subject matter experts has informed the design of this
second version of the Abu Dhabi Information Security Standards.
The key changes in this version of the document are as summarised below.
Change Description
Greater Orientation This version of the document has a stronger

Toward Tangible weighting toward specific, implementable, verifiable
Control Definition steps in support of an Entity’s Information Security
programme.
New Information Two new domains have been added:

Security Domains - Information Security Governance
This is intended to provide the structural framework
needed within Entities to ensure the effectiveness
of their Information Security programmes.
The ‘Strategy and Planning’, ‘Policy and Standards’

and ‘Performance Management’ sections of
version 1 have been subsumed into the new domain
of Information Security Governance.
- Third Party Supplier Security

Given the range of ways in which Entities make use
of third-party service and product providers, specific
attention is paid to how these stakeholders should
be integrated into Entity’s Information Security
programme.

Change Description
Revised Information The following domains from version 1 have changed

Security Domains as follows:
- Information Systems Acquisition, Development
and Maintenance
The name of the domain has changed to:
‘Information Systems Design Development and
Testing’ to give a clearer focus on upstream activities
i.e. those which occur prior to information assets
and systems moving to an operational/production
state.
With a closer focus on just design, development and

testing activities, the following movements have,
as a consequence, been made:
• Acquisition elements of this section have moved
to ‘Third Party Supplier Security’.
• Maintenance elements of this section have
moved to ‘Operations Management’.
- Awareness and Training & Communications

and Outreach
These domains have been combined into the new:
‘Training, Awareness and Communication’ due to
their common focus on achieving the outcome of
stakeholders being aware of Information Security
responsibilities and key issues.
- Business Continuity Management

The domain has been renamed to ‘Information
Systems Continuity Management’. End-to-end
Business Continuity Management, with its focus on
the continuation of business processes, is beyond
the scope of these Information Security Standards.
- Communications and Operations Management

The name of the domain has been changed to
‘Operations Management’. Communications as a
technical discipline has both upstream (i.e. design
and test) as well as downstream (i.e. support and
maintenance) dimensions.
17
Change Description
Removal of Non Version 1 control standards content describing the

Entity Related responsibilities of ADSIC, ADAA and any other party
Content beyond government Entities has been removed.
This has been done with the intention of making the
Standards more closely focused on the needs and
priorities of government Entities themselves.
Removal of Security The concept of Security Objectives has been removed
Objectives from version 2 as it was not recognised as making a
substantial contribution to the effectiveness of security
deployments. Entities now have the requirement to
set their own tangible and measurable objectives for
their Information Security programme (please see the
Information Security Governance section).
Movement of Content Some control standards have been moved between
Between Security sections in order to achieve a more logical and mutually
Domains supportive set of controls in a given area of focus.
Appendices D and E provide mappings of v1 control
standards to their v2 counterparts, and vice versa.
Addition and Following review, some controls have been removed
Removal of Controls and some new controls added. This being with the
intention of ensuring that the Standards provide
a sufficiently broad and coherent expression of
Information Security expectations.
Appendix D & E confirm if a control is new in version 2

or if a version 1 control has been retired (either
completely or via substitution with a different control).
Clarified Definition of As per v1, all Control Standards are mandatory in
What Constitutes a nature. This is consistent with the approach found
Control Specification in international standards and other best practice
sources.
To address requirements that are specific and unique

to Abu Dhabi, the decision has been taken to augment
these Standards with Control Specifications that
have a variable applicability, depending upon the
categorisation of the information system at hand.
Point 8 in Section 7.1 below expands upon the concept

of Control Specification applicability.

7.1 Changes to Control Standard Structure
In addition to the above changes, the structure and content of Control Standards has
also been revamped, as illustrated. The key shown below provides guidance on the
individual elements of the Control Standard’s new structure.
XX.4 1 Control Name 2 Version 3 2.0

Suggested P2
4
Priority
Control Control Standards definition 5

Standards
Control Type 6 q Directive a Preventive

q q Detective q Corrective
Control Specification 7 8 L M H
XX.4.1 Control Specification Definition M M M
XX.4.2 Control Specification Definition S R M
XX.4.3 Control Specification Definition S R R
Control Version History 9

V1.0 Control version history
Control 10 List of Abu Dhabi Control that this control depends on

Dependencies
References 11 List of related references that are used or/and related

to this control
19
Key Change Description
1 Simplified The numbering of controls has been simplified,

Clause Numbering to aid ease of navigation and ease of referencing.
The new numbering format is:
DOMAIN.CONTROL STANDARD NUMBER
An example being:
AM.1
This simply means that this is the first control in
the Information Asset Management section of
the Standards.
A Control Specification within a Control Standard

inherits its numbering from its parent control
standard. So:
AM.1.2
Simply means that this is the second element
of Control Specification applicable to the AM.1
Control Standard.
2 Control Name The title of the control standard.
3 Control Version The current iteration of the control. (Note: where

a Control Standard from the previous version of
the document had contained similar content,
but a different name, the Control Standard will
show in this version as version 1, rather than
version 2).
4 Control A suggested priority has been offered for

Prioritisation determining the order in which control standards
should be addressed. This exercise has been
informed by best practice and practitioner
experience.

4 Control Three Priorities have been allocated:

Prioritisation
(Cont.) PRIORITY 1 – The essential first steps that
should be taken by any organisation to provide
a base level of preventive and detective controls.
PRIORITY 2 – Intended for government Entities

that have implemented their foundational
controls and who wish to augment these with
capabilities tailored to their environment.
Priority 2 controls will likely be deployed
by organisations that have stabilised their
Information Security governance, risk
management and security funding activities,
allowing them to deploy controls in a discerning,
targeted way.
PRIORITY 3 – Higher-level controls, likely

deployed by Entities with mature and well-
resourced Information Security Management
Systems that are afforded significant executive
priority and which are well integrated with other
management disciplines. Sophisticated controls
will be mutually supportive and deployed in
manner where there is measurable business
benefit.
The prioritisation model is not intended to be

prescriptive. The actual implementation priority
will be contingent upon the organisation’s remit,
objectives, business processes and risk profile.
5 Control Standards The security outcomes needing to be realised in

order to achieve Standards compliance and to
ensure adequate security.
21
6 Control Types The concept of control types has been introduced

to help Entities determine whether there is a
balance in their control set.
DIRECTIVE CONTROLS - Express management

expectations of behaviours and activities
required for risk avoidance and risk mitigation, in
support of the Information Security programme.
(Example controls: Information Security policy,
security-related schedules within third-party
supplier contracts).
PREVENTIVE CONTROLS - Avoid security-

related threats from being manifested, or limit
their potential to achieve their fullest potential
impact.
(Example controls: network firewalls, segregation
of duties, email spam filtering).
DETECTIVE CONTROLS - Identity vulnerabilities

that are either being exploited, or potentially
could be exploited, to realise a threat.
(Example controls: system log analysis, network
vulnerability scanning).
CORRECTIVE CONTROLS - Contribute to

the return of an information asset to its last
known good state, with the view to removing
vulnerability, or reducing potential impact to an
acceptable level.
(Example controls: information system reimaging
to an approved configuration baseline, lessons
learned reporting).

7 Control One or more elements of control implementation

Specification specifying how a given control standard may be
met.
Control specification content has been made

modular in this version of the Standards.
It has been separated into more digestible
components, with each being given a unique
identifier to aid referencing. It is anticipated
that this approach will support Entities in
determining the tangible steps they will need to
take to achieve compliance with a given control
standard.
8 Control The expected level of compliance is now

Specification communicated, alongside each Control
Applicability Specification.
The three levels of applicability are:
MANDATORY
The specific element of Control Specification is
expected to be addressed in full, at all times, by
all Entities.
RECOMMENDED
The Control Specification would typically be
anticipated to apply to the majority of Entities,
under normal circumstances. However, there
may be specific, justifiable circumstances which
make the Control Specification not applicable in
the specific situation at all, or only partially. The
Entity should be able to articulate a meaningful
and informed rationale for why the Control
Specification does not apply in the specific case
concerned.
23
8 Control SUGGESTED
Specification The Control Specification is intended as
Applicability supplementary support for those Entities that
(Cont.) are in the process of maturing and consolidating
their Information Security control set. The
Control Specification is discretionary only – it is
anticipated that Entities may wish to consider
the specification, but are not obligated to do so.
Section 9 provides more information on these

levels of applicability.
9 Control Version The Control Version History section is intended to

History serve as a place to record any changes to Control
Specifications that have occurred since the last
major release of the Standards. In version 2, this
field is left empty. However, where there are any
minor changes published between version 2 and
version 3, this is where they will be recorded.
10 Control Other Control Standards or process components

Dependences which the given Control Standard has a direct
reliance upon.
11 References External best practice references beyond the

content of this document. Such references
encompass supporting materials within the
Abu Dhabi Information Security Programme,
international standards and recommendations
from professional bodies. The cited references
provide Entities with the opportunity to read
further in the area concerned.
Note: in version 1 of the Abu Dhabi Information Security Standards, Control Enhancements
were intended to act as an additional level of control specification for information systems of
‘Medium’ and ‘High’ categorization. The concept has been removed from this version of the
Standards. The right-hand columns of the Control Standard format above show that the Control
Specification applicability now serves a similar purpose.

8 Implementation Priorities -
When & How to Apply Controls
8.1 When to Apply Controls

Government Entities are expected to exercise discretion and good judgment in
determining what Information Security controls to implement, where to implement
them, how and when.
The decision-making process will be influenced by:
• The mandate and business objectives of the Entity.

• The business processes that the Entity transacts.
• The value and sensitivity of the government information asset’s within the
Entity’s custody.
• The complexity of the Entity’s supply chain e.g. how much of its business process
is dependent upon third-parties.
• The range, depth and potential impact of risks faced by the Entity.
• The resources available to deploy in building, implementing and managing
security-related controls.
• The knowledge, skills and experience of Entity personnel in relation to
Information Security.
• The legacy of what controls have already been deployed.
Additionally, the Entity will be guided by two elements from these Standards that
help determine an appropriate sequence of control implementation. These being:
Suggested Priority
Section 7.1 defines the suggested priorities that have been allocated to control
standards.
These priorities are meant only to guide the Entity – they are not intended to
be prescriptive. Due to its own unique circumstances, the Entity may rightly
determine that a different sequence of priority is merited.
The priorities are meant to provide a logical sequencing of controls to help

answer the questions: ‘where do we start?’ and ‘where should be go next?’
25
Suggested Priority (Cont.)
The highest priority controls have the underlying themes of:
1) Setting clear management direction for what is expected of the Entity’s

Information Security capabilities.
2) Deploying basic preventive controls to stop very common threats from being
manifested.
3) Implementing a foundational level of detective controls to help the Entity

understand its true risk profile and to gain an appreciation of what’s really
happening in relation to its information assets.
Control Specification Applicability
Section 7.1 defines the levels of Control Specification applicability relevant to a

given control i.e. ‘Mandatory’, ‘Recommended’ or ‘Suggested’.
The interrelationship between control priority and control specification

applicability may be summed up as:
Control specification Applicability confirms the expected level of control application

i.e. what must, should and may be done. Control Prioritisation provides a prompt
for how quickly a given control standard might be addressed.
It is preferable to have a balance in the Entity’s security control set and for
controls to be mutually supportive. In this context, an Entity should not seek
to implement all elements of Control Specification within a Priority 1 control
(including ‘Suggested’ items) if this would be to the detriment of applying
‘Mandatory’ elements of other, lower priority, controls.

8.2 How to Apply Controls
These Standards impose compliance obligations upon Entities. However, discretion
and good judgement are required as to what resources are applied, and in what
configuration, in order to achieve those obligations and to implement the additional
controls judged necessary by the Entity.
Entities need to determine what organisation structure best suits achievement of

its own Information Security Programme Plan. Examples where decision making is
required include:
• Whether the mandate of the Information Security Governance Committee should

be addressed by a free-standing committee or incorporated into the functioning
of an already existing committee.
• Whether the role of Chief Information Security Officer (CISO) should be full or
part time.
• Whether the CISO role should be rendered at corporate-level or within an

individual business unit (e.g. the IT department).
• Whether the level of risk, programme goals and level of activity provide
justification for additional security-related resources, beyond the CISO.
• What weighting should be applied to Information Security roles i.e. technical vs.
managerial.
• What minimum level of experience, competence and qualifications post-holders

require in order to successfully achieve the goals of the Entity’s Information
Security Programme.
A one-size-fits-all approach is not practical, given the diversity of Abu Dhabi

Government Entities, in terms of their remit, structure, risk profile and resources.
In the above context, security domains described within these Standards should
not be taken to be equivalent to specific organisational roles or units. For example,
obligations applicable to Information Security Incident Management may be
undertaken by a function that has responsibility for all types of incident across the
Entity. Similarly, Asset Management obligations do not imply that separate and
demarcated Asset Management provisions need to be created solely for the purpose
of achieving alignment with the Asset Management expectations of these Standards.
27
9 Mandatory vs. Recommended
vs. Suggested Controls
The Control Standards described within this document show three levels of expected
applicability i.e. in relation to control specification:
• Mandatory
• Recommended
• Suggested
These terms are explained in section 7.1 of this document. They are intended to
help Entities have a clear view as to what the minimum expectations are of them, in
relation to Information Security.
The level of applicability correlates to one of the three categorisation levels

defined in section 2.1.4 i.e. Low, Medium and High. As an example, an element of
control specification may be Mandatory for a High categorisation system but only
Recommended for Medium and Low categorisation systems.
The level of Control Specification application is expanded upon in the table below.
Applicability Level Mandatory

Description
‘Mandatory’ Control Specification elements are expected to be fully complied

with by the Entity, in full, from the time that the given Control Standard is
implemented.
Due the constraints of finite time and resources, it is recognised that an Entity
will not be able to achieve compliance with all ‘Mandatory’ components from
the outset of its Information Security programme. The Entity’s Information
Security Programme Plan should demonstrate the prioritisation for control
implementation, mapped to the relevant Control Standards within this
document.
Suggested priorities have been proposed against each Control Standard within
this document but Entities are expected to apply to management discretion,
based upon their business priorities and unique risk profile.
For any Control Specification not designated as ‘Mandatory’ there is a degree of

discretion and judgment which needs to be applied by the Entity’s management.

Impact Upon the Entity’s Risk Management Activities
Mandatory control elements need to be implemented, irrespective of the results

of the Entity’s risk management activities. They represent core areas of capability
in the given discipline of Information Security.
Applicability Level Recommended

Description
Control Specification elements that ADSIC assessment teams would typically

expect to see in place. However, there is the understanding that circumstances
specific and unique to the Entity may mean that the given Control Specification
is either not applied at all, or not applied in full. However, such exemptions would
need to be on the basis of defined criteria that can be justified by the Entity. (It
should not be interpreted that ‘Recommended’ Control Specification elements
are merely advisable to implement).
Risk analysis will help determine if the Entity’s unique circumstances make
the given control type applicable or not applicable in the specific setting being
analysed. Risk management can provide the Entity with informed and coherent
justification for the de-scoping of Recommend Control Specifications – where
appropriate.
Applicability Level Suggested

Description
Primarily oriented toward Entities which have established a robust foundation

of core controls and which are now on a journey of continuous improvement.
Just because they are not mandatory does not mean that Control Specifications
of this type should be ignored. Entities should actively consider their suitability
and relevance when deploying their Information Security controls. They have
the potential to enhance the protection of the Entity’s information assets.
However, for non-mandatory control elements the Entity is obligated to make
an evaluation of the cost of control implementation against the anticipated
protection benefit.
Risk analysis may provide a justification for whether suggested controls should
be applied within a given Entity.
29
Entities should appreciate that the Abu Dhabi Information Security Standards provide
a common base of security definition that allow minimum levels of protection
to be achieved and to facilitate the secure sharing of information across areas of
government.
The Standards are not an end in themselves. Achieving the minimum necessary
compliance with them should not be regarded as a primary goal. The Standards –
and assessments made against them – are merely instruments intended to support
the broader and more significant goals of:
• Informed and responsible information ownership and usage
• Protection of government information assets to a level appropriate to their value

and the risks posed to them
• Engendering and maintaining stakeholder confidence in the capability of

government to deliver sufficiently secure and reliable services to the emirate of
Abu Dhabi
• Protection and enhancement of the reputation of Abu Dhabi, at home and abroad
• Maximising the return on investment in information assets and systems, through

the enhanced support afforded to their availability, confidentiality and integrity
as part of a broader contribution to service quality
In the above context, government Entities have the primary responsibility for
ensuring that they have the appropriate depth and range of Information Security
controls deployed. In some circumstances, the Entity may determine that the
control definition required exceeds what is found in these Standards.

9.1 Areas Requiring Entity Interpretation
Government Entities are required to engage with these Standards, and the best
practice principles they convey, in a discerning manner. In some instances, this
requires Entities to make a judgement about how management and technical
controls should be implemented.
Within the Standards, terms such as “appropriate”, “timely”, “important” and

“competent” have been used. These require a subjective decision to be made on the
part of the Entity. An example being:
“Assigned auditors should be competent to undertake specialist Information Security

audit”.
(From SG.10.4)
For such Control Specifications, the Entity is obligated to determine for itself what
constitutes “competent” in the context of its own business processes, risks and
deployed technologies. It is neither practical nor advisable for these Standards
to specify absolutes across all areas of an Entity’s engagement with Information
Security. For areas requiring subjective decision making, the Entity should be able
to show, during assessment, that the judgement it applied was thoughtful and took
advantage of all necessary inputs.
10 Common vs. Tailored Security Controls

Government Entities should take the opportunity to review how their obligations to
these Standards can be met. As would be true in the implementation of any control
set, there is the need to effectively balance time, cost and quality constraints. Entities
should seek opportunities that allow them to implement the right Information
Security controls, at the right time and in the right way.
One way to improve the speed and quality of Information Security control
implementation is to build a common Enterprise Information Security Architecture
that is then leveraged by multiple information assets and systems. This requires the
Entity to take a holistic view of its Information Security requirements, rather than
merely considering controls on a system-by-system or service-by-service basis.
31
Common security controls have the greatest potential to help the Entity balance
expenditure on Information Security vs. effectiveness of the controls deployed.
However, for common controls to be effective, their range of potential uses needs to
be carefully evaluated. A control that is ideally suited for Service A may be much less
optimised for Service B, when it is introduced a year from now.
Examples of common controls that multiple systems and services could potentially
leverage include:
• Single Sign-On mechanisms for user authentication
• Password self-service mechanisms for user authentication
• Security Event and Incident Management tooling. (Possibly making use of a

common platform that then has technology-specific add-ons)
• An eLearning platform hosting a range of Information Security-related content
• Unified processes and procedures e.g. one common Change Management

process applied to all services and systems
The application of common controls will depend on the risk context and the business
need of the Entity. There will be circumstances where a tailored security control (i.e.
one that is specific to the individual service or system) is necessary, justified and
preferable.
The Entity has the obligation to understand its Information Security needs, threats and
vulnerabilities and to tailor its control set appropriately. The Abu Dhabi Information
Security Standards are intended as a starting point for informed engagement within
the Entity.
Tailored controls will be ones that are specific and unique to the target information
asset. They will be utilised where there is no common control is available, or where
the available common control is not fit for the specific purpose. ‘Tailored’ controls do
not necessarily indicate that the control has been heavily customised. Such might
be a standard, off-the-shelf control type from a vendor, but which has been acquired
specifically in reference to a target information system. Equally, a version or copy
of an existing common control may be adapted or configured in a way that makes it
unique to the specific control requirement.

Examples of tailored controls would include:
• Authentication tokens specifically deployed for access to a highly sensitive

systems
• A biometric access control infrastructure specifically implemented for access to

a data centre environment
11 Alignment to International Standards

The development of these Standards has been informed by reference to, and use of,
international best practice. The following references having served as the primary
sources:
• ISO/IEC 27001: ‘Information technology — Security techniques — Information

Security management systems —Requirements’.
• ISO/IEC 27002: ‘Information technology — Security techniques — Code of practice

for Information Security management’.
• National Institute of Standards & Technology (NIST) Special Publication 800-53:

‘Recommended Security Controls For Federal Information Systems & Organizations’.
• Other NIST Special Publications applicable to specific domains of Information

Security.
• SANS Institute best practice recommendations for control application.
The ADSIC publication: “Abu Dhabi Information Security Standards-

ISO27001 Mapping” provides a confirmation of how ISO 27001 requirements
correspond to control standards within this document. This will be of
assistance to Entities preparing for initial certification against ISO 27001,
or for those seeking to maintain an existing certification.
It should be noted that while the Standards have made reference to the above
sources, this document does not intend to duplicate them. This version of the
Abu Dhabi Information Security Standards is intended to be tailored to the specific
priorities, culture and configuration of the government of Abu Dhabi.
33
12 Abu Dhabi Information Security
Standards
12.1 Information Security Governance
SG.1 Information Security Programme Version 1.0
Management Suggested P1
Priority
Control The Entity shall develop and disseminate an organisation-wide
Standards Information Security programme plan.
Control Type a Directive

q q Preventive a Detective
q q Corrective
Control Specification L M H
SG.1.1 The Entity should agree and communicate M M M
specific, measurable and scheduled goals for its
Information Security programme. Goals should
reflect the programme’s obligation to support:
• Business strategy and priorities
• The Entity’s management of its security-
related risks
• Compliance obligations to these Standards
and other relevant laws and regulations
• The promotion of a security-oriented
organisational culture within the Entity
SG.1.2 The Programme Plan should provide an overview M M M

of the requirements for the Information Security
programme in meeting agreed upon programme
goals; and a description of the security
programme management controls and common
controls in place or planned for meeting those
requirements.

SG.1.3 The Programme Plan should define and allocate M M M
roles and responsibilities, confirm management
commitment, facilitate coordination among
organisational Entities, and support compliance
with these Standards.
SG.1.4 The Programme Plan should be approved by M M M

the Entity executive with responsibility and
accountability for the risk being incurred to
organisational operations.
SG.1.5 The Entity’s Information Security Programme M M M

Plan should be aligned to the annual objectives
specified for the government-wide Abu Dhabi
Information Security Programme.
SG.1.6 The Programme Plan should be reviewed regularly M M M

by the Entity’s senior management and revised as
necessary to address organisational changes and
problems identified during plan implementation
or security control assessments.
SG.1.7 The Entity should monitor progress against M M M

its Information Security Programme Plan and
take corrective action where milestones are not
met or anticipated benefits are not realised as
originally envisaged.
35
SG.1.8 In support of its Information Security Programme M M M
Plan, the Entity should develop supporting plans
to build out specific capabilities in defined areas.
These subsidiary plans may include (but may not
be limited to):
• Information Asset Management
• Identity and Access Management
• Risk Management
• Training and Communications
• Information Security Incident Management
• Information Systems Continuity Management
• Operational Readiness
• Physical and Environmental Management
The deliverables defined within these plans

should be aligned with the Entity’s Security
Architecture (see SG.7 Enterprise Information
Security Architecture). After their implementation
their status should be recorded in the Entity’s
Common Control Catalogue (see SG.11 Common
Control Catalogue).
Subsidiary plans may be rendered either as free-

standing documents or as appendices to the
Entity’s Information Security Programme plan.
SG.1.9 The Entity should make a determination of M M M

the inputs needed to deliver against agreed
Information Security-related plans and should
allocate the resources required to protect
information assets.
The Entity should establish a discrete line

item for Information Security in organisational
programme management and budgeting
documentation.

SG.1.10 The Entity should monitor expenditures on M M M
Information Security, against the agreed budget,
and evaluate the effectiveness of its investment
in Information Security controls.
SG.1.11 The Entity should consider the categorisation of M M M

services when allocating its Information Security
budget (with highest categorisation services
meriting priority for budget allocation).
Control Version History
Control None
Dependencies
References • NIST Special Publication 800-53 Revision 3:
o PM-1 Information Security Program Plan
o SA-1 System And Services Acquisition Policy and
Procedures
o SA-3 Life Cycle Support
• Abu Dhabi Information Security Governance Guide
• Abu Dhabi Information Security Programme Plan Template
37
SG.2 Information Security Categorisation Version 2.0
Suggested P1
Priority
Control The Entity shall categorise government services according to
Standards their risk profile.

q q Preventive q Detective q Corrective
SG.2.1 The Entity should define the purpose, scope and M M M
boundaries of each service in terms of attributes that
include: the business process(es) it supports and
the list of information systems it is composed of.
SG.2.2 The Entity should categorise each Government M M M

service owned by the Entity in accordance with
the approach defined within the Abu Dhabi
Government Service Security Categorisation
Guide.
SG.2.3 The Entity should document the security M M M

categorisation results, including supporting
rationale, in the Information Security Design
for any information system utilised by the
service.
Control
Dependencies
o RA-2 Security Categorization
• Abu Dhabi Information Security Asset Management Guide

SG.3 Information Security Organisation Version 1.0
Suggested P1
Priority
Control The Entity shall define resources and develop an organisation
Standards appropriate to its Information Security activities.

q q Preventive
a q Detective q Corrective
SG.3.1 The Entity should appoint a Chief Information M M M
Security Officer (CISO) with the mission,
resources and empowerment from the Entity’s
executive management to coordinate, develop,
implement, and maintain an organisation-wide
Information Security program.
SG.3.2 The role of the CISO should be supported by M M M

additional Information Security-related roles,
as required to achieve the deliverables and
outcomes defined within the Information
Security Programme Plan.
Dependent upon the size of the Entity, its service

portfolio and its risk profile, the Information
Security organisation may require one or more
Information Security personnel, in addition to the
CISO. The additional personnel may undertake a
range of management, functional and technical
duties that support the CISO in delivering against
the Information Security Programme Plan.
SG.3.3 Information Security personnel should have skills, M M M

qualifications, experience and competencies
commensurate with the requirements of their
positions.
39
SG.3.4 The Information Security organisation should M M M
have adequate organisational positioning to
ensure effective direction, accountability and
empowerment for the programme. The reporting
line for the Information Security organisation
should allow for timely and direct communication
of key security issues to senior management.
Information Security personnel should not be
prevented or discouraged from reporting threats,
vulnerabilities and control status.
SG.3.5 A regularly meeting (i.e. at least quarterly) Infor- M M M

mation Security Governance Committee should
be convened to provide independent oversight
and support for the work of the Information
Security organisation. The committee should
be represented by senior representatives from
across the Entity’s executive team.
The Chief Information Security Officer should

serve as the Secretary of the Committee,
assuming its delegated authority to undertake
day-to-day liaison with other parties (including
ADSIC) on matters relating to the Entity’s
Information Security Programme.
Control
Dependencies
o PM-1 Information Security Program Plan
o PM-2 Senior Information Security Officer
• Abu Dhabi Entity Information Security Roles &
Responsibilities

SG.4 Security Programme Change Version 1.0
Priority
Control The Entity shall manage change within its Information Security
Standards programme to ensure continued compliance to regulations and
on-going management of identified risks.

q q Preventive q Detective
a q Corrective
SG.4.1 The Entity’s Information Security Governance M M M
Committee should approve all changes to the
Information Security Programme Plan.
SG.4.2 The Entity should establish a baseline for its M M M

Information Security Programme Plan, with
proposed changes to the plan being analysed for
impact.
SG.4.3 Changes to the Information Security Programme R R R

Plan should be coordinated with the organisation-
wide Change Management capabilities of the
Entity to ensure on-going alignment between
Information Security and other organisation
initiatives.
Control None
Dependencies
References • Abu Dhabi Information Security Governance Guide
41
SG.5 Legal and Regulatory Requirements Version 1.0
Suggested P1
Priority
Control The Entity shall identify and implement appropriate controls
Standards to address legal and regulatory requirements applicable to

SG.5.1 The Entity should review and align its Information M M M
Security activities with the Abu Dhabi Information
Security Programme, which in turn will ensure
alignment to relevant emirate and federal-level
laws and regulations.
SG.5.2 Where the Entity identifies a contradiction M M M

between the Abu Dhabi Information Security
Programme and relevant laws or regulations, it
should highlight the disparity to ADSIC.
SG.5.3 Important Entity records shall be protected from M M M

loss, destruction and falsification, in accordance
with statutory, regulatory, contractual, and
business requirements.
SG.5.4 The Entity should implement procedures that M M M

support the protection of Intellectual Property
Rights (IPR) applicable to its own information
assets and which respect legitimate ownership
rights of other parties (e.g. third-party suppliers).
Procedural definition for IPR should encompass
multiple potential formats for information assets
(e.g. software, information system designs,
digital data, documentation).

Control
Dependencies
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 15.1.2 Intellectual Property Rights
o 15.1.3 Protection of organizational records
43
SG.6 Framework for Information Version 1.0
Exchange Agreements Suggested P3
Priority
Control The Entity shall establish a framework for determining what
Standards information it will exchange with other parties and how these
exchanges will be managed.
Control Type q Directive

a q Preventive q Detective q Corrective
SG.6.1 Agreements should be established for the M M M
exchange of information and software
between the Entity and external parties. These
agreements should be formally documented and
should confirm:
• The terms under which such information and
software is sent, received, stored and used.
• How exchanges of sent and received

information will be logged.
• How the terms of exchange agreements will be

audited.
• How long records applicable to exchange

agreements will be retained.
SG.6.2 Formal exchange policies, procedures, and M M M

controls should be in place to protect the
exchange of information.
SG.6.3 Information exchange agreements between M M M

the Entity and other Abu Dhabi government
organisations should confirm:
• The purpose for which the information type is
being provided.
• The classification of the information being

shared.

SG.6.3 • The parties within each organisation that are M M M
(Cont.) authorised to review, modify, augment or
delete the information.
• The reporting obligations that will apply in

the event that the information is disclosed to
unauthorised parties beyond the parties to the
agreement.
• The reporting obligations that will apply in

the event that the information is disclosed to
unauthorised parties beyond the parties to the
agreement.
SG.6.4 Information exchange agreements between M M M

the Entity and third-parties that are not part
of the government of Abu Dhabi (e.g. external
vendors) should incorporate elements a) to d) in
SG.6.3 above. In addition, information exchange
agreements with non-Abu Dhabi government
third-parties should additionally confirm:
• The penalties and consequences (e.g. contract
termination) that will potentially apply in
the event of unauthorised distribution of the
exchanged information to non-authorised
parties.
• The restrictions that will apply (e.g. the

avoidance of information being shared with
sub-contractors without the Entity’s prior
written permission).
• The timeline for the shared information being

retained by the third-party and the obligations
to purge the information after a stated period.
45
SG.6.4 • The intellectual property rights that will apply M M M
(Cont.) to the exchanged information.
Any information exchange agreement with a

vendor should be included within the enforceable
contractual terms defined between the Entity
and the vendor.
Control AM.3 Classification of Information Assets

Dependencies
o 10.8 Exchange of information
o 10.8.1 Information exchange policies and procedures
o 10.8.2 Exchange agreements

SG.7 Enterprise Information Security Version 1.0
Architecture Suggested P3
Priority
Control The Entity shall develop an Enterprise Information Security
Standards Architecture that provides a blueprint for a unified set of
common controls, applicable to information assets.

SG.7.1 The Enterprise Information Security Architecture M M M
should identify the principle areas of control
application required by the Entity to:
• Achieve its compliance obligations.
• Address areas of most significant Information
Security risk to the Entity.
• Achieve the goals defined within its Informa-
tion Security Programme Plan (see SG.1
Information Security Programme Management).
The security architecture should encompass a

balance of directive, preventive, detective and
corrective technical controls that are mutually
supportive in pursuit of the Information Security
programme objectives.
The Enterprise Information Security Architecture

should be supported by subsidiary designs,
specific to individual information systems (see
IS.2 Information Security Design).
The current status of common controls identified

within the Enterprise Information Security
Architecture should be confirmed within the
Entity’s Common Control Catalogue (see SG.11
Common Control Catalogue). It is possible
that the Security Architecture and Common
Control Catalogue are rendered within a single
document, so long as planned vs. actual status is
clearly delineated.
47
SG.7.2 The Enterprise Information Security Architecture M M M
should be approved by the Entity’s Information
Security Governance Committee.
SG.7.3 Proposed changes to the Entity’s common M M M

Information Security controls should require a
review of the Enterprise Information Security
Architecture and any substantive change should
require re-approval by the Information Security
Governance Committee.
SG.7.4 The Enterprise Information Security Architecture R R R

should be integrated with the Entity’s Enterprise
Architecture framework (where such is in place).
Control SG.1 Information Security Programme Management

Dependencies
o PM-7 Enterprise Architecture
• Abu Dhabi IT Architecture and Standards
• Abu Dhabi Enterprise Security Template
• Abu Dhabi Information Security Common Control
Catalogue Template

SG.8 Information Security Policy Version 2.0
Suggested P1
Priority
Control The Entity shall develop, distribute and maintain an
Standards organisation-specific Information Security policy.

SG.8.1 The Information Security policy should address M M M
the scope of the Entity’s Information Security
management system, roles and responsibilities,
management commitment, coordination among
organisational functions and compliance
obligations.
SG.8.2 The policy document should be approved by the M M M

Entity’s executive management, and published
and communicated to all employees and relevant
external parties.
SG.8.3 The policy should contain a definition of M M M

Information Security, its overall objectives
and scope and the importance of Information
Security as an enabling mechanism for
information sharing.
SG.8.4 The policy should contain a statement of M M M

management intent, supporting the principles
of Information Security, in line with the business
strategy and the goals defined within the Entity’s
SG.8.5 The Information Security policy should M M M

have general applicability to all areas of the
organisation and should be augmented by
supporting instructions and guidance (e.g.
contracts, procedures, work instructions, check-
lists) as required in specific areas of activity.
49
SG.8.6 The policy should provide clear and succinct M M M
expression of management expectations
regarding what individuals and teams should
and should not do in the handling of information
assets and the use of information systems with
the view to achieving a requisite level of security-
oriented behaviours.
The policy should articulate security-related

expectations in areas including (but not
necessarily limited to):
• The governance of Information Security
• The management of Information Security-
related risk
• Ownership of information assets
• Classification of information assets
• Acceptable usage of information systems
• Use of cryptography
• Use of remote access facilities
• Use of system administration privileges and
software
• Protection of media and equipment (including
its handling and disposal)
• Hardware, Software and Network Restrictions
• Avoidance of malicious code
• Access control to information systems
(including protection of passwords and
tokens)
• Adherence to clean workspace provisions
• The Entity’s right to monitor access to
information systems and information
processing facilities
• Obligations in relation to Information Security
incidents
• Obligations in relation to engagement of third-
party suppliers

SG.8.7 The expectations articulated in the Information M M M
Security policy should be quantifiable and
traceable back to the Controls Standards of
the Abu Dhabi Information Security Standards
(i.e. this document). The Entity should be able
to demonstrate how one or more tangible
controls can or will directly achieve a given policy
expectation.
SG.8.8 The Information Security policy should be M M M

reviewed regularly (at least annually) by the
Entity’s Information Security Governance
Committee. The committee should ensure the
policy’s continued relevance, adequacy and
effectiveness. Policy review should occur more
frequently if significant business or regulatory
change occurs.
SG.8.9 Entity personnel and other users of its information M M M

systems should be required to confirm, in
writing, that they have read, understood and will
comply with the obligations articulated within
the Entity’s Information Security policy. A record
confirming the individual’s understanding and
intended compliance should be retained by the
Entity, for future reference.
Control None
Dependencies
References • ISO 27002 Information technology - Security techniques -
Code of practice for Information Security management:
o 5.1.1 Information Security policy document
• NIST Special Publication 800-53 Revision 3:
o PL-1 SECURITY PLANNING POLICY AND PROCEDURES
o 8.1.1 Roles and responsibilities
• Abu Dhabi Information Security Policy Template
51
SG.9 Information Security Performance Version 1.0
Priority
Control The Entity shall develop, report against and analyse key
Standards performance indicators relating to its Information Security
programme.

q q Corrective
SG.9.1 Information Security performance reporting M M M
should be against specific, measurable,
achievable, realistic and timetabled goals
articulated by the Entity’s executive management
team and the ADSIC Information Security
programme team. Goals should encompass
the Entity’s business needs, as well as legal and
regulatory obligations. (See SG.1.1 for more
information on goal setting applicable to the
Entity’s Information Security programme).
SG.9.2 The Entity should develop outcome-based M M M

performance metrics to measure the
effectiveness and efficiency of its Information
Security implementation and the security
controls employed in support of the programme.
SG.9.3 The Information Security Governance Committee M M M

should serve as the authorising and overseeing
body for Information Security performance
metrics. The committee should:
• Oversee the setting of performance metrics
aligned to the Entity’s Information Security
Programme plan and its compliance obligations
to the government-wide Information Security
initiative.
• Receive and analyse performance data from

information owners, information system
owners and Information Security personnel.

SG.9.3 • Report performance of the Information M M M
(Cont.) Security programme to ADSIC and other
relevant stakeholders at a frequency and in a
format specified by those stakeholders.
In his/her capacity as the Committee Secretary,

the Entity’s Chief Information Security Officer
should serve as the facilitator for ensuring that
necessary data inputs are received and reporting
outputs are produced.
SG.9.4 The Entity’s Information Security performance M M M

metrics should be aligned to the performance
indicators of the Abu Dhabi Information Security
Programme and should support the Entity
in reporting timely and accurate Information
Security status to ADSIC and other relevant
stakeholders.
SG.9.5 Security performance data should be verified M M M

by a competent and independent party that is
not directly connected with the work that is the
subject of measurement. (E.g. supplier security
performance data should not be accepted
without the Entity independently verifying its
accuracy and completeness).
SG.9.6 The level of attention given to a specific R R R

dimension of Information Security performance
should be correlated to the associated level of
risk.
SG.9.7 Information Security performance indicators S R R

should allow for management by exception,
with reporting being focused on security
performance deviation from known and expected
baselines.
53
SG.9.8 Information Security reporting should consider S S S
multiple dimensions of security performance.
These should include (but not be limited to):
• Security incident status and lessons learned
• Availability, confidentiality and integrity status
of key information systems
• Achievement against security programme
milestones
• Status of individual security-related projects
• Security testing results and status of corrective
actions
• Expenditures on security controls and the
value generated
• Security training delivery and outcomes
• Security audit results and status of associated
corrective actions
• Status of security-related threats,
vulnerabilities and issues
• System account usage and reported violations
SG.9.9 The design of Information Security metrics should S S S

consider multiple perspectives on performance,
including:
• Achievement of Information Security
programme goals
• Levels of control implementation
• The efficiency and effectiveness of
Information Security processes and practices
• The business impact of Information Security
initiatives

SG.9.10 Information Security performance reporting R R R
should be integrated with the Entity’s enterprise
performance management system, to support
alignment of the Information Security
programme with the Entity’s business strategy.
SG.9.11 The Entity’s management should promote S S S

a culture of transparency that allows,
as appropriate, for the frank and timely
communication of Information Security issues
and vulnerabilities, with the view to stimulating
dependable Information Security performance
data and an accurate perspective on the security
risks faced by the Entity.
SG.9.12 The Entity should implement continuous M M M

improvement mechanisms that are informed
by the data and analysis associated with its
Information Security metrics. The Entity’s
Information Security Governance Committee
should monitor the cost, benefit and status of
proposed and implemented improvements.
Control None
Dependencies
o PM-6 Information Security Measures Of Performance
o Section 3.3 Type of Measures
• Abu Dhabi Information Security Programme Level Key
Performance Indicators
55
SG.10 Information Security Audit Version 1.0
Framework Suggested P1
Priority
Control The Entity shall develop, disseminate, review and update an
Standards Information Security audit framework.
Control Type q Directive a Preventive

q a Detective
q q Corrective
SG.10.1 The Entity’s Information Security audit M M M
framework should address the scope, roles,
responsibilities, management commitment and
coordination required among organisational
units, in order for compliance to these Standards
and the Entity’s Information Security policy to
regularly be determined.
Information Security audit activities should

be supportive of the Entity’s Internal Audit
framework and alignment should be achieved
with the Entity’s Internal Audit Plan.
SG.10.2 Formal, documented procedures to facilitate M M M

the implement-ation of Information Security
audits should be developed and approved by an
overseeing function independent of the Entity’s
management (i.e. audit committee, chairman or
board).
SG.10.3 The overseeing function should ratify an M M M

Information Security audit plan. (This may be a
stand-alone document or a component of the
fuller internal audit plan for the Entity). The plan
should be reviewed regularly (at least annually)
by the overseeing function. In determining
the frequency and depth to which a given
information asset/information system is to be
security audited, the overseeing function should
take into account:
- The business criticality of the information
asset(s)/information system.

SG.10.3 - The classification of the information asset(s)/ M M M
(Cont.) information system.
- The threats and vulnerabilities applicable to it.
- Regulatory and other external obligations.
- Past experience of material relevance (e.g.
previous Information Security incidents
impacting upon this or similar information
assets).
SG.10.4 Assigned auditors should be competent to M M M

undertake specialist Information Security audit,
with an appropriate level of skills, experience
and qualifications in the specific domain of
Information Security being reviewed, as well as
in audit best practice. The overseeing function
should ensure that auditor profiles are specifically
relevant to the audit target (e.g. relevant
technical skills appropriate to the technology
type under assessment).
SG.10.5 Information Security auditors should be indepen- M M M

dent of the function/processes being audited to
ensure the opportunity for an objective assess-
ment to be undertaken. The reporting line for
Information Security auditors should be via the
overseeing function referenced in SG.10.2 above.
SG.10.6 The Entity’s main directive Information Security M M M

controls (i.e. Information Security Programme
Plan, Enterprise Information Security
Architecture, Information Security Policy,
Common Control Catalogue, service-specific
Information Security Designs and Information
Security-related procedures) should be updated
to take account of relevant audit findings.
57
SG.10.7 Audit results should be evidence (not opinion M M M
or impression) based and should be divided into
‘Findings’ (verified non-compliance with these
Standards and/or the Entity’s own security
policy and procedures) and ‘Recommendations’
(suggested areas for Information Security
management enhancement). Findings should
reference the specific clause(s) of the target
publication where non-compliance has been
identified.
SG.10.8 Audit results should confirm the potential risks M M M

that could be manifested due to an identified
finding not being addressed.
SG.10.9 Audit results should be classified and protected M M M

to a level at least equivalent to the information
system/information asset being audited.
SG.10.10 Information Security audit activities should M M M

be coordinated with other audit activities
within the Entity, to ensure effective reporting
on performance and compliance while also
minimising the business impact of audit.
SG.10.11 Functions subjected to Information Security M M M

assessment should actively not prepare for audit
but instead should give an accurate account of
their normal, real-world working practices.

SG.10.12 The independent overseeing function should M M M
ensure that Information Security audit findings
are addressed by management with a priority
appropriate to the identified risk. Audit results
should be made available to the Entity’s
for it to apply oversight to the application and
effectiveness of corrective actions.
SG.10.13 The entity should ensure that a sufficient M M M

range and quality of records is maintained and
protected, in order to facilitate effective audit.
Control None
Dependencies
o AU-1 Audit and Accountability Policy and Procedures
• ISO 27001 Information technology — Security techniques
— Information Security management — Requirements:
o 4.2.3 Monitor and review the ISMS
59
SG.11 Common Control Catalogue Version 1.0
Suggested P1
Priority
Control The Entity shall develop and maintain a catalogue of its common
Standards Information Security controls.
SG.11.1 The Entity should develop and maintain a M M M
catalogue of the common controls implemented
in support of its Enterprise Information Security
Architecture (see SG.7 Enterprise Information
Security Architecture). Common controls will be
those that have applicability to more than one
information system or which are not system-
related (e.g. management controls).
The control catalogue should confirm:

• The unique identifier of the common control.
• The name of the common control.
• The section of the Security Architecture that
the control relates to.
• The location of the control’s full specification
and design.
• The purpose served by the control.
• The information system(s) or other assets that
the control is currently applied to.
• The status of the control (i.e. ‘design’,
‘development’, ‘test’, ‘production’, ‘retired’).

SG.11.2 The Common Control Catalogue should be M M M
referenced when the Entity is designing new
information systems (see IS.2 Information
Security Design). The Entity should seek to
determine whether an existing control will
be sufficient to meet a given security need
applicable to the new information system.
Where its specification is appropriate to the
need, an existing common control should be used
in preference to developing a wholly new control,
applied exclusively to the individual system.
When a common control is intended to be re-

used, the impact upon the control should be
evaluated (e.g. whether it will have sufficient
capacity to accept the additional demand placed
upon it).
SG.11.3 The Common Control Catalogue may be rendered S S S

in a single document with the Enterprise
Information Security Architecture (see SG.7.1),
subject to it being possible to clearly delineate
target vs. actual status of the common controls.
Control SG.7 – Enterprise Information Security Architecture

Dependencies
References
61
12.2 Information Security Risk Management
RM.1 Information Security Risk Version 1.0
Management Planning Suggested P1
Priority
Control The Entity shall plan its interventions, and the allocation of its
Standards resources, in the management of Information Security-related
risk.
RM.1.1 The Entity’s conducting of Information Security- M M M
related risk management activities should be
undertaken in accordance with the principles,
workflow and templates defined within the
Abu Dhabi Information Security Risk Management
Guide.
Risk will be defined as: “an uncertain event or

set of events which, should it occur, will have an
adverse effect on the achievement or maintenance
of the desired level of security for the information
asset”.
RM.1.2 The Entity’s Information Security risk M M M

management planning should take into
consideration the categorisation of information
assets. Assets of a higher categorisation, and
those co-located with such assets, will merit
more extensive risk management interventions
than other asset types.
RM.1.3 The Entity should develop an Information M M M

Security Risk Management Plan that addresses,
as minimum, the following areas:
• Confirmation of the organisation’s level of risk
tolerance in relation to Information Security
risk. (In other words, what level of risk the
Entity is prepared to accept in the transaction
of its Information Security programme).

RM.1.3 • The methodology that will be used to M M M
(Cont.) undertake risk management activities. (Unless
otherwise agreed with ADSIC in advance, the
method used will conform to that defined
within the Abu Dhabi Information Security Risk
Management Guide).
• The risk reporting thresholds and reporting

practices that the Entity has set (e.g. what
severity of risk will be reported to whom, when
and via what channels and in what manner).
• Priority areas for risk identification,

analysis and response/treatment (i.e. which
information assets, services and technologies
merit the most substantial risk interventions).
These priorities should be expressed in the
plan as a series of distinct risk identification
and assessment exercises that will take place
during the life of the plan.
• The roles and responsibilities that will apply

in the implementation and oversight of
Information Security risk management within
the Entity.
• Resources that will be deployed for the

conducing of risk management activities.
• How segregation of duty conflicts will be

avoided in the conduct of risk management.
• The budget allocated to risk management and

how it will be spent.
• The schedule for the conducting the phases of

the risk management lifecycle described in the
other Control Standards within this section.
63
RM.1.3 • How risk management will be integrated M M M
(Cont.) within other Information Security disciplines
within the Entity.
• The frequency with which the changing

risk profile of information assets will be re-
assessed.
The Information Security Risk Management Plan

should be subsidiary to, and supportive of, the
Entity’s Information Security Programme Plan.
The Information Security Risk Management

Plan should be authorised by the Entity’s
Information Security Governance Committee.
The plan should be maintained in alignment
with changes within the organisation and should
be re-approved by the Committee when major
changes are proposed for the plan.
RM.1.4 The Entity should ensure that it puts in place the M M M

necessary procedures, checklists and templates
in order to conduct its risk management activities.
RM.1.5 The Entity’s Information Security Governance M M M

Committee should assume principle responsibility
for oversight of the Information Security
Risk Management processes. The committee
should ensure that effective integration and
harmonisation is achieved with the Entity’s
Enterprise Risk Management process (where
such is in effect).

RM.1.6 The Entity’s Information Security Risk M M M
Management process should be integrated with
its Information Systems Design, Development
and Testing capabilities and its Operational
Management capabilities. This integration will
be demonstrated through the clear expression
of necessary inputs and outputs between the
disciplines, as evidenced by relevant procedures
and associated working practices.
The Entity should recognise that Risk

Management will serve as only one of several
inputs to the design, development and testing of
Information Security controls. Other key inputs
will include:
• Business requirements for information services
and information systems
• Compliance obligations (to these Standards
and other regulations and laws of the UAE)
• Entity strategy and objectives
• Organisation culture, capabilities and resources
• Market/external constraints
RM.1.7 The Entity’s planning should recognise the need M M M

for Risk Management to be an iterative, rather
than one-time, process. Consequently, time
and resources should be allocated as required
for follow-up and repeated Risk Management
interventions, throughout the end-to-end
lifecycle of its information assets.
The Information Security Risk Management

Plan should allow for the repeating of Risk
Management activities, as required, following
changes to:
• Organisational objectives
• Organisation design
65
RM.1.7 • Compliance obligations M M M
(Cont.)
• Supporting technologies and infrastructure
• Supply chain configuration
• Service requirements
Additionally, Information Security Risk Management

planning should recognise that new or changing
risk has the potential to be manifested at key
transition points during an information asset’s
lifecycle, including at the stages of:
• Service requirements being defined
• Controls being designed and developed
• Controls being tested
• The information asset being moved to
production status
• The information asset being substantially
updated during production
• The information asset being retired or replaced
RM.1.8 The Information Security Risk Management M M M

Plan should clearly articulate the constraints
and boundaries that will apply in the Entity’s
undertaking of risk identification, analysis,
response and monitoring.
The Entity should recognise that assessment

should be undertaken in all main risk areas.
However, realistically, not all Information
Security risks can or should have a full risk
response applied. Some identified risks will be so
unlikely to occur, or be of such negligible impact,
that they do no merit on-going risk treatment.
The Entity has the obligation to deploy its
finite resources in those areas where the most
significant and substantial risks exist.

RM.1.9 The Entity’s Information Security Risk M M M
Management planning activities should take
into account relevant knowledge and capabilities
that already exist. (For example leveraging
already completed risks assessments that can
serve as input to the activity of planning Risk
Management activities for the future).
These Standards and other government

regulations and laws prescribe minimum
mandatory obligations that must be met,
irrespective of the Entity’s specific risk landscape.
Given such, a risk assessment to confirm the
need for such control types would be redundant
and would potentially expend limited resources
in an ineffective manner.
The Entity should, instead, use Risk Management

as a mechanism for determining whether its
specific business circumstances, information
assets etc. merit control definition and application
above and beyond that which is already specified
as a mandatory minimum.
Control Specification elements defined as

‘Mandatory’ within these Standards will not
be influenced by the Entity’s risk management
activities. The specific control capabilities
will need to be implemented at a priority
confirmed within the Entity’s Information
Security Programme Plan, irrespective of its risk
management interventions.
67
RM.1.9 Control Specification elements defined as M M M
(Cont.) ‘Recommended’ within these Standards may
potentially be influenced by the Entity’s Risk
Management activities.
‘Recommended’ specification relates to

capabilities that the government of Abu Dhabi
would typically expect to see in place, within
most Entities. It may be the case that the threat
the Control Specification relates to does not
have applicability to the Entity, but its Risk
Management activities would need to formally
validate this.
Control Specification elements defined as

‘Suggested’ within these Standards are
discretionary. The Entity may choose to adhere
to them, if its risk identification and analysis
suggests a need and benefit in doing so.
RM.1.10 The Entity’s executive management should M M M

provide the inputs necessary for Information
Security Risk Management to be effective.
Key determinants in whether the Entity will

be able to limit its Information Security risk
exposure to an acceptable level will include (but
not be limited to) whether:
• Information Security awareness is actively
promoted within the organisation.
• Information Security is demonstrated to be an

on-going management priority.
• Sufficient funding is provided to design,

implement and maintain a range of preventive,
directive, detective and corrective Information
Security controls.

RM.1.10 • The organisation’s recruitment, training and M M M
(Cont.) performance management capabilities support
the placement of competent practitioners
with the necessary skills, motivation and
experience to implement and manage security
components.
• An organisational culture supportive of perfor-

mance transparency, personal accountability
and collective learning is encouraged.
• Known vulnerabilities are addressed,

information assets are security hardened and
the principle of least privilege is applied.
• Avoidance of unnecessary complexity in

the design, integration and management of
information assets is supported.
• Information Security controls demonstrate a

clear and tangible correlation to one or more
specific security services that they will serve.
Control None
Dependencies
References • Abu Dhabi Information Security Risk Management Guide
• OGC Management of Risk (M_o_R)
• NIST Special Publication 800-53
o PM-9 Risk Management Strategy
o RA-1 Risk Assessment Policy and Procedures
• NIST Special Publication 800-37 ‘Guide for Applying the
Risk Management Framework to Federal Information
Systems’
69
RM.2 Risk Identification Version 1.0
Suggested P1
Priority
Control The Entity shall identify a range of risks that have a potential
Standards bearing upon the security of its information assets.
Control Type q Directive q Preventive
a q Detective
a q Corrective
RM.2.1 Before attempting to undertake a risk M M M
identification exercise, the Entity should first
define the intended scope for that activity.
In order to work within a defined and manageable

boundary, the risk identification exercise should
have a clear definition of which information asset,
cluster of assets or supporting environment will
be looked at for their potential to manifest risk.
The scope for the risk identification exercise

should be confirmed within the Entity’s
Information Security Risk Management Plan.
RM.2.2 The Entity should ensure that a sufficiently broad M M M

constituency of stakeholders is consulted in order
to identify potential risks that may adversely
affect the information asset(s) being reviewed.
Stakeholders should be capable of providing

a range of informed perspectives on risk. (For
example, asking five different representatives of
the IT function – but no business representatives
– may provide too narrow a perspective on
potential risk). The Information Owner should be
considered as a primary stakeholder from whom
potential risks are solicited, given the potential of
those risks to impact upon their business process.
Other stakeholders with relevant insights

regarding potential risks should also be consulted,
e.g. third-party suppliers.

RM.2.2 Risk identification should include input from one M M M
(Cont.) or more parties with direct, practitioner-level
experience of potential risks within the given
sphere of concern. Without such there is the
risk that Risk Management interventions will
be incorrectly calibrated, i.e. focusing only on
superficial areas, or upon risk types that are not
of most critical relevance to the Entity and its
real-world risk profile.
RM.2.3 Risks will be composed of two foundational M M M

elements:
1) Threats – the potential for harm that could be
manifested in many environments.
Example: data theft achieved via malware.
2) Vulnerabilities – a weakness, or weaknesses,

specific to the given environment that would
allow a specified threat to be realised.
Example: anti-virus signatures are not being
updated regularly within this specific organisation.
When identifying risks, the Entity should seek to

confirm:
i. Does the threat category have applicability
in the first place? (For example, destruction
of data processing facilities by tornadoes
may be a realistic threat in Kansas, but not in
Abu Dhabi).
ii. If the threat type does have applicability, is

there a known vulnerability, or a suspected
vulnerability, that could cause the threat to
be realised? (For example, no preventive or
detective security controls relevant to the
given threat have yet been deployed by the
Entity).
71
RM.2.4 The Entity may wish to consider a range of S S S
techniques in the identification of risks e.g.:
• One-to-one Interviews
• Questionnaires
• Workshops attended by multiple stakeholders
• Reference to third-party threat databases
• Use of vulnerability scanning tools
RM.2.5 The Entity should define threats in the context R R R

of the security service type that they can
potentially impair e.g. ‘there is a threat to data
integrity at rest’.
RM.2.6 The Entity should endeavour to identity a R R R

spectrum of risks that may have a meaningful
potential to undermine or impair the required
security of its information assets.
It should not be assumed that only technology-

related risks can impact upon Information
Security. Other relevant risk sources may include,
but may not be limited to:
• Organisation objectives and leadership
• Governance mechanisms
• The degree of organisational change
• The level of supply chain maturity
• Limitations of current products and services
• Skills, training and competencies within the
organisation
• Organisational culture
• Process definition and working practices
Risk identification should seek to clarify the

potential for risk arising from a variety of sources.

RM.2.7 Any effort to scan the organisation for potential S S S
Information Security-related risks should also
take the opportunity to scan for opportunities
too. During the identification exercise, examples
of good practice could be uncovered that may
have a broader potential applicability, beyond
where they are currently in evidence (e.g. team
A’s more robust access control procedures could
be leveraged by team B). By identifying such
opportunities, there is the potential to reduce
the organisation’s overall risk footprint.
RM.2.8 It may not be realistic for the Entity to analyse M M M

all Information Security risks that it identifies.
Consequently, the identified risks should be
filtered before substantive analysis is attempted.
Only those risks exhibiting a credible threat and
a substantial (actual or potential) vulnerability
should be taken forward for fuller risk analysis.
RM.2.9 Once identified risks have been filtered, risk M M M

owners and risk custodians should be confirmed,
ahead of substantive risk analysis being under-
taken. The respective roles are defined as follows:
Risk Owner – the individual with ultimate

responsibility for ensuring an appropriate
response is provided to the given risk. This will
often be either the Information Owner or the
Information System Owner (e.g. a representative
of a business unit).
Risk Custodian – the individual or group

responsible for applying a risk response on
behalf of the risk owner (e.g. a member of the IT
function).
73
Control None
Dependencies

Systems’

o RA-5 Vulnerability Scanning

RM.3 Risk Analysis Version 2.0
Suggested P1
Priority
Control The Entity shall analyse risks related to the security of its
Standards information assets to determine the criticality and priority of
those risks for attention.
a q Detective
a q Corrective
RM.3.1 In analysing its Information Security risks, M M M
the Entity should apply one of the risk ratings
described in the Abu Dhabi Information Security
Risk Management Guide.
RM.3.2 Risks with the highest analysed scores should be M M M

prioritised for risk response and treatment (see
RM.4 Risk Response and Treatment).
RM.3.3 For identified risks that have been filtered in the M M M

manner described in Control Standard RM.2 Risk
Identification, the Entity should maintain a risk
register that is conformant with the data fields
described within the Abu Dhabi Information
Security Risk Management Guide.
RM.3.4 The Entity should undertake qualitative analysis of M M M

filtered risks that it identified under the direction
of Control Standard RM.2 Risk Identification.
Qualitative analysis will seek to apply one or
more subjective evaluations in coming up with
scorings against each of the following attributes.
Probability – How likely is it that the risk will be

manifested?
Impact – What will the consequences be if the risk

is manifested?
75
RM.3.4 Proximity – If the risk were to be manifested, when M M M
(Cont.) would this be likely to occur?
The Entity should aim to describe the potential

impact in both descriptive and, where possible,
financial terms. Description in financial terms
will greatly assist the determination of cost vs.
benefit of control application (see RM.4 Risk
Response and Treatment)
Proximity will be a determinant in prioritising

risk response. For example, if the risk is of high
probability and high impact but it won’t be
manifested for another three years then the
risk response can potentially be deferred until a
later time.
Risk analysis should lead to the risk being

awarded a risk scoring aligned to those provided
within the Abu Dhabi Information Security Risk
Management Guide. The scoring should be used
to prioritise the allocation of finite time and
resources within the subsequent phases of the
Risk Management process.
RM.3.5 The Entity should refrain from undertaking S S S

quantitative analysis of Information Security
risks (i.e. running statistical, multi-pass models
of probability, impact and proximity) unless
it has the skills, tools and business need to do
so. In most cases, qualitative risk analysis will
be adequate for analysing Entity Information
Security risks.

RM.3.6 In analysing risks, the Entity should recognise R R R
that a given vulnerability may have a different
impact depending on where it might be
manifested. The environment in which the
risk could be manifested will be relevant to its
evaluation. (For example, the same vulnerability
may have greater potential impact if present on a
boundary firewall than it would if it were present
on an infrastructure element far back in the
Entity’s core network).
Control None
Dependencies
Systems’
o RA-3 Risk Assessment
77
RM.4 Risk Response and Treatment Version 2.0
Suggested P1
Priority
Control The Entity shall appropriately address Information Security
Standards risks, providing a response appropriate to their analysed
attributes.
a q Detective
a q Corrective
RM.4.1 For prioritised risks it analysed under the direction M M M
of Control Standard RM.3 Risk Analysis, the Entity
should apply a risk response. The primary risk
responses available being:
Acceptance – the Entity may choose to accept the

risk and not apply a control. This is a legitimate
risk response approach so long as:
• Doing so would not contradict or subvert any
mandatory obligations imposed by these
Standards, other regulations or the laws of
theUAE.
• The acceptance is made by the Risk Owner

and they have done so on the basis of being
sufficiently informed about the potential
outcome.
• The Risk Owner’s acceptance of the risk is

overt and formally documented. Acceptance
should imply a willingness on the part of the
risk owner to accept any consequences, in the
event that the risk is manifested.
Mitigation – the Entity would apply one more

detective and/or corrective controls, with the
aim to lessen the risk’s impact, should it be
manifested.

RM.4.1 Avoidance – the Entity may aim to avoid the M M M
(Cont.) risk by either a) eradicating the cause of the risk
or b) applying preventive controls, to limit the
potential for the risk to occur.
Transfer – the Entity may seek to transfer the

risk to a third-party. However, it should be clear
whether it is transferring risk ownership (and the
attendant impact) or just risk custodianship. For
example, outsourcing a data centre to a third-
party does not transfer the business risk of there
being a loss of data. The Entity’s contract with
the third-party might provide legal redress for
such an outcome but the impact may still be felt
within the Entity.
In the majority of cases, a third-party supplier will

be a risk custodian but risk ownership will remain
with the Entity. (See RM.2 Risk Identification for
the definition of these terms).
The risk response type preferred for a given risk

and the date on which the risk owner decided
upon it should be recorded within the risk
register.
RM.4.2 Where the Entity aims to mitigate or avoid a risk, M M M

one or more controls will need to be applied in
order to provide the required risk treatment.
The Design, Development and Testing section of

these Standards should be followed in order to
develop and deploy controls.
79
RM.4.2 For a control developed in order to address a risk, M M M
(Cont) it should be possible for the Entity to confirm:
• How will the control specifically achieve the
desired risk response?
• Is the analysed impact of the risk of such a

magnitude that compensating/secondary
controls are necessary, in case the primary
control fails, or is otherwise compromised?
• Is the cost of implementing the control the

same as or greater than the potential financial
impact if it were to be manifested? If it is then
the business justification for applying the
control should be evaluated by the Entity’s
Control None
Dependencies
Systems’

RM.5 Risk Monitoring and Corrective Version 1.0
Action Suggested P1
Priority
Control The Entity shall monitor the effectiveness of responses applied
Standards to Information Security risks; and identify new or changing risks
applicable to its information assets.
a q Detective
a q Corrective
RM.5.1 Following the application of a risk response, the M M M
Entity should monitor the effectiveness of that
response.
Its monitoring should have a particular focus on

whether:
• The control continues to function in the
manner designed.
• The control continues to effectively support

the avoidance or mitigation of the risk.
• The deployment of the control has not caused

the introduction of ‘secondary’ risks i.e. those
that arise as a consequence of the control
being implemented. (If this has occurred then
that secondary risk would need to be subject to
its own risk analysis and potential treatment).
• Any ‘residual’ risk that remains after the

control has been applied i.e. elements of the
original vulnerability that remain unaddressed.
(If such does persist then the Entity may
need to consider reworking the control or
adding additional controls – depending on the
potential impact of the residual risk).
Where control deficiencies are found, corrective

action should be applied at a priority appropriate
to the assessed scoring of the risk (see RM.2 Risk
Analysis in this section).
81
RM.5.2 For the purpose of monitoring technical risks, S S S
the Entity may wish to consider deploying
automated vulnerability scanning tools (see OM.7
Technical Vulnerability and Patch Management
within these Standards).
RM.5.3 The Entity should not assume that the risks M M M

applicable to an information asset will remain
static and unchanging throughout its lifecycle.
Original risks may change in nature, new risks
may present themselves and old risks may cease
to be of concern. Potential triggers for such may
include (but not be limited to) to:
• Modification of the information classification
• Adjustments in the profile of the asset’s usage
or management
• Change in the physical and or logical location
of the asset
• Modification of the asset’s configuration
• Adjustments in the supply chain related to the
asset
• Reconfiguration of the organisation’s design
• Changes in external obligations
(e.g. regulations and laws)
Provision should be made for regularly analysing

the risk profile of the information asset to
determine if it has changed, or is likely to change.
In such an eventually, the Entity should determine
whether the number, type and specification of
controls remains appropriate to the revised risk
profile.

RM.5.3 The Entity should ensure that its Change M M M
(Cont) Management process is mandated to consider
the potential for new or changing risk when
changes to information assets are proposed,
built, tested or implemented. Reporting
between the Change Management process and
the Risk Management process should be aligned
to ensure both disciplines are fed with relevant
and timely data.
RM.5.4 The Entity should evaluate all security incidents – R R R

but particularly Priority 1 and Priority 2 incidents
– for their risk context. The Security Incident
Management process (see the Information
Security Incident Management section of these
Standards) should be able to provide the
necessary base data for risk monitoring activities
to take place.
Risk monitoring in relation to incident

investigation should seek to address the following
questions:
• Was this incident avoidable?
• Did the incident occur because one or more

risks were not identified at the appropriate
time?

risks were incorrectly analysed? (E.g. the
decision was made to accept the risk rather
than treat it).

controls were incorrectly designed and/or
applied to treat an analysed risk?
83
RM.5.4 The Entity’s Information Security Governance R R R
(Cont) Committee should promote the notion that
risks and incidents have a causal relationship.
In other words, the Committee should promote
the understanding that security incidents are
not an inevitable by-product of day-to-day
operations but are, instead, caused by incorrectly
processed risks. The Committee should take
the opportunity to promote this correlation
with the aim of improving understanding of the
Entity’s risk profile and to enhance its future
risk identification, analysis and treatment
interventions.

RM.5.5 As a consequence of learning derived from M M M
security incidents and changes that have occurred
to the risk profile of the information asset, the
Information Security Risk Management Plan
should be updated accordingly.
Control None
Dependencies
Systems’

12.3 Human Resources Security
HR.1 Information Security Roles Version 1.0
and Responsibilities Suggested P1
Priority
Control The Entity shall identify Information Security responsibilities
Standards applicable to employees and address them in the job
descriptions, and terms and conditions of employment.

HR.1.1 Information Security responsibilities should be M M M
defined prior to employment. For roles that have
substantial involvement with the Information
Security programme and/or involve the handling
of data at classification ‘Confidential’ or above,
specific security-related responsibilities should be
defined within job descriptions and in the terms
and conditions of employment. Those terms
and conditions should include the employee’s
obligations to observe non-disclosure provisions
relevant to their access to the government’s
information security assets.
HR.1.2 The Entity should assign a risk designation to M M M

all positions, and should establish screening
criteria for the individuals filling those positions.
The Entity should review and revise the risk
designations at an Entity-defined frequency.
Control HR.4 – Segregation of Duties

Dependencies
o 8.1 Prior to employment
o 8.1.1 Roles and responsibilities
o 8.2.1 Management responsibilities
o PS-2 Position Categorization
85
HR.2 Security Screening Version 2.0
Suggested P1
Priority
Control The Entity shall screen all employees prior to and during their
Standards employment.

q a Detective
q q Corrective
HR.2.1 All candidates for employment and existing M M M
employees, should be screened (and as required,
re-screened) by appropriate authorities, with
priority being given to roles that involve the
handling of data at classification ‘Confidential’
or above.
HR.2.2 The Entity should carry out background checks M M M

with regards to the accuracy of statements
concerning job history and the validity of formal
educational and professional qualifications.
Control None
Dependencies
o 8.1 Prior to employment
o 8.1.2 Screening
o PS-3 Personnel Screening

HR.3 Terms and Conditions Version 2.0
of Employment Suggested P1
Priority
Control The Entity shall establish terms and conditions of employment
Standards for all employees.

HR.3.1 Employees should sign terms and conditions M M M
of employment that include an outline of their
Information Security roles and responsibilities.
The level to which these roles and responsibili-
ties will need to be detailed will depend upon:
• the level of privileged information access
position requires
• the risks associated with the information access
• the level of involvement the post-holder will

have in the design and implementation of the
Information Security process
Terms and conditions should seek to ensure that

conflicts of interest do not arise and must be
reported where they are suspected.
HR.3.2 The Entity should establish and make readily M M M

available to all information system users a set
of acceptable usage rules that describe their
responsibilities and expected behaviours and
acceptable usage with regard to information
system usage.
The Entity should receive signed acknowledge-

ments from users indicating that they have read,
understood, and agree to abide by these rules of
acceptable usage, before authorising their access
to the given information system. The completed
acknowledgement should be retained on file by
the Information Owner or Information System
Owner.
87
HR.3.3 The organisation should apply different sets S S R
of information service and information system
rules based on user roles and responsibilities.
(For example, differentiating between the rules
that apply to privileged users and rules that apply
to general users).
Control None
Dependencies
o 8.1.3 Terms and conditions of employment
o PL-4 Rules Of Behavior

HR.4 Segregation of Duties Version 2.0
Suggested P1
Priority
Control Duties and areas of responsibility shall be segregated by the
Standards Entity to reduce opportunities for unauthorised or unintentional
modification or misuse of the organisation’s information assets.
HR.4.1 The Entity should carefully consider the M M M
appropriateness of a single individual per-
forming multiple critical roles. The Entity
should undertake organisational and work
design in manner that provides for appropriate
separation of duties. Duties should be separated
to avoid potential abuse of position, conflicts of
interest or collusion between parties, with the
possible outcome of information assets being
compromised.
Where such a clustering of critical roles in a

single position may be unavoidable (e.g. limited
resource availability requires one individual to
fill multiple roles) compensating controls should
be deployed to limit risk. Compensating controls
may include (but not be limited to): monitoring
of activities, audit trails and an increased level of
management supervision.
HR.4.2 When designing information systems the Entity M M M

should ensure that no single person can access,
modify or use assets without authorisation or
detection.
89
HR.4.3 When designing for separation of duties, the S R M
Entity should seek to weigh the benefit of such
segregation against the potential impact of not
having staff trained across multiple disciplines.
(For example, too much segregation may mean
that a service is not administered effectively
during times when the individual is on leave, on
training etc.) The Entity should evaluate the risk
applicable to both scenarios. Highly segmented
roles, undertaken by only one individual, may
impact upon the availability of the information
service due to necessary support coverage not
being available.
Control None
Dependencies
o 10.1.3 Segregation of duties

o AC-5 Separation Of Duties

HR.5 Disciplinary Process Version 2.0
Suggested P2
Priority
Control The Entity shall establish a disciplinary process for handling
Standards violations of Information Security policy and procedures.
Control Type q Directive q Preventive q Detective q Corrective
a
HR.5.1 The Entity should employ a formal sanctions M M M
process for personnel failing to comply with
approved Information Security policies and
procedures. The sanctions process should be
consistent with applicable Government laws,
directives, policies, regulations, standards, and
guidance, and may be included as part of the
general personnel policies and procedures for
the Entity.
HR.5.2 The disciplinary process should be invoked fairly, M M M

consistently and on the basis of reliable evidence.
HR.5.3 Disciplinary actions should be handled M M M

with sensitivity as regards the potential for
information leakage. Only those parties with a
confirmed need to know should be involved with
the disciplinary process.
HR.5.4 Opportunity should be taken to identify R R R

lessons learned when conducting security-
related disciplinary action. This may include
the proposing of new or revised preventive and
detective controls that would limit the possibility
of such action occurring again in future, or
lessening its potential impact.
91
Control None
Dependencies
o 8.2.3 Disciplinary process

o PS-8 Personnel Sanctions

HR.6 End of Employment Security Version 2.0
Suggested P2
Priority
Control The Entity shall assign responsibilities within the involved
Standards departments (e.g. Human Resources, IT Department) to ensure
that employment termination is managed in a secure manner.
q a Preventive
HR.6.1 An inventory of relevant equipment and access M M M
granted to the employee/contractor should be
maintained to aid transaction of the termination
process.
HR.6.2 An exit interview should be conducted, where M M M

assigned equipment, access control cards,
keys and access tokens are recovered from the
employee/contractor.
Employees should be obligated to notify the exit

interviewer of any Entity-owned equipment or
information assets not on the inventory that are
in their possession.
A record of the exit interview should be retained

by the Entity. This should confirm:
• Which parties were in attendance
• The date and time that the interview was held
• Which items were confirmed, by reference

to the inventory, as being in the employee/
contractor’s possession
• Which additional Entity-owned items the

employee/contractor confirmed as being in
their possession
93
HR.6.2 • The status of the items identified (i.e. return or M M M
(Cont) not returned)
• The signature of the employee and the Entity

representative conducting that interview that
the record is complete and accurate
The record should not be finalised until such

time as all listed items have been returned to the
Entity.
HR.6.3 Access to information systems should be revoked M M M

no later than the formal contract termination
point. In exceptional circumstances (e.g.
where the individual’s employment has been
terminated by the Entity for cause) access should
be revoked immediately upon implementation
of the termination. The terminating party
should notify the IT department of the need to
undertake such activity without delay. Under
such circumstances account revocation should
take priority over day-to-day access and account
management activities.
HR.6.4 Accounts relating to terminated employees/ M M M

contractors should be suspended immediately
at the end of employment/engagement period.
The account should be retained for an Entity-
defined period of time in case there is the need
to subsequently access data held within it.
In the event that legacy data would need to be

accessed after the termination (e.g. electronic
mail archives), steps should be taken to migrate
the data to active information repositories
for future reference. Accounts relating to
terminated employees/contractors should not,
as a matter of general practice, be used by other
parties, after the termination.

HR.6.4 At the end of the Entity-defined retention M M M
(Cont) period, the account should be purged from the
information system. There may be exceptional
circumstances (e.g. evidential requirements
relating to a criminal investigation) where an
account will need to be retained for a period in
excess of the standard retention period.
Control None
Dependencies
o 8.3.1 Termination responsibilities
o PS-4 Personnel Termination
95
12.4 Third Party Supplier Security
TP.1 Security-Oriented Supplier Version 1.0
Selection Suggested P2
Priority
Control The Entity shall ensure that its Information Security
Standards requirements and obligations are reflected in its engagement
of third-party suppliers.

q q Detective
a q Corrective
TP.1.1 The Entity should ensure that Information M M M
Security-related requirements applicable to
third-party products and services are fully
captured and communicated in Requests For
Proposal (RFPs) and Requests For Quotation
(RFQs).
The requirements should:

• Be clearly identifiable as being Information
Security-related
• Carry a unique identifier, per requirement
• Be directly traceable back to original
requirements defined within the Service
Design or Information Security Design
TP.1.2 RFPs and RFQs that contain information M M M

describing either the current Information
Security capabilities of the Entity, or its future
Information Security requirements, should not
be released without the receiving party first
committing their organisation, employees
and any relevant sub-contractors to an Entity-
provided Non-Disclosure Agreement.

TP.1.3 The Entity should ensure that supplier responses M M M
to RFPs and RFQs confirm the specific, tangible
control(s) that will be put in place by the
supplier to address a given Information Security
requirement. (It should be readily possible to
correlate the proposed control or controls to the
uniquely identified requirement).
TP.1.4 The Entity should define weighting and R R R

evaluation criteria for reviewing supplier
proposals that take sufficient account of
Information Security-related requirements. The
Entity should specify within its procurement
procedures the specific percentage weighting
that will be applied to Information Security
in its evaluation of suppliers. The weighting
should show a correlation to the classification
of the information assets to which the service or
product offering relates.
TP.1.5 When evaluating a supplier’s capability to R R R

provide secure products and/or services, the
Entity should:
• Take into consideration past performance of
the supplier (e.g. involvement with previous
Information Security-related incidents).
• Solicit Information Security-oriented references

from other clients of the supplier.
• Review media sources for public domain

insights regarding the supplier’s strengths
and weaknesses in the area of Information
Security.
97
TP.1.6 Where evaluation of a prospective supplier R R R
highlights serious Information Security-related
concerns, the Entity should not proceed with
contract award unless and until the supplier
has adequately addressed those concerns in a
specific and verified manner; and has provided an
acceptable account of why those concerns arose
in the first place.
TP.1.7 The Entity should consider pre-qualifying S S S

suppliers/supplier facilities capable of handling,
transmitting or storing information of certain
classifications.
Such suppliers may be entered into a Preferred

Supplier List for products or services relating to
data of a given classification level.
TP.1.8 With specific reference to the hosting of M M M

information systems, the Entity should ensure
that government information classified as
‘Restricted’ or above is not hosted outside of an
Abu Dhabi government data centre. If, exceptional
circumstances require a consideration of other
hosting alternatives, a business case should be
presented to ADSIC.
Control None
Dependencies
References • Abu Dhabi Information Security Third Party Supplier Guide

TP.2 Security-Oriented Contract Version 1.0
Definition Suggested P2
Priority
Control The Entity shall ensure that third-party supplier commitments
Standards and obligations to Information Security are supported by robust
contractual definition.
q a Detective
q q Corrective
TP.2.1 The Entity should ensure that supplier M M M
commitments to, and assertions about,
Information Security control implementation
and management – made via RFP/RFQ – are
carried forward into relevant security-oriented
contract schedules with the selected supplier.
TP.2.2 The Entity should consider including within its S S S

third party supplier contracts behaviour-shaping
penalties that will apply in the event of security-
related controls:
• Not being implemented at all
• Not being implemented as per agreed
specifications
• Being found to be deficient
The impact of such penalties should be greater

than the cost of implementing and maintaining
the given control, so as to ensure compliance
with contractual commitments.
TP.2.3 The Entity’s contract with a supplier should R R R

require the supplier to proactively give
notification of any material weakness or
vulnerability that may give rise to a potential an
Information Security incident in relation to the
Entity’s information assets. Such a weaknesses
may possibly stem from any of the following
supplier elements:
• Processes
• Personnel
99
TP.2.3 • Relationships with sub-contractors R R R
(Cont.)
• Technology
• Business culture
• Premises
TP.2.4 The Entity’s contract with a third party supplier R R M

should ensure that the Entity retains the right to
audit the Information Security controls that the
supplier has committed to maintaining.
TP.2.5 Entity contracts with third-party suppliers should R R R

require the supplier to actively avoid conflicts
of interest and to ensure appropriate access
restrictions within their organisation, to avoid
Entity information assets being compromised.
This requirement will have specific applicability
to consultancies and outsourcers, working
with multiple client organisations on the same
engagement type, or working with the same
Entity on different types of engagement.
TP.2.6 Contracts with third-party suppliers of software R R R

and hardware should require the supplier to
warrant that their product is free of errors and
known vulnerabilities. The Entity should require
the supplier to demonstrate that relevant
security-oriented testing has been undertaken
on the hardware or software in question.
Control None
Dependencies

TP.3 Security Monitoring and Review Version 1.0
of Third Party Services Suggested P2
Priority
Control The Entity shall ensure that third-party suppliers are managed
Standards in accordance with Information Security requirements and
associated contracts.
Control Type q Directive q Preventive a Detective
q q Corrective
TP.3.1 The Entity should put in place monitoring and M M M
performance review mechanisms to verify that
third-party products and services are being
delivered in a manner consistent with agreed
Information Security-related contract schedules.
TP.3.2 The Entity should ensure that supplier personnel M M M

with access to Entity information assets and
information systems should satisfy the control
standards defined within the Human Resource
Security section of these Standards. Specifically
those relating to:
• Background screening
• Previous employment verification
• Educational/professional qualifications and
competency verification
• Non-disclosure of Entity information
The necessary verification may be undertaken

by the Entity itself. Alternatively, the Entity may
require the supplier to undertake such activities
and to confirm the results in a timely manner to
the Entity.
TP.3.3 With specific reference to IT, telecoms and R R R

business process outsourcers, the Entity should
require the service provider to:
• Provide regular (e.g. monthly) reports
confirming activity and performance against
agreed Key Security Indicators (KSIs).
101
TP.3.3 • Regularly submit a self-assessment of the R R R
(Cont.) status of the Information Security controls in
place to protect Entity information assets. The
self-assessment should be provided on a six
monthly basis, or more frequently in the event
of a) major change to the agreed services
supported by the outsourcer and
b) major business or organisational changes
within the outsourcer that may have a bearing
upon its delivery of service to the Entity.
• Require the service provider to proactively

notify the Entity in the event of the outsourcer
becoming aware of any vulnerability that
could materially affect the security of Entity
information assets.
TP.3.4 The Entity should undertake structured assess- S R R

ment of the outsource providers’ Information
Security capabilities on a regular (i.e. at least annual)
basis. The assessment should take as input:
• The service provider’s Key Security Indicator
reporting data.
• Any security incidents relating to Entity
information assets that the outsourcer was
involved in.
• The service provider’s self-assessment
submissions.
The Entity should undertake this assessment

itself and not merely reply on the supplier’s
own self-assessment. The findings from the
assessment should be reviewed by the Entity’s
Control None
Dependencies

TP.4 Security-Oriented Contract Version 1.0
Termination and Renegotiation Suggested P3
Priority
Control The Entity shall consider Information Security needs when
Standards terminating or renegotiating third party supplier contracts.

q a Detective
q q Corrective
TP.4.1 In the event of a major or repeated breach R R R
of Information Security-related contractual
clauses, the Entity should consider termination
of its contractual relationship with a third-party
supplier.
TP.4.2 The Entity should consider the effectiveness of R R R

a supplier’s Information Security capabilities
and control maturity when considering the re-
awarding/extension of a product or service supply
contract. Where those capabilities are found to
be deficient, the Entity should either:
a) Require a tangible and timetabled corrective
action plan from the supplier that will address
the shortcomings in advance of the contract
being re-awarded
or
b) Initiate a new procurement exercise to replace
the incumbent supplier.
TP.4.3 The Entity should ensure that its information R R R

assets are returned or destroyed (as appropriate)
by the supplier, at the end of the contractual
period. Destruction may include purging of
information systems and digital media, as well as
destruction of paper outputs.
Control None
Dependencies
103
12.5 Information Security Training, Awareness
& Communication
TA.1 Security Induction Version 1.0
Suggested P2
Priority
Control The Entity shall implement a formal Information Security
Standards induction process designed to introduce the organisation’s
security expectations.

TA.1.1 The Entity should arrange for all users of M M M
information assets and information systems
to be inducted into the Information Security
process. Induction should be relevant to the
level and scope of information access that the
individual will be granted.
For information creators and substantive users

of information assets, induction should include
(but not be limited to) introducing:
• The Abu Dhabi Information Security
Programme.
• The role and benefit of these Standards.
• The commitment of the Entity’s executive

management to effective Information Security.
• The Abu Dhabi Information Classification

framework.
• The purpose of the Entity’s Information

Security Policy and supporting documentation.

TA.1.1 • Key roles and responsibilities for Information M M M
(Cont.) Security within the Entity, with contact
information provided for relevant post-
holders.
• The terms of acceptable usage of information

systems.
• The mechanism for reporting Information

Security vulnerabilities and incidents.
• The portfolio of Information Security-related

training available to the inductee.
• Key user responsibilities (e.g. password

protection, destruction of paper waste).
TA.1.2 Information Security induction should be R M M

provided prior to access being granted to
information systems.
TA.1.3 The Entity should ensure that records are kept M M M

as to which individuals have attended security
induction, when this occurred and whether any
information systems access was granted prior to
attending induction.
Control None
Dependencies
o 8.2.2 Information Security awareness, education, and
training
105
TA.2 General Awareness Message Version 2.0
Delivery Suggested P1
Priority
Control The Entity shall deliver general Information Security awareness
Standards training to all information users.

TA.2.1 The Entity shall complement its security induction M M M
activities with regularly (i.e. at least annually)
provided general security awareness training
for all information users. This training should
reinforce the need for vigilance concerning
common security threats and make users aware
of emerging threats.
TA.2.2 General awareness training should additionally M M M

make users aware of any changes to the
definition of the Information Security process,
Information Security policy and the Entity’s
Information Security organisation that have
relevance to their information usage.
Control None
Dependencies
— Information Security management systems —
Requirements:
o 5.2.2 Training, awareness and competence
o AT-2 Security Awareness

TA.3 Tailored Awareness Security Version 2.0
Training Suggested P2
Priority
Control The Entity shall provide role-based security-related training
Standards that fits Entity needs.

TA.3.1 All personnel with defined responsibilities in the M M M
usage and/or management of information assets
should be provided with security training tailored
to their role type.
TA.3.2 Tailored training should be repeated at an Entity- R R R

defined interval to ensure that role-holders
remain aware of their security responsibilities.
TA.3.3 Role-based security-related training should be R R R

provided before access to a relevant information
system is granted and before the role-holder
performs assigned duties.
Control None
Dependencies
Requirements:
o AT-3 Security Training
107
TA.4 Security Training Development Version 2.0
and Delivery Suggested P1
Priority
Control The Entity shall oversee the development and delivery of
Standards Information Security training to ensure achievement of agreed
learning objectives.
q a Detective
q q Corrective
TA.4.1 The Entity should determine in advance the M M M
learning outcomes and required capabilities
applicable to information users and other
stakeholders within its Information Security
programme.
TA.4.2 The Entity should structure Information Security M M M

training curricula to directly address the learning
outcomes identified.
TA.4.3 Training curricula should be tailored to the M M M

specific needs, interests and responsibilities of
defined categories of stakeholders within the
Information Security programme e.g.:
• Information users
• Information Owners
• Control providers
• Information Security Governance Committee
members
TA.4.4 For training to be delivered in-house, the Entity M M M

should develop distinct security training modules
that directly address the agreed curricula. The
modules (including presentation materials,
hand-outs, quizzes etc.) should follow the
defined curricula and achieve the defined learning
outcomes.

TA.4.5 The Entity’s Information Security Governance M M M
Committee should verify that Information
Security training is being delivered in a manner
consistent with the training section of the
Information Security Programme Plan. The
verification should seek to confirm:
• Is training being delivered with sufficient
frequency?
• Are defined learning outcomes being achieved?
• Are requisite levels of verifiable competence

being demonstrated at the end of training?
• Are suggestions for improvement being

solicited from training attendees?
• Are training curricula being updated in light

of: attendee feedback, lessons learned from
security incidents and changing trends in
security threats and vulnerabilities?
• Has any information systems or facilities

access or permissions been granted without
requisite training having been provided?
Verification should apply whether the training is

delivered in-house or via a third-party provider.
TA.4.6 The Entity should keep detailed training records M M M

for each employee and non-employee with
access to its information systems. The records
should confirm:
• What security training was attended, when
and where
• What curriculum and version of that curriculum

was covered
109
TA.4.6 • Who the trainer was M M M
(Cont.)
• Quiz and/or test results
• Attendee confirmation of their attendance
• Recommendations for further training
TA.4.7 The Entity should determine the frequency at M M M

which security training should be repeated,
in order to ensure that the knowledge and
awareness of stakeholders remains active and
current.
Control • SG.1 – Security Programme Plan

Dependencies
Requirements:
o 5.2.2 Training, awareness and competence: I
o AT-1 Security Awareness and Training Policy
and Procedures
o AT-3 Security Training
o AT-4 Security Training Records

TA.5 Contact With Special Interest Version 2.0
Groups Suggested P3
Priority
Control The Entity shall require its Information Security personnel
Standards to solicit relationships and establish contacts with relevant
external forums and professional associations.
TA.5.1 The Entity should establish and institutionalise S S S
contact with selected groups and associations
within the Information Security community. This
being with the view to:
• Facilitating on-going security education and
training for Entity personnel.
• Staying up-to-date with the latest recom-

mended security practices, techniques, and
technologies.
• Sharing current security-related information

including threats, vulnerabilities, and incidents.
• Staying up-to-date with applicable laws,

directives, policies, regulations, standards and
guidance.
Control None
Dependencies
Requirements:
o 6.1.7 Contact with special interest groups
o AT-5 Contacts with Security Groups and Associations
111
TA.6 Information Security Version 2.0
Communications Suggested P2
Priority
Control The Entity shall determine, and plan for, the communication
Standards requirements of Information Security stakeholders.
TA.6.1 The Entity should develop a communications R R R
approach as part of its Information Security
Programme Plan. Communications planning
should complement the Entity’s security training
activities.
TA.6.2 Information Security communications planning R R R

should confirm:
• Key stakeholder audiences and their
anticipated communication needs.
• Key messages to be communicated to those

audiences.
• Channels for communication (e.g. intranet,

newsletter).
• Anticipated frequency of communication (e.g.

monthly, quarterly, annually).
TA.6.3 The Entity should develop and release R R R

Information Security-related communications
deliverables in a manner consistent with its

TA.6.4 The Entity’s Information Security Governance R R R
Committee should monitor the effectiveness
of communications-related initiatives and
deliverables to ensure on-going awareness of the
Information Security programme’s objectives
and key activities.
Control None
Dependencies
Requirements:
113
12.6 Information Asset Management
AM.1 Inventory of Information Assets Version 1.0
Suggested P2
Priority
Control The Entity shall maintain a current, documented inventory of
Standards assets.
q q Corrective
AM.1.1 The Entity’s information asset inventory should M M M
record the minimum mandatory data for each of
its principle information assets:
• Name of the information asset
• Business purpose of the information
• Principle user group(s) of the information and
their access levels (e.g. Read, Write, Executive,
Modify, Delete)
• Definitive location of the information (e.g.
which information system holds the primary
copy of the data)
• Other locations of the information (e.g. off-site
data stores)
• Name of the Information Owner
• Relationship with and dependency upon other
information assets
• Classification label of the information
• Current stage within the information lifecycle
(see AM.5 – Information Management and
Retention)
• Date of next review of the asset inventory’s
accuracy and completeness.
For the purpose of inventory tracking,

information assets may include both information
types and information systems.
AM.1.2 Changes to the information asset inventory M M M
should be managed in accordance with the
Entity’s Change Management process.

AM.1.3 The Entity should consider rendering its S R R
information asset inventory in a database that
enables:
• Reporting on asset status
• Relationships definition between information
assets
AM.1.4 The Entity should consider implementing S S S

automated configura-tion auditing tooling that
allows for prompt confirmation of significant
deviations between the actual information
estate and the associated records within the
inventory.
AM.1.5 On a regular basis (at least every six months) the R M M

Entity should audit its information asset estate
to ensure that the data contained within its
inventory remains accurate and current.
AM.1.6 The Entity should consider complementing its S S S

information asset inventory with a Configuration
Management Database (CMDB). The CMDB
may define the configuration parameters for its
information systems. The Entity may wish to
consolidate its information asset inventory and
CMDB in a single data repository.
Control AM.5 – Information Management and Retention

Dependencies
Requirements:
o 7.1.1 Inventory of assets
o CM-8 Information System Component Inventory
115
AM.2 Information Asset Ownership Version 2.0
Suggested P1
Priority
Control The Entity shall assign owners to all of its information assets.
Standards
AM.2.1 Information Owners should be defined for all M M M
information assets, with their responsibilities
documented and accepted by them. Information
Owners should be senior representatives
of the Entity departments with the primary
responsibility for a given information asset.
The Information Owner should retain ultimate
accountability for the protection of an information
asset, whether or not certain responsibilities
have been delegated to other parties.
AM.2.2 Information Owner responsibilities should M M M

include:
• Approving access to the information asset.
(Depending on the circumstance this approval
may be on a per-request basis or a more general
approval for a certain level of usage e.g. ‘all
members of Department A are approved for
write access to this network share’).
• Defining the lifecycle of the information asset,

including when it should move to archived
status and how long the information should be
retained after its active usage.
• Approving and reviewing security measures

applied to the information asset.

AM.2.2 • Ensuring all regulatory and legal obligations M M M
(Cont.) applied to the information asset are met.
Control
Dependencies
Requirements:
o 7.1.2 Ownership of Assets

o CM-9 Configuration Management Plan
117
AM.3 Classification of Information Assets Version 2.0
Suggested P2
Priority
Control The Entity shall classify information in accordance with
Standards Abu Dhabi information classification guidelines.
AM.3.1 All Abu Dhabi information assets must be M M M
classified based upon the sensitivity of their
potential disclosure.
All Entity information assets should carry one of

the following classification labels, as applied by
the designated Information Owner:
Public
Information specifically intended for dissemi-
nation in the public domain. Such information
is defined as having no local, national or
international restrictions on access and usage.
Public information is intended for the general
betterment of society, promoting the interests
of the country in the public realm, equipping
citizens and other stakeholders with necessary
information and the helping to promote the
country’s vision and values at home and abroad.
Restricted
Information that must be afforded limited
confidentiality protection due its use in the day-
to-day operations of government. Disclosure
of such information could have limited adverse
impact on the functioning or reputation of the
government. Such information relates to the
internal functioning of government and will not
have general relevance and applicability to a
wider audience. Although individual items of
information are not sensitive, taken in aggregate
they may reveal more information than is
prudent, if they were to be revealed.

AM.3.1 Confidential M M M
(Cont.) Information that requires robust protection due
to its critical support to decision-making within
government.
Information that could disclose designs,

configurations or vulnerabilities exploitable by
those with malicious intent.
Information that the government has a duty of

care to others to hold in safe custody (e.g. critical
personal information, government financial
information etc.).
Secret
Information that requires substantial and multi-
level protection due to its highly sensitive nature.
Disclosure of such information could have a

serious and sustained impact upon the national
security, social cohesion, economic viability and
health of the country.
Information disclosure could potentially threaten

life or seriously prejudice public order.
Default classification levels are specified for

certain main types of information asset (see
AM.3.10 – AM.3.11 below). The Entity is at liberty
to modify the classification of these information
types, as used within its own environment.
However, where the Entity intends to use a lower
classification level than identified within these
Standards, the Information Owner should be able
to demonstrate an informed and risk-oriented
rationale for why this is appropriate.
119
AM.3.2 The current, and any previous, classification of M M M
an information asset should be recorded within
the Information Asset Inventory. Any changes
to a classification level should be approved by
the Entity’s Information Security Governance
Committee, with an impact assessment on the
associated security control requirements being
conducted.
AM.3.3 Where the Entity identifies information assets M M M

that are potential candidates for designation as
‘Secret’, this should be communicated to ADSIC.
Assets confirmed as requiring such a classification
will require specific attention, in terms of control
definition and security assessment.
AM.3.4 Where the Information Owner has not defined it, M M M

and where it is not subject to the application of a
default classification level (see AM.3.10 – AM.3.11
below) the information asset’s classification will
default to ‘Confidential’ unless and until the
Information Owner completes the exercise of
classification.
AM.3.5 When seeking to classify its information M M M

assets, the Entity should make reference to the
Classification Matrix shown in Appendix C of
this document. The matrix should be used to
validate that the classification level proposed is
appropriate to the potential impact. Classification
levels should be determined by the value of the
information asset and the potential harm were it
to be disclosed.

AM.3.5 The impact of information being compromised M M M
(Cont.) will vary based upon:
• The classification level
• The area of potential impact (e.g. economic,
reputation)
Classification levels should not be decided

upon based on the resources available for
the application of controls. (e.g. a budgetary
constraint should not be a trigger for the asset’s
classification being downgraded).
AM.3.6 The Information Owners should ensure that M M M

classification levels for information assets under
their stewardship are reviewed regularly during
the information asset’s life (at least annually,
or more frequently following major business
change).
Information may undergo change during its

lifetime. There may be changes to:
• The content of the information
• The use the information is put to
• Who will be accessing the information
• Its location
• Its ownership
• The perceived value of the information
• The legal and regulatory obligations that
impact on the information
• The interrelationship between this information
and other information
Given such potential for change during the

information asset’s lifecycle, the Entity should
not consider the classifying of its information
assets as a one-time activity that leads to a static
and enduring classification level.
121
AM.3.7 Where an information asset is proposed for M M M
reclassification during its life, the Information
Owner is obligated to undertake an impact
analysis ahead of the reclassification taking
place. This analysis should seek to establish
what Information Security controls should be
added, removed or modified in support of the
revised classification level.
Proposed changes to the classification level of

information assets should be subject to multi-
disciplinary analysis and approval via the Entity’s
Change Management process.
AM.3.8 The Information Owner should ensure that M M M

internal and external stakeholders involved
in the creation, usage, storage, transmission,
management or disposal of an information asset
are made aware of its classification level and
the obligations imposed by that classification.
Any changes to the classification level should
be communicated to the stakeholder group in a
timely fashion.
AM.3.9 The classification of an information system M M M

or network will be determined by the highest
classification of data resident on that information
system, or transiting via that network. E.g. a
server hosting ‘Public’ and ‘Restricted’ data
should itself be designated as ‘Restricted’.

AM.3.10 The following information asset types should M M M

be classified by the Entity as being ‘Restricted’
or higher:
• Entity policies and procedures
• Entity performance reports
• Entity daily correspondence, memos and
electronic mail

AM.3.11 The following information asset types should M M M
be classified by the Entity as being ‘Confidential’
or higher:
• Customer/service user private data
• Entity strategy documentation
• Personnel and payroll records
• Financial records
• Procurement records
• Entity Requests for Proposals and contracts
with third-party suppliers
• Information systems architecture, design, test
and configuration documentation
Control AM.1-Inventory of Information Assets

Dependencies Appendix C – Classification Matrix
Requirements:
o 7.2 Information classification
123
AM.4 Information Labelling and Handling Version 2.0
Suggested P2
Priority
Control The Entity shall label and handle information assets based on
Standards their information classification.
AM.4.1 Entity documentation should carry a multi- S S S
part classification label corresponding to the
following format:
Classification Level/Organisation/Role(s)
Examples being as follows:

a) Restricted/DoT and Approved Outsourcers
Only/All Grades
b) Confidential/Executive Council and ADTA

Only/UAE Nationals Only (Director or Above)
Documentation of classification ‘public’ should

carry a label showing this classification level
but Organisation and Role(s) do not need to be
defined, due to the inherent nature of the data.
AM.4.2 Entity documentation templates should support M M M

the application of classification labels via the
provision of information classification fields in the
cover sheet and header/footer of the template.
AM.4.3 For documentation not generated from Entity R R R

templates (e.g. outputs from the Entity’s
enterprise resource planning (ERP) system), the
information system should automatically apply
a watermark showing the relevant classification.

AM.4.4 The Entity should consider applying a colour S S S
coding to classified documents, to provide
visual reinforcement of the classification and,
consequently, the handling expectations for the
material.
Standard colours for expressing classification

within the government of Abu Dhabi being:
Red = Secret
Orange = Confidential
Blue = Restricted
Green = Public
Where classification colouring is applied, the

above convention should be adhered to, to avoid
potential confusion for documentation passing
between government Entities.
AM.4.5 The Entity should determine, document and R R R

train its personnel in the restrictions that will be
applied to the handing of information of a given
classification. It should ensure the application
of these restrictions via policy, procedures and
other security controls.
Examples of possible handling restrictions being:

Secret – no access to information outside of the
designated office suite. No connection of the
information system to any transmission medium
other than a secure, closed network.
Confidential – no copying of data from the

information system to external media (e.g. USB
drive). Only printing to a secure printer, making
use of uniquely numbered copies. Printed outputs
(other than master copies) shredded after use.
125
AM.4.5 Restricted – no transmission of data via public R R R
(Cont.) email. Printed outputs (other than master copies)
to be shredded after use.
Control AM.3-Classification of Information Assets

Dependencies
Requirements:
o 7.2.2 Information Labelling and Handling

o MP-2 Media Access
o MP-3 Media Marking
o AC-16 Security Attributes

AM.5 Information Management and Version 1.0
Retention Suggested P3
Priority
Control The Entity shall determine the lifecycle of its information assets
Standards and apply appropriate Information Security controls during
that lifecycle.
AM.5.1 The Entity should determine the anticipated life- M M M
cycle of its information, from production through
to destruction. This should be informed by:
• The Entity’s business needs
• Regulatory and legal obligations applicable to
its business processes
AM.5.2 The Entity should determine how long M M M

information should to be retained, beyond its
active usage. Once a retention period has been
determined, the Entity should ensure that the
information remains accessible during this period
(e.g. it is maintained on media that can be read
by current information systems).
AM.5.3 The information asset inventory should show M M M

information’s current lifecycle stage and the date
that this will next be reviewed. The information
lifecycle may be distinguished by the following
phases:
• Development
• Production
• Archive
• Replaced
• Destroyed
127
AM.5.4 The Entity should evaluate how the scope and R R R
depth of Information Security controls will
change during the information lifecycle. For
example, determining if less stringent controls
are necessary once the information is no longer
current and is stored within an archive. On-going
maintenance of the Information Security Design
for the associated information system can
ensure that controls are adapted appropriately
to the lifecycle stage.
AM.5.5 The Information Owner should approve any R R R

change of lifecycle phase and any upgrade or
downgrade of Information Security controls on
the basis of that transition.
Control AM.1 Inventory of Information Assets

Dependencies
Requirements:
o 15.1.3 Protection of Organizational Records
o AU-11 Audit Record Retention
o MP-1 Media Protection Policy and Procedures
o MP-4 Media Storage
o SA-5 Information System Documentation

AM.6 Physical Asset Management Version 1.0
Suggested P2
Priority
Control The Entity shall identify and manage the physical assets used in
Standards support of its information assets.

q q Preventive q Detective
a q Corrective
AM.6.1 The Entity should develop and maintain a M M M
plan for the management of its information
systems and other physical assets (e.g.
supporting infrastructure) deployed in support
of its information assets. The plan should seek to
determine where specific categories of physical
assets may be sited, what purpose they will serve
and which of these assets can be removed from
the specified locations.
AM.6.2 The Entity should implement and maintain an M M M

inventory of its physical assets (with a particular
focus on information systems and network
devices). The inventory should, as a minimum,
confirm:
• The asset’s unique asset inventory number
• The category of asset it belongs to
(e.g. ‘desktop’, ‘laptop’ ‘printer’ etc.)
• The make and model of the asset
• Its date of purchase
• Its anticipated date of retirement
• The purpose of the asset - what is it intended
to do and in relation to what information
asset(s)?
• The identity of the information system/asset
owner
129
AM.6.2 • Its serial number M M M
(Cont.)
• The highest classification of information
that the asset stores, transmits or otherwise
directly interacts with
• The specific location of the asset (i.e. not
simply ‘Data Centre’ but also the specific rack
position within that data centre)
Changes to the physical asset inventory should

be managed under the direction of the Entity’s
AM.6.3 The Entity should consider managing its physical S S S

inventory within a configuration management
database that confirms:
• The data defined in AM.6.2 above
• The baseline configuration of the asset
• The relationships between physical assets
(e.g. ‘is a child of’, ‘is a parent of’, ‘is a sibling
of’). Relationship mapping can help assist in
undertaking impact analysis when changes to
a given asset are proposed.
AM.6.4 Physical assets should carry a label displaying: M M M
a) which party owns the asset e.g. the Entity

b) the unique asset inventory number referenced
in AM.6.2 above.
Labels should be sufficiently robust to avoid the

label being removed during the asset’s life, or the
data displayed on it becoming unreadable (either
through normal wear and tear or intentional
defacement). Where physical labels are no longer
legible they should be replaced.

AM.6.5 For physical assets that are at significant risk S S S
of theft, the Entity should consider applying
indelible marking to the equipment, to limit its
potential for resale by unauthorised parties.
AM.6.6 The Entity should regularly audit its physical M M M

asset estate (at least annually) to:
• Verify the accuracy and completeness of
entries within its physical asset inventory
• Determine if assets are suitably labelled
• Conform compliance with asset movement
restrictions defined within the Physical Asset
Plan (see AM.6.1 above)
AM.6.7 Physical assets should be disposed of in a manner M M M

conformant with the requirements of these
Standards (see OM.22 Secure Disposal and Reuse
of Equipment).
Control
Dependencies
o A.7 Asset Management
131
12.7 Physical & Environmental Security
PE.1 Physical and Environmental Version 1.0
Security Planning Suggested P2
Priority
Control The Entity shall evaluate the physical environments in which
Standards it processes or stores information and shall apply suitable
controls.
a q Preventive
PE.1.1 The Entity should undertake a structured review M M M
of any proposed information processing or
storage facility to determine its suitability. The
evaluation should include assessment of:
• Adequacy of environmental controls (heating,
lighting, ventilation)
• Adequacy of smoke and fire detection and
suppression capabilities
• Access to the facility, including perimeter
restrictions and internal access restrictions
• Power, including capacity, quality and
predictability of the electrical feed from the
electrical grid
• Loading and unloading capabilities for
equipment
• Assessment of the most significant risks
applicable to the facility’s location, its con-
figuration, its facilities and its profile of usage
• Other activities taking place at the location
that may have a bearing upon the processing
of the Entity’s information (e.g. a shared space
used by other organisations).
• Proximity to emergency services
(e.g. fire department)
Information processing and storage facilities will
include data centre/computer suite environments,
as well as offices, other workspaces and archive/
storage facilities.

PE.1.2 Based upon the findings from its review, the M M M
Entity should develop a plan of new, augmented
or improved physical and environmental controls
for the target facility. The level of control
application should be influenced by:
• The value and classification of the information
being handled at the facility.
• The type of facility it is. The Entity’s information

assets will likely be created, used, modified and
destroy in one of three main physical domains:
a) Offices and other workspaces
b) Data centres/computer rooms
c) Archive/storage locations
Control standards applicable to each of these

environments are provided in this section of the
Information Security Standards.
PE.1.3 Where a review of a proposed facility shows R R R

significant and/or wide-ranging physical or
environmental vulnerabilities, the Entity
should consider the viability of its information
being processed there. Serious physical and
environmental risks that cannot be avoided or
effectively mitigated should cause the Entity
to review its options for possible alternative
facilities.
Control
Dependencies
o PE-1 Physical and Environmental Protection Policy and
Procedures
133
PE.2 Common Physical and Version 1.0
Environmental Security Controls Suggested P1
Priority
Control The Entity shall ensure that appropriate physical and
Standards environmental controls are deployed in all facilities where its
information assets are created, handled, modified, stored or
destroyed.

q a Detective
q q Corrective
PE.2.1 On the basis of its review and planning M M M
activities, the Entity should deploy physical
and environmental controls to each of its main
physical domains. Certain control types will
have general applicability to each of its three
main physical domains (i.e. offices and other
workspaces, data centres and archive/storage
facilities).
PE.2.2 The Entity should ensure that the external M M M

perimeter of its facility is protected via the
deployment of physical access controls. These
will include:
• Lockable doors
• Lockable windows
• Designated entry/exit points (e.g. receptions)
• Automated access control mechanisms
(e.g. barriers)
• Security guards (static and patrolling)
PE.2.3 The Entity should develop and maintain current M M M

lists of personnel with authorisation to access the
facility. Appropriate authorisation credentials
(e.g. badges, identification cards, smart cards)
should be distributed to approved parties.
Access lists should be reviewed regularly (at least
every six months) to ensure that individuals with
access still have a legitimate and approved need
for access to the facility.

PE.2.4 Access credentials to the facility should be M M M
revoked and collected once access is no longer
required (e.g. at the end of the individual’s
employment).
PE.2.5 Physical access should be monitored and M M M

access logs reviewed periodically for anomalies.
Apparent access violations should be investi-
gated and remedial action taken.
PE.2.6 For those facilities other than those designated M M M

as publicly accessible, the Entity should maintain
a visitor access log that includes:
• Visitor’s name and organisation
• Date of access
• Time of arrival and departure
• Signature of visitor
• Purpose of visit
• Form of identification presented and verified
• Name and organisation of person being visited
Visitors should be escorted by Entity personnel

during their time at the facility.
PE.2.7 The Entity should consider deploying and R R R

monitoring real-time intrusion alarm and
surveillance systems.
135
PE.2.8 The Entity should require authorisation prior R R R
to any property (including information assets
and information systems) being removed from
the facility. For certain assets types (e.g. laptop
computers that are regularly taken home by
employees to work) pre-approval may be granted
to a range of individuals needing to have such a
dispensation, depending on the classification of
the data being handled on these devices.
Control HR.6 End of Employment Security

Dependencies
Requirements:
o 9.1.1 Physical security perimeter
o 9.1.2 Physical entry controls
o 9.1.3 Securing offices, rooms, and facilities
o 9.1.4 Protecting against external and environmental
threats
o 9.1.6 Public access, delivery, and loading areas
o 9.2.1 Equipment siting and protection
o 9.2.2 Supporting utilities
o 9.2.5 Security of equipment off-premises

o PE-2 Physical Access Authorizations
o PE-3 Physical Access Control
o PE-4 Access Control for Transmission Medium
o PE-6 Monitoring Physical Access
o PE-7 Visitor Control
o PE-8 Access Records

PE.3 Workspace Security Version 2.0
Suggested P1
Priority
Control The Entity shall ensure that the design and use of workspaces
Standards supports its Information Security objectives and obligations.

q a Detective
q q Corrective
PE.3.1 The Entity should define procedures and R R R
implement enforcement mechanisms to support
the ‘clear workspace’ provisions of its Information
Security policy. Such may include the Entity’s
Information Security personnel:
• Conducting periodic walk-throughs of working
areas to identify:
- Paper materials and removable digital media
left unattended and unprotected.
- Workstations that have been left without a
screen lock being applied while unattended.
- Laptops and mobile devices that have been
left unsecured outside of working hours.
- Desk pedestals and cupboards that have
been left unsecured outside of working
hours.
• Removing and quarantining materials of

classification of ‘Restricted’ or above discovered
on desks, at printers, in meeting rooms, on flip
charts, in waste paper baskets etc.
• Identifying, photographing and removing

information of classification of ‘Restricted’ or
above left on meeting room whiteboards after
meetings have been concluded.
• Reporting of clear workspace violations to

the senior management of the department
concerned.
137
PE.3.1 • Monitoring the implementation of corrective R R R
(Cont.) actions by the department concerned, to
ensure future avoidance of clear workspace
security violations.
• Recommending disciplinary action where

there is evidence of serious and/or repeated
violation.
Such enforcement activities should be: a)

oriented toward education and continuous
improvement b) focused on material of
classification ‘Restricted’ or above and c) should
not be arbitrarily applied to all information
outputs.
PE.3.2 The Entity should seek to ensure that S S S

sound-proofing is put in place to protect the
confidentiality of discussions taking place in
meeting rooms and offices.
PE.3.3 The Entity should consider moving the handling S S R

of information of classification ‘Confidential’ or
above to demarcated workspaces, with physical
access controls separating these environments
from common areas of the Entity’s office space.
Where such information must be handled in ‘open

plan’ areas, the Entity should make provision to
limit the potential for information confidentiality
to be compromised (e.g. computer screen filters
to limit the potential angle of view).
PE.3.4 For functions handing data of classification S S S

‘Confidential’ or above, the Entity should require
access control and event logging capability on
printers, scanners and fax machines. Individuals
should be required to enter their access
credentials at the printer before such materials
are output.

PE.3.5 Where the Entity already does receive, or S S S
anticipates receiving, data of classification
‘Confidential’ or above via fax, it should consider
deploying a fax server, integrated with its
electronic mail server and its access control
mechanisms (in preference to using traditional
fax machines where inbound faxes may remain
uncollected).
PE.3.6 Entity personnel should be educated as to the S S S

potential information leakage risks associated
with work activity and work-related conversations
held outside of Entity premises. Where such
work and conversations are necessary, the
environment should be treated as an Entity
workspace and the above Control Specifications
should be considered.
PE.3.7 Entity personnel should be encouraged to R R R

report any suspicious activity or unaccompanied
visitors within Entity premises, to security
personnel.
Control
Dependencies
o 11.3.3 Clear Desk and Clear Screen Policy
o AC-11 Session Lock
• ENISA Secure Printing Guide (http://bit.ly/ustxmL)
139
PE.4 Data Centre Security Version 1.0
Suggested P2
Priority
Control The Entity shall ensure that data centre facilities provide an
Standards adequate level of protection for the information assets stored
and processed within them.
q a Detective
q q Corrective
PE.4.1 In addition to the other controls described M M M
in this section, the Entity should determine
what specific, unique or enhanced controls are
required to secure its data centre locations.
Where the Entity has outsourced information
system, application or file hosting to an external,
third-party provider, it should ensure that:
• Its contractual terms specify the security
controls that will be deployed in the data
centre environment and the purpose they will
serve.
• The Entity retains the right of audit to validate

the continued presence and effectiveness of
the contractually agreed controls.
PE.4.2 Sensitive information systems should be sited S S M

in dedicated (isolated) physical computing
environment, demarcated from other computing
environments. The level of access control to this
area should be restricted to only those personnel
with a verified need for access.
PE.4.3 The Entity should site its data centre in a location R R R

where the risk of natural disasters (e.g. flood,
fire) is at an acceptable level.

PE.4.4 The Entity should site its data centre in a location R R R
where the risk of man-made disaster (e.g. plane
crashes, riots, explosions, chemical spills) is low.
PE.4.5 Data centres should ideally not be housed in S S S

the same building as other offices, especially
offices used by other, non-governmental
organisations.
PE.4.6 Digital Closed Circuit Television (CCTV) should R R R

provide continuous monitoring of parking areas,
access points to the data centre and the interior
of computer rooms. Recordings should be
retained for at least six months from the date of
recording.
PE.4.7 The computer rooms of data centre facilities S S S

should be placed in the interior of the building,
away from perimeter walls. Computer rooms
should not have windows.
PE.4.8 The Entity should have fire, power, weather, S S S

temperature and humidity monitoring systems
in place. The data centre should be subject to
continuous monitoring, with automated alerting
to relevant personnel in the event of defined
reporting thresholds being reached.
PE.4.9 An automatic authentication method (e.g. S S S

badge reader) should be deployed for access
to the data centre perimeter. The Entity should
consider supplementing this with a second form
of authentication (e.g. biometric, key pad PIN)
for access to computer rooms.
141
PE.4.10 Visitors should be required to sign in and sign S S S
out of the data centre facility, after having their
identity verified by reference to primary ID (e.g.
passport, Emirates ID or UAE driving license).
Visitors should be escorted at all times while in
the data centre.
PE.4.11 There should be a Halon or other total flooding S S S

fire suppressant agent in place in each computer
room. Water-based suppressant agents (e.g.
wet pipe sprinkler systems) should not be used
due to the potential for damaged to information
processing equipment. Fire extinguishers should
be placed within computer rooms and other
areas of the data centre building. Emergency
power-off buttons switches should be installed in
computer rooms.
PE.4.12 Battery backup power should be available, with S S S

sufficient duration to allow for a switch over
to diesel power generation. Diesel generators
should have sufficient capacity and fuel to
provide power to key information systems and
critical data centre infrastructure for at least
24 hours following an outage.
PE.4.13 Security guards and cleaning staff should be S S S

subject to criminal background checks. Guards
should be trained to follow and enforce the
physical security requirements of the facility.
Cleaning crews should work in groups of at
least two.

Control
Dependencies
Requirements:
o 9.1.4 Protecting against external and environmental
threats

o PE-11 Emergency Power
o PE-12 Emergency Lighting
o PE-13 Fire Protection
o PE-14 Temperature and Humidity Controls
o PE-15 Water Damage Protection
143
PE.5 Archive and Storage Facility Security Version 1.0
Suggested P3
Priority
Control The Entity shall protect information held in archive and long-
Standards term storage facilities until its disposal.
q a Detective
q q Corrective
PE.5.1 The Entity should apply Information Security M M M
controls to archive facilities appropriate to the
classification of the data being stored.
Information may be reclassified during its lifetime,

especially if its sensitivity is time dependent. As
consequence, the level of Information Security
controls may also need change over time, as the
information ages.
PE.5.2 In order to apply appropriate controls to archive M M M

facilities, the Entity should be able to confirm:
• What information is being stored
• Who needs to have access to it
• Who is authorised to approve access
• How soon after request must information be
retrievable from the archive
• How long the information is to be stored
for (see AM.5 Information Management and
Retention)
• In what format the information will be stored
• What risks apply to the security of the archive
facility

PE.5.3 The Information Owner should formally confirm M M M
how long information should be retained within
the archive. On a regular basis (at least annually)
the Information Owner should reconfirm that
the information still needs to be held and the
now anticipated date for the end of its storage.
Archived information should not be defaulted to
an ‘indefinite’ storage period.
PE.5.4 The Entity should ensure that information held M M M

within the archive/storage facility remains
accessible during the information’s defined
lifecycle. If held on digital media, the Entity
should ensure that the media can continue to be
accessed as technologies are updated.
PE.5.5 Paper and digital media held in the archive M M M

should be uniquely identified and catalogued. A
record should be kept of what items were moved
in and out of the archive, when, by whom and
for what purpose. The record should also show
who approved this movement.
PE.5.6 Higher classification materials should be subject M M M

to a more stringent level of physical controls e.g.
locked storage cages, Closed Circuit Television
(CCTV) monitoring of access.
PE.5.7 The Entity should ensure that fire suppressant S S S

technologies used within the storage are
designed to limit potential damage to archived
media (e.g. a sprinkler system only activating in
an affected area, not throughout the facility).
145
Control • AM.5 – Information Management and Retention

Dependencies
Requirements:
o 9.1.4 Protecting against external and
environmental threats

o PE-11 Emergency Power
o PE-12 Emergency Lighting
o PE-13 Fire Protection
o PE-14 Temperature and Humidity Controls
o PE-15 Water Damage Protection

12.8 Information Systems Design,
Development & Testing
IS.1 Security Requirements Version 1.0
of Information Systems Suggested P2
Priority
Control The Entity shall determine Information Security controls
Standards requirements for new information systems, or enhancements
to existing information systems.
IS.1.1 Information Security requirements should be M M M
canvassed from relevant stakeholders and should
encompass:
• Legal and regulatory obligations
• Compliance with these Standards
• Compliance with the Entity’s Information
Security policy
• Classification of the data at hand
• Business functional requirements
• Integration with existing infrastructure and
controls
• Service and Security Management requirements
(e.g. what supporting capabilities are needed
to support the given information system)
Requirements should be prioritised on the basis

of greatest need, with each of the above levels
predominating over the ones below it.
IS.1.2 Security requirements should confirm the M M M

specific dimension of Information Security
where requirements arise (e.g. confidentiality,
integrity, availability, capacity, maintainability,
non-repudiation).
147
traceable throughout the full lifecycle of the
information system. It should later be possible to
correlate any Information Security control with
the requirement that prompted its design and
implementation.
A Requirements Traceability Matrix [see

Dependencies below] should be used to
ensure the effective capture, categorisation
and management of Information Security
requirements.
IS.1.4 Information Security requirements should not M M M

be bound to specific technologies, which may
change over the life of the information system.
(This does not prevent the specification of
requirements that have a technical focus; the
expectation is merely that specific technologies
and vendor solutions are not be specified at the
time of requirements capture in a way that would
too prematurely narrow the range of potential
solutions).
IS.1.5 Where an Information Security requirement will M M M

not endure for the full life of the information
system, the time-dependent parameters of the
requirement should be defined (e.g. the cover
time needed for the protection of confidential
information).
IS.1.6 Each Information Security requirement should M M M

be mapped to an individual requester and a
unique identifier, to aid traceability throughout
the systems development lifecycle.

IS.1.7 The Entity should evaluate the totality of M M M
requirements to make sure they are compatible
and mutually supportive e.g. Information Security
(requirements for a high level of confidentiality)
not contradicting Productivity (requirements for
a high level of system responsiveness.

explicitly mapped to the security service type
that that they correspond to. Security services
types include:
• Authentication
• Access Control and Authorisation
• Availability
• Data Integrity At Rest
• Data Integrity In Motion
• Data Confidentiality At Rest
• Data Confidentiality In Motion
• Non Repudiation
• Recoverability
• Maintainability
Where the provider of the requirements does
not have the experience necessary to make
such a correlation, the Entity’s Chief Information
Security Officer (CISO) should analyse the
requirements and propose a workable mapping
of requirements to target security services.
149
IS.1.9 The Entity should confirm the anticipated usage R R M
of the information system during the capturing
of requirements. The requirements capture
should confirm the anticipated size of the
information system’s user community, their
projected demand on the information system
and when this demand is likely to occur.
Projections should be sought regarding the
anticipated future growth in demand, during
the life of the information system, for the
purpose of undertaking capacity and availability
management.
Control Information Security Requirements Traceability Matrix

Dependencies Template
o 12.1.1 Security requirements analysis and specification

o SA-1 System and Services Acquisition Policy and
Procedures
o SA-3 Life Cycle Support
o SA-4 Acquisitions
• Abu Dhabi Information Security Design, Development and

Testing Guide

IS.2 Information Security Design Version 1.0
Suggested P2
Priority
Control Entity information systems shall adhere to a structured
Standards Information Security design that is integrated into the
information system design.
q a Preventive
IS.2.1 The Entity should develop an Information M M M
Security Design for a specific information system
that confirms:
• What the Information Classification and
Categorisation of the information system
will be.
• What specific Information Security controls
will be implemented.
• How these controls map to specific, uniquely
identified Information Security requirements
(see IS.1 Security Requirements of Information
Systems).
• How the controls map to Control Standards
defined within this document.
• Whether a given control is tailored to the

target information system, or if an existing
common control will be leveraged. (See SG.7
Enterprise Information Security Architecture
and SG.11 Common Control Catalogue). Where
the control has potential applicability to other
information systems, it should be added to the
Common Control Catalogue.
• What anticipated demand will be placed
on the control and how it will be sized and
configured to ensure its continued availability
and functionality under anticipated usage
scenarios.
• How a given control will interact with other
controls (e.g. two controls working in harmony
to provide defence-in-depth).
151
IS.2.1 • What risks (including potential impact) would M M M
(Cont.) be manifested if the control were to fail or be
compromised.
The Information Security Design should

be reviewed and approved by the Entity’s
before development, implementation and testing
activities are commenced. The Committee should
seek to satisfy itself that the design has, if
implemented, the potential to provide a level of
Information Security protection appropriate to:
• the confirmed requirements
• the information system’s classification &
categorisation
• the Entity’s risk profile
IS.2.2 The Information Security Design should confirm R R M

the specific controls that will be applied in order
to a) provide an agreed level of capacity and
b) monitor usage against this defined level of
capacity.
Where information system usage currently

is exceeding, or is anticipated to exceed,
the capacity thresholds defined within the
Information Security Design, the Entity should
make provisions for re-evaluating the usage
and sizing of the information system. The
information system may need to be resized for
continued availability and performance.
Changes in the capacity profile of the primary

information system should be reflected in any
secondary information systems used for service
continuity purposes.

IS.2.3 When designing information systems, Entities M M M
(or their third-party providers) should adhere to a
tiered (i.e. multi-level) architecture model. Such
allows information system design to adopt a
modular approach that helps manage complexity
and dependencies.
An example three tier model is:

• Presentation/Client Tier
• Business Logic/Application Tier
• Database Tier
The specific number of tiers required will depend

upon the Entity’s business needs and prevailing
architectural standards. Individual tiers may be
further elaborated into supporting sub tiers, as
required.
The information system design should decide

upon:
• The optimal tier for the placement of a given
security control type
• Whether the same control type needs to be

replicated within multiple tiers
• How the security of interfaces between the

tiers can be protected and tier boundaries
enforced
IS.2.4 The Entity should ensure that Information M M M

Security requirements (see IS.1 Security Require-
ments of Information Systems) remain fully
traceable throughout the design, development
and testing process. A clear correlation between
Information Security requirements and a specific,
tangible set of management and technical
controls targeted to meet those requirements
should be fully evident.
153
IS.2.5 The Information Security Design should serve as M M M
the primary record of how Information Security
controls will be, and have been, deployed for a
specific information system.
IS.2.6 When designing Information Security controls, S R R

the Entity should undertake a business impact
analysis in relation to Control Standards shown
as ‘Recommended’ or ‘Suggested’ within these
Standards. This being in order to determine if
the benefit of applying a given control
outweighs its potential negative impact on
the business process. (Information Security
should be approached as an enabler of effective
government activities, not impedance to them.
Unduly restrictive or ill-conceived Information
Security controls that don’t take account of
Entity’s risk profile and business objectives may
have unintended consequences e.g. decreasing
productivity, user satisfaction and service
availability).
IS.2.7 The Entity should consider the deployment S S S

of automated code analysis tools during the
development and testing lifecycle, to evaluate
code for common software vulnerabilities.
IS.2.8 The Entity should ensure that the design of M M M

information systems is aligned to best practice
for the secure development of information
systems (see References below). Such including
the need for:
• Input Data Validation (restriction of the types
of information that can be entered into an
application)

IS.2.8 • Output Data Validation (only confirmed M M M
(Cont.) information types can be output by the
information system)
• Message Integrity, authenticity and

confidentiality (messages within the
information system and between information
systems are protected from being
compromised)
• Exception Management Control of Internal

Processing (validation checks are made to
detect and handle errors and exceptions in a
secure manner)
Information systems should be designed and

developed with an orientation toward achieving
a known, good configuration that is provably
secure against the agreed security requirements.
IS.2.9 Where an information system has been M M M

developed by a third-party supplier, the
Entity should undertake an evaluation of the
Information Security controls deployed by the
supplier. This provision should apply whether
the information system includes Commercial
Off-The-Shelf (COTS) software or is a solution
developed specifically for the Entity.
Where the Entity identifies control omissions

within the third-party developed information
system, it should implement compensating
controls to address the identified shortfall.
The specification and management of the third-

party controls should be handled in a manner
consistent with the provisions within the Third
Party Supplier Security section of these Standards.
155
IS.2.10 Design of information systems should consider M M M
the infrastructure and computing environment
into which the information system will be
deployed. The information system should be
designed to work in a hardened environment.
The Entity should ensure that the infrastructure
will be supportive of the security needs of the
information system.
IS.2.11 Information systems should be designed to M M M

fail in a secure manner i.e. avoiding security
vulnerabilities being presented at the time of
failure.
IS.2.12 The Information System Owner and/or M M M

Information Owner (as applicable) should
approve the Information Security Design prior
to the development of the security controls
commencing.
IS.2.13 When undertaking its design activities, the Entity S S S

should consider physically isolating information
systems of higher classifications, to allow for the
demarcation of physical controls, on the basis of
the sensitivity of data held on those information
systems.

Control SG.7 Enterprise Information Security Architecture

Dependencies SG.11 Common Control Catalogue
IS.1 Security Requirements of Information Systems
References • NIST Special Publication 800-27 Rev A ‘Engineering

Principles for Information Technology Security’
• SafeCode - Fundamental Practices For Secure Software

Development
http://www.safecode.org/publications/SAFECode_Dev_
Practices0211.pdf
• DACS - Enhancing the Development Life Cycle to Produce

Secure Software: A Reference Guidebook on Software
Assurance
• Software Assurance Maturity Model (SAAM)

http://www.opensamm.org/download/
• Open Web Application Security Project

https://www.owasp.org/index.php/OWASP_Guide_Project
• Build In Security Initiative

https://buildsecurityin.us-cert.gov/bsi/home.html
• ISO 7498-2 Information processing systems - Open Systems

Interconnection - Basic Reference Model - Part 2: Security
Architecture

Testing Guide
157
IS.3 Information System and Network Version 1.0
Device Hardening Suggested P1
Priority
Control The Entity shall restrict information systems and networks to
Standards only those configurations required to achieve the agreed design
objectives.
q a Preventive
IS.3.1 The Entity should design information systems M M M
and networks to function only with the least
level of privilege necessary to complete the
agreed task. Unnecessary functionality, processes,
protocols and ports should be disabled. Hardened
versions of application software, middleware,
operating systems and hardware should form a
baseline configuration for the computing device.
IS.3.2 The Entity should develop a checklist to M M M

ensure that information system and network
hardening procedures have been followed
during commissioning.
IS.3.3 Baseline configurations of hardended S R M

information systems should be held under
change control in definitive software and
hardware libraries (i.e. repositories that hold
a master copy of the software images and
documented hardware specifications that have
been approved).
IS.3.4 Information Security testing and on-going M M M

monitoring should confirm that unnecessary
functionality and capabilities are not active
within information systems being commissioned
or already within the production environment.

IS.3.5 Operational changes to baselined, hardened M M M
information systems should be assessed for their
potential to deviate the system configuration
away from the Entity’s hardening best practices.

IS.3.6 Hardware configurations should be limited to M M M
only those components required for the purpose
stated in the network, information system or
information security design. Unnecessary hard-
ware components should ideally be removed or at
least disable in software.

IS.3.7 Incidents should be analysed for potential M M M
learning regarding the further enhancement
of the Entity information system and network
hardening capabilities.

IS.3.8 Equipment subject to maintenance should M M M
be confirmed as being returned to the
hardened configuration baseline, before being
reintroduced to the production environment.

Control
Dependencies

o CM2- Baseline Configuration
o CM-6 Configuration Settings
o AC-19 Access Control for Mobile Devices

Testing Guide
159
IS.4 Source Code Protection Version 2.0
Suggested P2
Priority
Control The Entity should protect software source code carefully from
Standards unauthorised access and/or modifications.
IS.4.1 Program source libraries should not be stored in R M M
operational information systems.
IS.4.2 Updating of program source libraries and M M M

issuing of programme sources to programmers
should only be performed after appropriate
authorisation.
IS.4.3 Maintenance and copying of programme source M M M

libraries should be subjected to strict change
control procedures.
IS.4.4 Access to programme source code should M M M

be restricted. Access to programme source
code and associated items (such as designs,
specifications, verification plans, and validation
plans) should be strictly controlled to prevent the
introduction of unauthorised functionality and
avoid unintentional change.
IS.4.5 Central storage of code in secure programme R R R

libraries should be considered.

IS.4.6 Where use is made of third-party code, the M M M
source libraries should be validated for accuracy
and avoidance of malicious code.
IS.4.7 The Entity should ensure that software code R R M

is independently verified for completeness,
accuracy and the avoidance of common security
vulnerabilities prior to it being complied. The
verification should be done by an independent
party with the knowledge, skills and experience
to effectively verify the code.
Where the Entity is purchasing off-the-shelf/

already compiled software, contractual terms
with the third-party supplier should require
that the third-party is adhering to safe coding
practices (see References below).

Control
Dependencies

o 12.4.3 Access Control to Program Source Code

o AC-3 Access Enforcement
o AC-6 Least Privilege
o CM-5 Access Restrictions for Change
o MA-5 Maintenance Personnel
o SA-1 System and Services Acquisition Policy and
Procedures

Testing Guide
161
IS.5 Cryptographic Controls Version 2.0
Suggested P2
Priority
Control The Entity shall deploy cryptographic controls in a manner
Standards commensurate with confirmed confidentiality, integrity and
non-repudiation requirements and in a manner supportive of
the organisation’s security policy.
q a Preventive
IS.5.1 As applicable, an Information Security Design S M M
should confirm how cryptographic controls will
be deployed and for what business purpose.
IS.5.2 The Entity should endeavour to only select S M M

robust public-domain (non-proprietary) crypto-
graphic algorithms for use within its information
systems and networks.
Where requirements and/or market constraints

present a strong case for the use of proprietary
cryptographic algorithms, the proposed use
should be discussed in advance with ADSIC.
IS.5.3 The selected cryptographic key length should M M M

be sufficient to provide adequate protection for
the cover time defined within the Information
Security Design.
For symmetric/secret key cryptography, key

lengths of at least 256 bits should be used for
information of classification ‘Confidential’ or
above.
For asymmetric/public key cryptography, key

lengths of at least 1024 bits should be used for
information of classification ‘Confidential’ or
above.

IS.5.4 Hybrid cryptographic systems (i.e. ones making S M M
use of both symmetric and asymmetric
algorithms) should be considered in order
to achieve a balance between cryptographic
system manageability and system performance.

IS.5.5 The Entity should only solicit public key M M M
certificates from ADSIC-approved Certification
Authorities.
IS.5.6 Users of information systems should be M M M

prohibited from using cryptographic controls
that are not part of an approved Information
Security Design.
IS.5.7 Cryptographic controls should be designed M M M

and implemented in a manner considerate
of the Entity’s need to effectively monitor its
information flow, retain oversight of information
system usage and protect against malicious
software.
IS.5.8 The Entity should have in place adequate S M M

provisions for key management of crypto-
graphic systems including issuing, changing and
revoking keys as necessary.
IS.5.9 For data hosted at Entity-owned facilities, S R R

cryptographic protection should be applied to
data at rest.
163
IS.5.10 Data hosted at non Entity-owned facilities e.g. M M M
third-party data centres should be subject to
strong encryption protection at rest.

IS.5.11 Data transmitted to/from non-Entity-owned R M M
facilities (e.g. third-party data centres) should be
subject to strong encryption to protect data in
motion.

IS.5.12 Workflow approval within information systems S S S
should be supported via the use of digital
signatures using public key cryptography.
Control
Dependencies

o 12.3.1 Policy on the Use of Cryptographic Controls
o SC-13 Use of Cryptography
• NIST Special Publication 800-78-3 ‘Cryptographic
Algorithms and Key Sizes for Personal Identity Verification’
• RSA Laboratories – recommendations for public key
system key sizes
Testing Guide

IS.6 Information Leakage Prevention Version 2.0
Suggested P2
Priority
Control The entity should design information systems to prevent
Standards unintentional information leakage.
IS.6.1 The entity should design information systems R R M
with a focus on identifying the appropriate
location(s) for the storage of information.
Boundaries for information repositories should
be adequately defined and suitable protections
applied to their boundaries when the information
system is being designed and developed.
The Information Security Design should provide

a baseline for acceptable information storage
and transmission parameters, against which
extrusion monitoring can be conducted (see
OM.11 Information Extrusion and Detection).
IS.6.2 When developing and testing information R R M

systems, the entity should ensure that the
normal operations of the information system
(e.g. the computation of cryptographic
calculations) and exception states (e.g.
the generation of error messages) do not
unintentionally leak information of potential
benefit to an attacker.
IS.6.3 The entity should apply shielding mechanisms S S S

to protect information systems and networks
from information leakage due to electro-
magnetic signals emanations.
165
IS.6.4 The entity should design and deploy end-point S S R
protection to prevent the copying of information
systems data to removable media (e.g. DVDs,
USB sticks).

Control IS.2 Information Security Design

Dependencies

o 12.5.4 Information leakage
o PE-19 Information Leakage
Testing Guide

IS.7 Mobile Code Protection Version 2.0
Suggested P1
Priority
Control The Entity shall implement mobile code protection on all
Standards information systems.
q a Detective
q q Corrective
IS.7.1 The Entity should implement procedures and M M M
tooling that address mobile code. Appropriate
controls should be introduced to restrict the use
of mobile code not approved by the Entity.
IS.7.2 Users should be made aware of the dangers of M M M

mobile code.
IS.7.3 The Entity should receive information system S R R

security alerts/advisories regarding mobile code
vulnerabilities on a regular basis, issue alerts/
advisories to appropriate personnel, and take
appropriate actions in response.
IS.7.4 Appropriate authorisation should be given for R R R

the use of mobile code on information systems.
(Example technologies being: Java, JavaScript,
ActiveX, PDF, Postscript, Shockwave movies,
Flash animations, and VBScript). Unless a given
mobile code type is explicitly authorised, it should
be restricted.
IS.7.5 Usage restrictions to limit the use of mobile code R R R

should be designed into information systems,
with appropriate warnings being generated for
users ahead of mobile code being invoked.
167
IS.7.6 The Entity should consider prohibiting the R R R
downloading and execution of mobile code on
individual computing devices.
IS.7.7 Appropriate Entity officials should authorise S S S
the use of mobile code. Usage restrictions and
implementation guidance should apply to both
the selection and use of mobile code installed
on Entity servers and mobile code downloaded
and executed on individual workstations. Control
procedures should prevent the unauthorised
development, acquisition, or introduction
of mobile code within the information
system.

Control
Dependencies
References • Abu Dhabi Information Security Design, Development and

Testing Guide

IS.8 Security Appliance and Security Version 1.0
Software Design Suggested P1
Priority
Control The Entity shall design and deploy Information Security
Standards appliances and software to support its Information Security
objectives.
a q Preventive a Detective
q q Corrective
IS.8.1 Information Security appliances and software M M M
should be selected and deployed to tangibly
support the Entity’s Information Security
programme and to reduce its exposure to risk.
Security appliance/software may include:

firewalls, intrusion detection and intrusion
prevention devices, spam blocking, log analysers,
security event monitors, vulnerability scanners,
anti-virus software and other capabilities types
deemed necessary in support of the Information
Security programme.
IS.8.2 Information Security appliances and security M M M

software should only be implemented and
managed by trained and authorised personnel,
with a specifically defined role in Information
Security.
IS.8.3 The Entity should specifically prohibit the M M M

possession and use of security software such
as network sniffers and password crackers by
non-authorised personnel; or use by authorised
personnel in a non-authorised manner.
169
IS.8.4 Testing of security appliances/software should M M M
seek to confirm:
• Does the appliance/software function as
envisaged in the agreed Information Security
design? (For example, detecting anomalous
events in the manner and time envisaged).
• Could the appliance/software be circumvented

by a malicious attacker?
• Does the appliance fail in a secure state?
IS.8.5 The Entity should consider a defence-in-depth M M M

approach for its security appliances/software, to
provide multiple levels of protection e.g. both
exterior and interior firewall protection.

Control
Dependencies

Testing Guide

IS.9 Management of Development Version 2.0
and Test Access Suggested P3
Priority
Control The Entity shall ensure that developers’ and testers’ access to
Standards information systems is removed when no longer required.
IS.9.1 The Entity should implement procedures R R R
that limit developers’ and testers’ access to
information systems to only those areas of the
system and those periods of the development
and test lifecycle necessary for their work to
be completed. Prior to being commissioned,
developer and tester accounts should be
removed.
IS.9.2 Where developers need to provide on-going R R R

support of the information system after its
commissioning, or where testers require
business-level access, standard user or super user
accounts (as appropriate) should be created for
this purpose.
IS.9.3 Information system commissioning checks R R R

should confirm that legacy user, administrator,
developer and tester accounts do not remain
on the information system after its move to
production status. Accounts without a verified
need during the production phase of the
information system’s lifecycle should be purged
prior to the move of the information system to
production status.
Control
Dependencies

Testing Guide
171
IS.10 Network Segregation Version 2.0
Suggested P2
Priority
Control The Entity shall segregate information services, users, and
Standards information systems in networks, based upon sensitivity and
risk exposure.
IS.10.1 Any connections to public networks or M M M
information systems should occur through
controlled interfaces (e.g., proxies, gateways,
routers, firewalls, encrypted tunnels).
IS.10.2 The operational failure of network boundary M M M

protection mechanisms should be detected and
should not result in any unauthorised release
of information outside the information system
boundary.
IS.10.3 The Entity should employ Network Address R R R

Translation (NAT) to prevent the typology
and configuration of its core network being
discoverable by outside parties.
IS.10.4 The Entity should employ Virtual LANs (VLANs) R R R

within its core network to segregate user groups
from a) each other and b) information services.
IS.10.5 The Entity should consider deploying multiple R R R

VLANs to delineate the differing levels of its IT
architecture (i.e. web/application/database/
storage area network).

IS.10.6 The Entity should consider segregating S R M
individual application servers into their own
VLAN segments.
IS.10.7 The Entity should consider the deployment S R M

of access control lists, internal firewalls and
intrusion detection capabilities within its core
network, to segregate and monitor particularly
sensitive information assets and information
systems.

IS.10.8 Boundary firewalls should be stateful, only M M M
permitting connections between networks where
a well-formed network session can be confirmed.

IS.10.9 One or more ‘Demilitarized Zones’ (DMZs) R M M
should be created to segregate externally
published/available services from the Entity’s
information systems intended for internal use
only. Individual DMZ network segments for
each published service should be considered
to prevent compromises propagating between
services.
IS.10.10 Any information system holding data of M M M

classification ‘Restricted’ or above should reside
on the Entity’s core network and never be
directly accessible from a public network (e.g. the
Internet). The establishment of a DMZ may be
used to securely facilitate access to the data by
approved users external to the organisation.
IS.10.11 Network devices and information systems within R R M

the core network (i.e. behind the boundary
defences) should be configured to not respond
to external requests for profile data (e.g. ping,
traceroute).
173
IS.10.12 DMZ-based information systems should R R R
communicate with information systems within
the Entity’s core network via an application proxy.
IS.10.13 Networks should be categorised (see SG.2 M M M

Information Security Categorisation) at a level
corresponding to the highest information system
categorization present on that network.

IS.10.14 The network routing protocols deployed for R R R
communication with external networks should be
different than those used on internal networks.
IS.10.15 Information systems and workstations should not R R R

be connected to any other network at the time
of their connection to the Entity’s core network.
Ad-hoc bridging of networks via a workstation
should be prohibited.
Control SG.2 Information Security Categorisation

Dependencies

Testing Guide
• ISO 27002 Information technology — Security techniques
o 11.4.6 Network connection control
o AC-4 Information Flow Enforcement
• SANs Institute: ‘Design Secure Network Segmentation
Approach’ http://bit.ly/tOjoW2

IS.11 Routing, Switching and Network Version 1.0
Patching Security Suggested P2
Priority
Control The Entity shall implement appropriate controls to secure its
Standards data networking infrastructure.
IS.11.1 The Entity should employ gateway-to-gateway S R M
strong encryption to protect data traffic
transiting between its physical locations, to limit
the potential for eavesdropping.
IS.11.2 Routing and switching equipment should be M M M

housed in physically secure locations, to which
only approved personnel have access.
IS.11.3 Network routers should be configured to permit M M M

exchange of routes only with trusted parties.
IS.11.4 Simple Network Management Protocol (SNMP) S R M

should be disabled on devices unless it is actively
used for network management. Where SNMP
is used for communication between network
devices, the preferred version should be version
3.x. or later. Version 2.x should only be used by
exception. Earlier versions of the protocol should
be disabled on devices capable for running them.
A strong community string should be used with
SNMP.
IS.11.5 Network routers and switches should be M M M

hardened to limit the attack surface that they
present. Hardening of network devices may
include (but not be limited to):
• Disabling unused protocols and network
services
• Disabling unused network interfaces and VTYs

(Virtual Teletypes)
175
IS.11.5 • Disabling unused ports M M M
(Cont.)
• Disabling unnecessary message types received
on a network interface
• Enabling hashing of network device passwords
• Setting CPU and memory thresholds
• Reserving memory for console access
• Enabling detection of memory leaks and buffer

overflows
• Filtering questionable packet types (e.g. ICMP

packets, IP fragments, TTL value in packets)
• Control plane protection via port filtering and

queue thresholds
• Configuring anti-spoofing protections
• Broadcast Storm control per interface to limit

the broadcast from an infected machine.
IS.11.6 The Entity should protect itself against potential R R R

Denial of Service attacks on its network.
Protections may include:
• Rate Limiting for certain data types e.g. SYN
packets
• Unicast Reverse Path Forwarding (uRPF)

checking
• Applying ingress and egress filtering using

Access Control Lists
• Limiting ICMP packets

IS.11.7 Switches should be used in preference to network R R R
hubs and Virtual Local Area Networks (VLANs)
should be configured on switches to segregate
different:
• User communities
• Information system categorisations
IS.11.8 Virtual Trunking Protocol (VTP) should be R R R

disabled on switches, unless specifically required.
Where enabled, the following should be set
for VTP: management domain, password and
pruning. VTP should be set to Transparent Mode.
IS.11.9 The Entity should consider the deployment of S S S

a password management system for network
devices that allows for the concurrent updating
of passwords across the network infrastructure.
IS.11.10 Router and switch operating systems should be M M M

regularly patched and updated as indicated by
the device vendor.

IS.11.11 The SSH protocol should be used in preference to R R R
Telnet for communication with network devices.
IS.11.12 Routers and switches should be managed out-of- S S S

band where possible. Where this is not feasible,
a separate VLAN should be created for in-band
management.
IS.11.13 Port security should be enabled on switches to R R R

limit access based on MAC addresses. Auto-
trunking should be disabled on ports. Trunk ports
should be assigned a native VLAN number that is
not used by another port.
177
IS.11.14 The Entity should consider deploying tooling to S S S
detect potential and actual attacks on the TCP/IP
Address Resolution Protocol (ARP) and to deploy
Dynamic ARP inspection to avoid man-in-the-
middle attacks.
IS.11.15 The Entity should restrict network broadcasts S S S

to only essential traffic required in support of
an approved network design. Non-authorised
broadcasts should not be forwarded by routers.

IS.11.16 Ingress and egress filtering should be deployed R R R
at boundary routers to limit the potential for IP
address spoofing.
Control
Dependencies
References • SANS
o Critical Control 10: Secure Configurations for Network
Devices such as Firewalls, Routers, and Switches
o Critical Control 19: Secure Network Engineering
Testing Guide

IS.12 Wireless Network Security Version 1.0
Suggested P2
Priority
Control The Entity shall ensure that wireless networks and wireless-
Standards enabled devices are suitably protected.
q a Detective
q q Corrective
IS.12.1 Prior to deploying wireless base stations, the M M M
Entity should undertake and document a site
survey to determine the optimal physical
locations for their placement. The need to
provide sufficient signal coverage to a defined
area should be balanced against the need to
avoid stray signal leaking too far outside of the
Entity’s physical perimeter.
IS.12.2 The Service Set Identifiers (SSIDs) of wireless S S S

base stations should either not be broadcast or
should be anonimised, so as to avoid the wireless
network being associated with the Entity by
non-approved network users.
IS.12.3 Authentication to a wireless base station M M M

should only be via strong encryption, with no
authentication credentials being transmitted in
the clear over the air.
IS.12.4 The Entity should prohibit and sanction the M M M

creation and use of ad-hoc wireless networks,
including the connecting of unapproved wireless
base-stations to the Entity’s core data network.
179
IS.12.5 Workstations and mobile devices should be R R R
restricted from accepting inbound wireless
connections while their wireless cards are
enabled.
IS.12.6 Data of classification ‘Confidential’ or above M M M

transiting over a wireless network should be
subjected to strong encryption to protect its
confidentiality.
IS.12.7 The Entity should put in place mechanisms that R R R

allow for the identification and isolation of rogue
wireless access points.
IS.12.8 Connections to the Entity’s core network initiated M M M

from a wireless station should be subject to
equivalent authentication and access control
processing as would apply to a wired connection
to the network. No connection to services on the
core network should be permitted from generic
accounts or anonymous users.
IS.12.9 The Entity should consider authenticating S S S

wireless stations to client devices, as well as
authenticating clients to base stations, via use of
802.1x authentication.

IS.12.10 The use of ‘guest’ wireless networks should be R R R
restricted to genuine short-term guests of the
Entity and consultants without a verified need for
connection to the Entity’s core network. Guest
networks should only connect to the Internet
and their data should not transit via the Entity’s
core network. Traffic on wireless guest networks
should not be terminated on the core network
and should be tunnelled directly to the network
perimeter.
A client device should not be permitted to connect

to the core network and the guest network at the
same time.
Traffic on guest networks should be monitored

by the Entity to ensure conformance with its
acceptable usage provisions. Temporary users of
guest networks should be required to authenticate
to the network, to avoid opportunistic use of the
Entity’s network resources.
IS.12.11 When using public wireless base stations (e.g. S S S

ones in hotels, coffee shops, airports etc.), Entity
staff should be required to establish a VPN tunnel
before data of classification ‘Restricted’ or above
is sent or received.
IS.12.12 Unless there is a verified business need and S S S

appropriate security controls have been
deployed, the Entity should consider disabling
short-range and near-field wireless functionality
on computing devices e.g. Bluetooth.
181
IS.12.13 When designing its wireless networks, the Entity S S S
should consider the number of base stations to
be deployed, where they will be situated, what
bandwidth limitations should apply to clients
and what wired alternatives should exist, so as
to limit the potential for wireless-based Denial of
Service attacks.
IS.12.14 The Entity should consider restricting the time S S S

period during which connections to its wireless
networks are permitted (e.g. restriction to
working days and working hours).

Control
Dependencies

o AC-18 Wireless Access
• NIST Special Publication 800-153 ‘Guidelines for Securing
Wireless Local Area Networks (WLANs)
• NIST Special Publication 800-97 ‘Establishing Wireless
Robust Security Networks: A Guide to IEEE 802.11i’
Testing Guide

IS.13 Information Systems and Network Version 1.0
Security Testing Suggested P2
Priority
Control The Entity shall conduct Information Security testing of
Standards information systems and networks.
q q Corrective
IS.13.1 The Entity should develop an Information M M M
Security Test Plan for all information systems
and information networks.
For new information systems and networks, the

test plan should be developed during the design
phase of the information system’s lifecycle. For
existing information systems and networks, the
test plan should be developed at a time deemed
appropriate by the Information Owner and the
Information System Owner custodian.
The test plan should confirm:

• What specific, uniquely identified Information
Security controls are in scope for testing.
• Whether any Information Security controls

will be omitted from the testing exercise, the
rationale for their exclusion and the associated
risk.
• How the controls will be tested.
• Who will test them and what their

competencies and qualifications are to
undertake such tests.
• How test results will be documented and

communicated to relevant stakeholders. (With
provision for how results will be secured from
access by unauthorised parties).
183
IS.13.1 • What minimum acceptable outcomes are M M M
(C0nt.) required for the test to be deemed successful i.e.
- the acceptance criteria articulated by
relevant key stakeholders including the
Information Owner and the Information
System Owner.
- the compliance requirements imposed by

these Standards.
(The Information Security Test Plan should

support full traceability, from requirements
definition to the design and implementation of
controls, through to testing of those controls to
verify their ability to meet requirements).
IS.13.2 Information Security testing should seek to R R R

confirm whether:
• The control is configured in a manner consistent
with the target configuration defined for it
within the Information Security Design.
• The control performs in a manner consistent

with the performance baseline defined for it
within the Information Security Design.
• The control cannot be bypassed, compromised,

fed erroneous data or otherwise compromised.
• The alerting associated with detective controls

is timely and accurate.
• The control is capable of supporting the

anticipated loading defined within the
Information Security Design (e.g. x number of
concurrent transactions per second through
the Internet proxy).

IS.13.2 • The generation of false negative and false M M M
(C0nt.) positive results is within acceptable thresholds
defined within the Information Security
Design.
• The control fails to a safe state when adverse

conditions are simulated.
• The control’s deployment and usage avoids

introducing secondary risks.
• Common vulnerabilities applicable to the

technology type are not capable of being
exploited.
• Management information generated by or

in relation to the control is accurate, relevant
to management of the control/information
asset and is generate in a timely way.
• The administrative and management support

required for the control are in place and are
effective.
IS.13.3 The Information Security Test Plan should be R R R

developed in concert with the functional and
non-functional test plans for the information
system, to ensure a coherent and integrated
approach is taken to testing.
IS.13.4 The Information Owner and System Owner M M M

should be informed signatories of both the
Information Security Test Plan and the associated
results report.
185
IS.13.5 The Information Security Design (see IS.2 M M M
Information Security Design) may make use of:
• Controls that are developed specifically for the
information system concerned.
• Existing common controls that apply to

multiple information systems.
• A combination of both of the above.
Where an existing common control (see SG.11

Common Control Catalogue) is to be applied to a
new information system, it should be re-tested
to ensure that:
• The confidentiality, integrity and availability
baseline of the common control is not
compromised by its application to the new
information system.
• The additional anticipated demand on

the control is within acceptable capacity
parameters (e.g. the control is able to process
the additional number of transactions that
would be generated).
• New vulnerabilities are not introduced as

a consequence of making this connection
between the new information system and the
common control.
IS.13.6 Upon request, the Entity should make available M M M

its test plans and test results to ADSIC. These
will serve as a key input to information system
accreditation activities.

IS.13.7 The Entity’s Change Management process M M M
should consider the impact of proposed changes
on a security control. Substantial change would
require Information Security testing to be
repeated during the control’s life.
IS.13.8 Information Security testing should seek to M M M

simulate common attacks and exploitations
relevant to the target technology and
information types.
IS.13.9 The Information Security test plan and M M M

Information Security test results should be
retained in a secure manner but be made readily
accessible to relevant, authorised parties in the
event of them needing to be used by the Entity’s
Information Security Incident Management
process.
IS.13.10 During the information system or network’s M M M

production lifecycle, on-going vulnerability
scanning should be used to determine if any
new vulnerability has been introduced after the
completion of original security test. (See OM.7
Technical Vulnerability and Patch Management).
IS.13.11 Software security testing should make use S R M

of code analysis tools to identify common
programming flaws.
IS.13.12 In addition to information system or network- R M M

specific security testing, the environment in
which the information system is deployed
should also be subject to regular wide-ranging
penetration testing that seeks to simulate the
exploitation of vulnerabilities across multiple
elements of the Entity’s information technology
estate.
187
IS.13.13 A formal Information Security Test Report should R M M
be produced confirming:
• What tests were conducted and when during
the development lifecycle they occurred.
• Who the tests were conducted by
• What deviations from the approved

Information Security Test Plan occurred,
why and what consequences arise from the
deviation
• What findings the tests produced
• What recommendations have been made by

the tester regarding the information system’s
security, relative to the agreed design and
associated requirements
• What decisions have been taken in light of the

findings and recommendations
• What risks remain unaddressed on completion

of the testing
IS.13.14 The Information Security Test Report should R M M

be approved by the Chief Information Security
Officer, the Information System Owner and the
Information Owner. The report should serve as
a key input into the ‘go/no go’ decision made
regarding the move of the information system to
production status. Where the CISO, Information
System Owner and Information Owner cannot
ratify the test report then the system should
not assume production status. In such an event,
options available to the decisions makers are:
• Rerun the same tests to validate the results
• Develop new test cases if the original ones

were incorrectly scoped

IS.13.14 • Redesign the information system’s control R M M
(C0nt.) set to address shortcomings identified during
testing
• Accept the attendant risk(s), either as-is or

with the application of compensating controls.
(Risk acceptance can only occur within the
boundaries of the Entity’s decision-making
powers. Entities cannot accept risks related
to Control Specification elements shown as
‘Mandatory’ in these Standards, unless there is
prior agreement on exemption with ADSIC.).
Note: ‘production status’ means that live

business data is present on the information
system. Avoiding the ‘production’ designation
(e.g. by keeping an information system at test
status indefinitely) is not permitted as a means
to bypass the obligations imposed above. Where
any information system is hosting or processing
live business data, that information system’s
Information Security Test Report must have been
authorised in the manner described.
Control
Dependencies

o 10.3.2 System acceptance
o 12.5.5 Outsourced software development

o SA-11 Developer Security Testing
o SI-6 Security Functionality Verification
o SI-7 Software and Information Integrity

Testing Guide
189
IS.14 Domain Name Service Security Version 1.0
Suggested P2
Priority
Control The Entity shall protect its Domain Name Service facilities to
Standards ensure the integrity and availability of its network address space.
IS.14.1 The Entity should deploy Domain Name Service M M M
(DNS) in a hierarchical, structured fashion. All
internal networks client machines should be
configured to send requests to intranet-based
DNS servers, not DNS services located outside of
Entity’s core network.
IS.14.2 DNS servers should be hardened to restrict their R R R

configuration to only essential processes. DNS
should not be co-located on servers running
other application types.
IS.14.3 DNS zones should be signed using an asymmetric R R R

cryptographic key pair to provide data origin
authentication.
IS.14.4 Name servers should be configured to turn on R R R

DNSSEC processing, in support of data origin
authentication.
IS.14.5 Updates to DNS servers should require multi- R R R

factor authentication, to limit the potential for
unauthorised updates to DNS records and zone
files.

IS.14.6 DNS zone file(s) should regularly be reviewed (at S S S
least quarterly) for any possible integrity errors.
IS.14.7 The Entity should consider designing its DNS S S S

capabilities to achieve network topological and
geographic dispersion of authoritative name
servers, in order to improve fault tolerance.
IS.14.8 DNS servers should be protected via network S S S

Quality of Service (QoS) and ingress filtering
controls, to limit the potential for packet flooding
attacks.
IS.14.9 BIND installations and the DNS server operating R R R

systems should be regularly patched to limit the
potential for vulnerabilities within the Domain
Name Service from being exploited.
Control
Dependencies
References • NIST SP 800-81 ‘Secure Domain Name System (DNS)

Deployment Guide’
Testing Guide
191
IS.15 Protection of Information System Version 2.0
Test Data Suggested P3
Priority
Control The Entity should select information system test data carefully,
Standards and provide protection when sensitive data is involved.
IS.15.1 Information of classification ‘Restricted’ or M M M
above, or information that is directly attributable
to named individuals should be not be used for
the purpose of information system test data,
wherever possible. When this is not possible,
the data should be randomised and anonimised
before testing commences.
IS.15.2 All test data should be purged from the M M M

information system once testing has been
completed.
Control
Dependencies

Requirements:
o 12.4.2 Protection of System Test Data
o AC3 Access Enforcement
o AC4 Information Flow Enforcement
Testing Guide

12.9 Identity & Access Management
IA.1 Identity Management Version 1.0
Suggested P1
Priority
Control The Entity shall ensure that it verifies the identity of users and
Standards information systems intended to have access to its information
assets.
q q Detective
a q Corrective
IA.1.1 The Entity should ensure that the identity of all M M M
information users is initially authenticated via
reference to original primary source photo ID
(passport, Emirates ID card, UAE driving license)
as part of the enrolment process for access to
Entity information systems, premises, processing
facilities and data stores.
IA.1.2 Re-authentication of information users should M M M

take place when changes to their access is
required and/or requested e.g.:
• Password reset
• Account re-enablement following lock-out
• Increase in privilege level
• Change of name
Such changes should not be made unless the

Information System Owner (or their nominated
delegate) has satisfied themselves that the
person requiring or requesting the change has
the identity associated with the given account.
It should not be assumed that a requester is
the person claimed, unless there is definitive
recognition via facial recognition, vocal
recognition or re-checking against primary
source ID.
193
IA.1.3 Identity verification via primary source ID R R R
checking should be undertaken for all visitors
to the Entity’s principle data processing (e.g.
data centre) and data archiving facilities. The
verification should occur on each occasion
of a visit, unless and until the party has been
approved for regular, unescorted access to the
facility. The visitor’s name, the ID type reviewed
and the ID number should be recorded in a facility
access log.
IA.1.4 Information systems and network devices R R R

requesting access on behalf of themselves
or as proxies on behalf of users should be
authenticated via trust mechanisms such as
secure directories and public key certificates.
IA.1.5 Foreign identity documents that the Information S S S

System Owner cannot readily confirm the
voracity of (e.g. overseas driving licenses,
student cards) should not be accepted for the
purpose of primary source ID.
IA.1.6 Foreign passports should not be accepted as S S S

a source of primary ID unless and until the
individual concerned has been confirmed as
screened by the relevant UAE authorities.
IA.1.7 Where the use of Public Key Infrastructure (PKI) R R R

capabilities applies, the Entity should apply
particular vigilance to verifying an identity before
it is bound to a public key certificate. Given the
sensitivity of the process and the one-time
nature of the association, multiple individuals
should check that the identity is the correct one.

IA.1.8 Where a Public Key Infrastructure is used, the R R R
information system should:
• Validate user and information system
certificates by constructing a certification path
to a known and trusted Certification Authority.
• Ensure that the user’s private key is protected

from potential usage by another party.
Control HR.2-Screening
Dependencies

Requirements:
o 11.2.1 User registration
• NIST Special Publication 800-63-1 ‘Electronic
Authentication Guide’
195
IA.2 Account Management Version 2.0
Suggested P1
Priority
Control The Entity shall ensure that accounts on information systems are
Standards managed and monitored.
q a Detective
q q Corrective
IA.2.1 The Entity should ensure that a formal M M M
registration and de-registration process is in
place for granting and revoking accounts on
IA.2.2 Information system users should be provided M M M

with unique account IDs to allow for confirmation
that all activities undertaken via that account
can reliably be associated with the specific user.
Generic accounts should never be permitted on
any Abu Dhabi government information system.
IA.2.3 Obsolete accounts should not be re-issued to M M M

other users.
IA.2.4 Accounts should be revoked in accordance M M M

with the Human Resources provisions of these
standards (see HR.6 End of Employment Security).
IA.2.5 On a regular basis (at least quarterly) the Entity M M M

should formally review the accounts on its
information systems and ensure that all accounts
remain valid and in active use. Dormant accounts
should be backed up and then purged from the
production system.
Dormancy will be determined on the basis that:

a) The account holder has left the organisation
or
b) They remain with the organisation but have
not accessed the account recently (e.g. within
the previous three months).

IA.2.5 The only exception to the purging of dormant M M M
(Cont.) accounts should occur when the account has
been confirmed as being part of the evidence set
related to an Entity or police-led investigation.
The Entity should additionally consider

automatically disabling inactive accounts after
an Entity-defined period of inactivity.
IA.2.6 Root accounts should never be directly used on M M M

information systems. Any activities requiring
such access should be conducted via the
administrator’s individual account, with elevated
privileges assumed (e.g. sudo access in Linux/
Unix environments).
IA.2.7 Default accounts provided by suppliers on a new M M M

systems or device should be removed as part of
the equipment’s commissioning and prior to its
connection to the Entity’s network.
IA.2.8 Account access should be disabled if there are M M M

multiple unsuccessful log-in accounts made:
a) Consecutively (e.g. three successive attempts)
and
b)
Within an a given time period (e.g. six
unsuccessful attempts within a twenty-four
period)
(The thresholds for these restrictions should be

defined by the Entity, on the basis of the sensitivity
of its data, the maturity of its information security
architecture and its own assessment of risk).
197
IA.2.9 Unsuccessful account access attempts should be M M M
analysed and root cause analysis undertaken. A
substantial number of unsuccessful attempts
(either as a long-term trend or as a peak) may be
indicative of:
• Unauthorised access attempts/an attempted
attack.
• An unrealistically complex password policy

that users struggle to comply with.
• The need for improved and additional IT and

Information Security training.
IA.2.10 The Entity should consider the deployment of a S S S

Single Sign-On (SSO) architecture, to limit the
need for users to remember access credentials
for a range of different accounts.
Control HR.6 – End of Employment Security

Dependencies

Requirements:
o 11.2 User access management
o AC-2 Account Management

IA.3 Information System Authentication Version 1.0
Suggested P1
Priority
Control The Entity shall ensure that passwords and tokens granting access
Standards to information systems and network devices are protected.
q a Detective
q q Corrective
IA.3.1 Passwords and/or tokens associated with M M M
information system accounts should not be
made available to the user until:
• Their identity has been verified
(see IA.1 Identity Management).
• The user has signed a statement confirming

(as applicable) that they commit to:
- Keeping the password confidential

(including not sharing the password with
others and not keeping it in unsecured
written form)
- Keeping the token in safe keeping and not

sharing it with others
- Abiding by the ‘Acceptable Usage’

provisions contained within the Entity’s
Information Security policy and in their
Terms & Conditions of Employment (see
HR.3 Terms and Conditions of Employment).
199
IA.3.2 The account ID and the account password should M M M
be communicated via separate channels to the
user. (E.g. the account ID being sent by mail, with
the password being sent via SMS text message).
To avoid potential interception, passwords

should not be sent to users via:
• Electronic mail (especially where the mail will
be sent beyond the Entity’s local mail server)
• Communication to another person, such as the
user’s colleague
• Fax
• Internal post
IA.3.3 The Entity should define within the Information M M M

Security Design the parameters of passwords
used on its information systems. This should
take into account the sensitivity of the data
being manipulated or stored on the information
system. However, as a minimum, the Entity’s
information systems should enforce a password
policy that requires passwords to be:
• At least eight characters long.
• A mixture of letters, numbers and special

characters.
• Changed at a frequency determined by the

Entity to be appropriate to the sensitivity of
the data being accessed.

IA.3.3 (This password change frequency should M M M
(Cont.) be defined within a range i.e. the password
change being required no more than once
every 30 calendar days and not less than every
90 days).
• Not re-used frequently over the life of the user’s

information system access. (For example,
with the information system mandating that
the password not be reused within twelve
iterations of the password being changed).
• The Information Owner and individuals users

should retain the right, and be afforded the
permissions, to change their password more
frequently and to apply a greater level of
password complexity, than the information
system-mandate minimum, if they so choose.
IA.3.4 New and re-enabled accounts should be set with M M M

a temporary password that the user is forced to
change on the first/next log on to the information
system. The temporary password should be
unique (i.e. the same temporary password should
not be issued to more than one user; and should
only be issued to the same user on one occasion)
and should not guessable (e.g. passwords such as
‘LetMeIn’, ‘ChangeMe’, ‘Guest1234’ should not
be issued to users).
IA.3.5 Passwords must not be stored in plaintext M M M

anywhere on information systems and network
devices. Any stored password or password
database should be held in hashed form.
201
IA.3.6 Information systems should prevent entered M M M
passwords from being displayed on screen to
avoid the potential for the password to be seen
by non-authorised parties.
IA.3.7 Information systems should require user access M M M

to operating systems to be controlled via a secure
log-on procedure/secure attention sequence
(e.g. Control-Alt-Delete in Windows) to provide
for a trusted path between the information
system user and the authentication manager
within the operation system.
IA.3.8 The Entity should consider the deployment S S S

of a password self-service capability, allowing
information system users to create and reset
passwords themselves on the basis of their
ability to verify their identity against previously
provided shared secret data.
IA.3.9 The Entity may consider the deployment of S S S

biometric authentication mechanisms (e.g.
laptops fitted with fingerprint scanners), as
an alternative to passwords, where there is a
business justification for such.
Control
Dependencies

— Information Security management systems
— Requirements:
o 11.2.3 User password management

IA.4 Privilege and Access Management Version 1.0
Suggested P1
Priority
Control The Entity shall ensure that information access and information
Standards system privileges are only granted to those with suitable
approval.
q a Detective
q q Corrective
IA.4.1 The Information Owner should approve, in M M M
advance, any requirements for access to
information assets. Access should be granted
on the basis of a verified need to know. Records
of approval should be retained for verification
purposes.
IA.4.2 Approval for information access should explicitly M M M

state:
• What information is in scope
• What level of access to this information is being

granted (i.e. read, write, deleted, execute).
• To whom the access is being granted
• Whether any restrictions apply to the access

approval (e.g. it is only for a defined time
period)
The level of access granted should not exceed

that required to undertake the defined activity.
IA.4.3 Upon a change of roles within the Entity, the M M M

user’s level of information access should be
reviewed to determine if it remains appropriate.
Access types no longer required within the new
role should be revoked.
203
IA.4.4 Elevated information system privileges (e.g. M M M
account creation, deletion) should only be
granted to nominated information system and
network administrators with a defined role and
relevant skills, experience and qualifications
applicable to the use of those privileges.
IA.4.5 Elevated information system privileges should M M M

be considered as a potential source of risk for
the Entity. The use of such privileges should be
monitored to ensure their use is confined to the
original purpose intended and that they are being
exercised responsibly.
IA.4.6 All access to Entity information systems should M M M

be recorded (see OM.20 System and Network Log
Management and Analysis).
IA.4.7 Information systems should display an approved M M M

system use notification before granting access.
This should inform the user that:
• He or she is accessing an Abu Dhabi
information system
• Information system usage may be monitored,
recorded and possibly subject to audit
• Access may be revoked at any time, where this
is deemed necessary by the Entity
• Access to the information system indicates
consent to monitoring and recording
IA.4.8 On a regular basis (at least semi-annually) the M M M

Entity should formally review access granted to
its information systems and the system privileges
allocated, to ensure that they remain relevant
to business need. Where changes in business
circumstances mean that access or privileges are
no longer required, these should be revoked.

IA.4.9 Entity information systems should implement M M M
technical access control policies (that may be
identity, role or attribute-based policies) and
mechanisms to enforce those policies (e.g.
access control lists, access control matrices,
cryptography).
The policies and enforcement mechanisms

should be employed by the Entity to control
access between users (or processes acting on
behalf of users) and objects (e.g., devices, files,
records, processes, programs, domains) in the
information system.
IA.4.10 The Entity should implement role based access R R R

control that defines the level of access required
based upon the work to be undertaken by the
information system user. This provides greater
flexibility in user provisioning and system
administration while maintaining a defined level
of security.
IA.4.11 Entity network devices should have AAA R R R

(Authentication, Authorisation and Accounting)
enabled. Configuration of AAA should be made
via use of a TACAS + or RADIUS server. Method
lists should be defined for the purpose of
authentication to the network device and method
lists should be applied per network interface.
Control OM.20 – System and Network Log Management and Analysis

Dependencies

Requirements:
205
IA.5 Remote Access Version 1.0
Suggested P2
Priority
Control The Entity shall ensure that remote access to its information
Standards systems and networks is controlled.
q a Detective
q q Corrective
IA.5.1 The Entity should procedurally define which M M M
forms of remote access it permits, which types of
devices are permitted to use each form of remote
access, the type of access each type of remote
access user is granted, and how user account
provisioning should be handled. Procedures
should also cover how the Entity’s remote access
gateways are administered and how policies in
those gateways are updated.
IA.5.2 Information Security aspects of the remote M M M

access solution design should be documented in
an Information Security Design for the remote
access service component.
IA.5.3 Before being activated as a production service M M M

component, a remote access solution should be
tested. The testing should encompass: connectivity,
traffic protection, authentication, management,
logging, performance, implementation security,
and interference with applications.
IA.5.4 Remote access privileges should be formally M M M

approved, on the basis of verified business need.
Remote access should not be provided by default
to all holders of accounts on the Entity’s core
network.
IA.5.5 Remote access users should be made aware M M M

of, and should be required to document, their
understanding of, and intended compliance
with, the acceptable usage obligations specific to
this service type.

IA.5.6 All remote connections to the Entity’s core M M M
network should be terminated at an Entity-
managed remote access gateway, unless the
connection is to:
• a publicly available service
• an extranet service for which alternative
authentication mechanisms are provided.
No direct remote access connections should be

permitted to other parts of the core network.
IA.5.7 All remote access connections should occur M M M

via a Virtual Private Network (VPN). The VPN
connection should be established using either
IPSec or SSL-based capabilities. VPN client
software/configurations should only be ones
approved and provided by Entity’s IT function.
IA.5.8 Remote access activity logs should be analysed M M M

regularly (at least weekly) to identify any potential
anomalies or suspicious activities. Particular
attention should be paid to time and duration of
access, as well as frequency of connection.
IA.5.9 Remote access gateways should only accept one M M M

connection per approved user account at any
one time.
IA.5.10 Two factor authentication (for example lever- R R M

aging elements that include challenge-response
security tokens or biometric-based systems)
should be used to improve authentication
mechanisms for remote access connections.
(Security tokens may be hardware or software-
based).
207
IA.5.11 While connected to the Entity’s core network R R R
via VPN, remote access users should not be
authorised to connect to other networks, to avoid
the potential for bridging between the networks.
IA.5.12 Remote access provided to third-party suppliers M M M

for the purpose of ad-hoc remote support
should be monitored and only enabled for the
period during which support is being provided.
The access should be disabled outside of these
periods. Any remote access credentials made
available to such suppliers should be provided on
the basis that the activities on a remote access
account can always be correlated to a named
individual within the supplier’s organisation.
IA.5.13 Scheduled maintenance activities on remote M M M

access solutions should include: deploying soft-
ware updates, verifying clock synchronization,
reconfiguring access control features as needed,
and detecting and documenting anomalies
within the remote access infrastructure.
Control OM.20 – System and Network Log Management and Analysis

Dependencies
References • ISO/IEC 18028-4 Information technology — Security

techniques — IT network security : Part 4: Securing remote
access
o AC-17 Remote Access
• Special Publication 800-46 Revision 1 ‘Guide To Enterprise
Telework and Remote Access Security’
• NIST Special Publication 800-77 ‘Guide to IPsec VPNs’
• NIST Special Publication 800-113 ‘Guide to SSL VPNs’

IA.6 Directory Management Version 1.0
Suggested P2
Priority
Control The Entity shall maintain a secure directory of its network
Standards assets and users to facilitate access to information assets.
q a Detective
q q Corrective
IA.6.1 The Entity should deploy and maintain a centrally M M M
managed directory (e.g. Active Directory) for the
management of user accounts, the granting of
permissions and the moderating of information
system access.
IA.6.2 The Entity’s directory should be designed and R R R

implemented in a manner that provides flexi-
bility to accommodate potential organisational
changes. The directory design should seek to
ensure that access permissions are not impaired
when changes to the directory are necessitated
by changes in the organisation (e.g. the breaking
of trust relationships between domains and
between trees within an Active Directory forest).
IA.6.3 Directory servers should be housed in physically M M M

secure data centre locations, conformant with
the requirements described in Control Standard
PE.4 Data Centre Security of these Standards.
IA.6.4 The Entity should define access and permissions M M M

policies on its directory service. Access to data
objects should be made only after reference to
the relevant directory policy.
IA.6.5 The Entity should monitor activity on its directory M M M

servers, with a particular emphasis on ensuring
that they have not been compromised and that
they are replicating data between themselves in
format and at a frequency consistent with their
approved design.
209
IA.6.6 The Entity’s directory service should inherit the M M M
classification of highest classified information
system to which the directory controls access.
E.g. if the directory service handles access to
‘Confidential’ information then the directory
itself should also be classified as ‘Confidential’.
IA.6.7 Candidate servers requesting permission M M M

to join a directory server group should be
authenticated, to ensure that it is appropriate
for data to be shared with them.
IA.6.8 All communications that involve the trans- M M M

mission of authentication credentials or
information system access permissions should
be subject to strong encryption, end-to-end,
from the client device through to the directory
database. [See IS.5 Cryptographic Controls].
(Examples of protocols capable of supporting
secure communication within directory message
exchanges are Secure LDAP and LDAP over SSL).
There should be no communication in plain text

of directory-related details applying to subjects,
objects and permissions. Communication
between directory server peers should also be
subject to strong encryption.
IA.6.9 Before directory management responsibilities R R R

are delegated (e.g. granting an Information
Owner the right to assign access permissions)
the Entity should ensure that the party receiving
the delegated authority has the resources, skills
and work instructions necessary to exercise the
delegation responsibly.

IA.6.10 Cross domain relationships – both within the R R R
directory and from the directory to other
directories – should be documented and
validated. Linkage of the directory with other
directories should be approved in advance by
Committee.
IA.6.11 The directory should record the classification S S S

of data objects and the authorisation level of
subjects (i.e. what classification level they are
approved to access). The directory should
invigilate access requests and approval should be
withheld where a subject attempts access of an
object at a classification level higher than their
approval.
IA.6.12 Access to data concerning the directory service’s M M M

design and configuration should be restricted to
parties with a legitimate, verified need for such
information.
Control IS.5 Cryptographic Controls

Dependencies

Requirements:
o PM-1 INFORMATION SECURITY PROGRAM PLAN
o SA-1 SYSTEM AND SERVICES ACQUISITION POLICY
AND PROCEDURES
o SA-3 LIFE CYCLE SUPPORT
211
IA.7 Connection Management Version 1.0
Suggested P2
Priority
Control The Entity shall monitor connections to its information
Standards systems and networks and apply relevant restrictions to those
connections.
q a Detective
q q Corrective
IA.7.1 The Entity should authorise connections from its M M M
information system to other information systems
outside of its core network, through the use of
Interconnection Security Agreements.
The agreement should, as a minimum, include:

• Which representatives of the involved
organisations is approving interconnection of
information systems and networks.
• How long the agreement is anticipated to be in

place and the mechanism for its review
• Which specific information systems are within

the scope of the interconnection and which
elements of the participants’ network and
information system estate will be visible to
each other.
• What communications paths/channels/routes

are authorised for the exchange of data
between the organisations.
• What protections will be put in place to

ensure the confidentiality and integrity of
data in transit via the interconnection. (This
potentially being described at a high level,
with reference made to a detailed supporting
Information Security Design).
• How the parties will coordinate changes to

their respective infrastructure in a way that will
maintain the ability to interconnect.

IA.7.1 • What protections the parties will put in place M M M
(Cont.) to ensure that they only pass to each other
reliable digital content.
IA.7.2 The Entity’s information systems should R M M

terminate or lock inactive sessions after a pre-
defined period of inactivity.
The amount of time for this should be defined

in the Information Security Design. Session
time limitations should be informed by a risk
assessment. High-risk applications should allow
only limited inactivity times, whereas low-risk
applications may generally tolerate longer
periods of inactivity.
IA.7.3 The Entity shall limit the permitted number of R R R

concurrent sessions to information systems and
applications.
The limitation on concurrent sessions should

be based upon the performance and security
baseline defined within the Information Security
Design.
IA.7.4 Information systems should only accept one R R R

connection per network account at any one
time. Where a user logs in from another network
location/device, the original connection should
automatically be terminated.
Control
Dependencies

o CA-3 Information System Connections
213
12.10 Information Systems Operations Management
OM.1 Operational Procedures and Version 2.0
Responsibilities Suggested P1
Priority
Control The Entity shall document and maintain procedures to ensure
Standards the correct definition and transaction of its Information
Security-related processes.
OM.1.1 Procedures should be developed to allow M M M
for the consistent and secure development,
introduction, management and retirement of
information assets and information systems.
OM.1.2 Procedures should form part on an integrated M M M

management system, aligned to Quality
Management best practice. Procedures should
function in support of agreed policies and should
conform to agreed documentation standards
active within the Entity.
OM.1.3 Procedures should be aligned with, and M M M

conformant to, relevant laws, directives,
regulations and government standards. Such
external references should be treated as having
priority over the procedures; and contradictions
should be resolved in favour of the external
reference.
OM.1.4 Procedures should be reviewed regularly, to R R R

ensure continued relevance and accuracy to the
work being undertaken. Review should occur at
least annually, or more frequently in the event of
major business change.

OM.1.5 Procedures should confirm the minimum M M M
mandatory activities that must be undertaken to
achieve a defined outcome.

OM.1.6 The Entity should define the roles required M M M
to transact its procedures. Procedures should
show which role has primary responsibility for
undertaking a given procedural activity.
OM.1.7 Relevant staff and supplier personnel should M M M

be made aware of procedures relevant to their
Information Security responsibilities and should
be trained in their usage.
OM.1.8 The Entity should ensure that responsibilities M M M

defined within procedures are suitably allocated
between roles, to avoid segregation of duties
conflicts.
Control • TA.4 – Security Training Development and Delivery

Dependencies • HR.4 – Segregation of Duties

o 10.1.1 Documented operating procedures
215
OM.2 Operational Change and Version 2.0
Configuration Management Suggested P1
Priority
Control The Entity shall control and document changes to the
Standards configuration and status of information assets and information
systems.
q a Preventive
q a Detective
q q Corrective
a
OM.2.1 A multi-disciplinary Change Approval Board S S R
should review and approve proposed changes
to information systems. The board’s mandate
should be formally defined and sponsored
by the Entity’s executive management. The
board’s quorum for decision making should
be defined by the Entity and the criteria for
approval determined in advance. The Entity’s
Chief Information Security Officer (CISO) should
be a mandatory member of the board and the
quorum for approving changes with a potential
Information Security impact should include the
CISO.
OM.2.2 Changes occurring during the development and R M M

operations of information systems should be
analysed by the Entity’s CISO for their potential
impact on the Information Security Programme
Plan.
OM.2.3 The Entity’s CISO should evaluate any Informa- M M M

tion Security-related change for its potential
impact upon an existing authorisation granted
to an information system. Where the change
will have a material bearing upon an existing
Authority To Operate (ATO) or Interim Authority
To Operate (IATO) then the CISO should clarify
the scope, benefit, implementation approach
and testing method with ADSIC, before giving
their approval.

OM.2.4 Changes to information systems should only M M M
be undertaken in accordance with a defined
Change Management process and only if
subjected to a change impact assessment, with
the change being implemented only if approved
in advance of the change being implemented. All
requirements for change should be documented
within a Request For Change (RFC) document.
The RFC should confirm:

• Which party is requesting the change
• What configuration items will be affected by

the change
• The nature of the change that will occur
• The anticipated business benefit/driver for the

change
• When the change is proposed to occur
• The urgency of the change
• Who will test and who will implement the

change
• Who will verify the success of the change
• What impact the change will have upon

existing references (e.g. the information
system design, relevant policies, contracts)
• Which parties are anticipated to be mandatory

approvers of the change
217
OM.2.5 The approvers of a change should be identified M M M
in advance and their involvement should reflect
their role in relation to the target of the change.
The Information Owner and/or Information
System Owner should be a mandatory approver
of any change that has the potential to affect
the availability, integrity or confidentiality of
their data.

OM.2.6 Changes should be tested before being M M M
implemented on production information
systems.

OM.2.7 The Entity should maintain Configuration M M M
Item Records (CIRs) relating to its information
assets and information systems. The CIR should
define the asset’s/system’s attributes, including
its Information Security categorisation and
configuration.
OM.2.8 The Entity should consider holding CIRs in a S S S

relational Configuration Management Database
(CMDB). The relationship between CIRs should be
shown (e.g. parent-child/sibling-sibling) with the
view to supporting change impact assessment).

OM.2.9 The Entity should consider the application of S S S
pre-approved change types, for changes to
information assets and information systems that
are regularly transacted, of low risk and which
are supported by procedural definition (e.g. user
account creation).
Candidates for pre-approval change status

should be ratified by the Entity’s Change
Approval Board prior to their usage and should
only be accepted from approved channels for
change request.

OM.2.9 The pre-approval should be of the procedural S S S
(Cont.) steps that will be undertaken when the given
change type is transacted. ‘Pre-approval’
should not be interpreted as default approval
for matters such as authorising access to
information systems. The procedural definition
of a pre-approved change may include seeking
the explicit approval of the Information Owners,
as required.

Pre-approved change types should have
thresholds defined for the number of times
that they may be transacted before additional
approval is required (e.g. a maximum of fifty
new accounts may be added to this information
system before additional approval is required).
Where there is desire or need to deviate from the

parameters of a pre-approved change type, the
modifications should be subjected to review and
approval.
OM.2.10 The Entity’s Change Management process should M M M

make provision for the application of emergency
changes, where justified.
Emergency changes will be ones requiring

implementation outside of the normal para-
meters of standard operational changes (e.g. to
facilitate the fast implementation of a critical
security patch). Emergency change provisions
should not be invoked for standard changes that
could and should have been scheduled, built and
tested in advance but were not, due to oversight.
219
OM.2.10 The process should make clear what criteria M M M
(Cont.) differentiate normal changes from emergency
changes. Emergency changes may require
streamlined approval or testing, with the view
to the rapid implementation of the change.
Emergency changes should only be applied on an
exceptional basis and the rationale for their use
should be fully justified to the Change Approval
Board at the earliest available opportunity before
or after (but preferably before) the change has
been applied.

OM.2.11 Wherever prudent and possible, changes should S R R
be grouped and implemented within defined
time periods set aside for the implementation of
changes (‘change windows’). This should be done
with the view to minimising disruption to the
availability of production information systems.
OM.2.12 Changes to information systems should be M M M

monitored for effectiveness (including on-going
compliance to the Entity Information Security
Policy and these Standards) at a defined period
after the change has been applied.

OM.2.13 The Entity should consider deploying an S S S
information system to automate the recording
Requests For Change. Entity management
should consider the performance metrics
required from such an information system.

OM.2.14 The Entity should consider deploying automated S S S
mechanisms to detect, and potentially correct,
unauthorised changes to information systems.


OM.2.15 The Entity’s Change Management process M M M
should be appropriately integrated with the
equivalent processes within third-party supplier
organisations, most especially where the Entity’s
information system is hosted by the third-party
supplier.

OM.2.16 Changes occurring during the development R M M
and operations of information systems should
be analysed for their potential impact on
the Information Security Programme Plan.
Reference should be made to ADSIC’s ‘Security
Authorisation Terms and Conditions’ document
to determine the degree of change that would
require the information system to be re-
authorised.
Control
Dependencies

o 10.1.2 Change management

o CM-1 Configuration Management Policy and Procedures
o CM-3 Configuration Change Control
o CM-4 Security Impact Analysis
o CM-5 Access Restrictions for Change
• ADSIC Security Authorisation Terms and Conditions
221
OM.3 Management of Development, Version 2.0
Test and Production Facilities Suggested P2
Priority
Control The Entity shall define and manage the boundaries between
Standards its development, test and production environments for
OM.3.1 The Entity should define the minimum, distinct M M M
levels of Information Security controls necessary
for its development, test and production
environments for information systems.
Mechanisms should exist to prevent Information
Security vulnerabilities from one environment
carrying forward to the next. Such mechanisms
may include:
• Robust Change Management (see OM.3.2 below)
• Network Access Control Lists (ACLs) restricting

information flow between the environments
• Isolating environments from each other where

a security incident has occurred within one of
them
• Account segregation (where an individual

needing access to more than one environment
has a different account and different
credentials for each environment)
OM.3.2 The movement of information assets and M M M

information systems from one environment
to another should be controlled by the Entity’s
Change Management process. No movement
between environments should occur without an
approved Request For Change.

OM.3.3 Access to information systems should be confined M M M
to the specific duties for which the individual has
been authorised. Developers, testers, systems
administrators and end users should not have
access to information system types that are not
required to undertake their specific duties e.g.
developers should not typically have access to
production information systems.
OM.3.4 Data from one environment should not transit M M M

from that environment to another without
specific and informed approval from the
Information Owner (e.g. test data should typically
not be migrated to production information
systems).

OM.3.5 The configuration of test information systems R R R
should be in alignment with their production
information system counterparts, to ensure that
test results can be quantified against a known
configuration baseline.

Control
Dependencies

o 10.1.4 Separation of development, test, and
operational facilities
o CM-2 Baseline Configuration
223
OM.4 Commissioning of Information Version 1.0
Systems and Networks Suggested P2
Priority
Control The Entity shall commission information systems and
Standards networks in a manner supportive of their secure operation and
management during production.
OM.4.1 The Entity should establish procedures and M M M
checklists for the transition of information
systems and networks from test to production
status. These should define the minimum
mandatory requirements the system/network
must meet on making the transition to pro-
duction status, including Information Security
controls, performance requirements and business
continuity arrangements.
OM.4.2 Information system and network commissioning M M M

activities should be conducted in a manner
conformant with, and subsidiary to, the Entity’s
OM.4.3 Information system/network commissioning M M M

criteria should be more stringent the higher the
information system/network categorisation is.

OM.4.4 The Information System Owner and/or M M M
Information Owner (as applicable) should
formally accept the information system/
network into production, on the basis of
minimum acceptable test outcomes having been
achieved, the performance baselines having
been established, service readiness having been
confirmed, a service level agreement having
been negotiated and residual risks having been
assessed. The Information System Owner and/
or Information Owner (as applicable) should
withhold approval unless and until they are
satisfied that the information system/network
is capable of being operated and managed in
a suitably secure manner, consistent with the
agreed Information Security Design.
Control IS.2 Information Security Design

Dependencies IS.13 Information Systems and Network Security Testing

o 10.3.2 System acceptance

o CA-1 Security Assessment and Authorisation Policies
and Procedures
o CA-6 Security Authorization
225
OM.5 Monitoring of Information System Version 1.0
and Network Performance and Suggested P1
Usage Priority
Control The Entity shall establish procedures and tools for monitoring
Standards the performance and use of information systems and processing
facilities.
q q Corrective
OM.5.1 The Entity should ensure that information M M M
systems and networks are subject to on-going
monitoring. Monitoring attributes may include
(but not be confined to) confirming:
• Deviation from an information system
performance baseline defined within the
Information Security Design.
• Loading on the information system/network
(in the context of available capacity).
• Status of Information Security controls.
• Usage of information services by users.
• User and administrator account status (e.g.
times of access, locations of access, dormant
vs. active accounts).
• Anomalous and suspicious events (including
data access outside of the normal pattern of use).
• Potential and actual attacks.
• Potential and actual malicious code distribution.
• Presence of known vulnerabilities.
• Status of security patches within the Entity’s
infrastructure.
• Configuration deviation from agreed baselines.

OM.5.2 The Entity should ensure that its monitoring M M M
data is protected from accidental or intentional
corruption or deletion.
OM.5.3 The Entity should ensure that its monitoring M M M

data is regularly analysed by qualified personnel,
with prioritised and costed recommendations
for corrective action and improvement being
presented to the organisation’s Information
Security Governance Committee.

OM.5.4 The Entity should classify its monitoring data and M M M
provide protections appropriate to that level of
classification. Sensitive elements of monitoring
data should only be made available to those
parties with a verified and approved need for
access to it.

OM.5.5 The Entity should integrate its monitoring M M M
activities with its Information Security Incident
Management capabilities, to ensure that
appropriately and timely interventions are
made on the basis of observed deviations
from acceptable information system/network
performance and/or usage.

OM.5.6 The Entity should consider automating its S R R
monitoring activities and setting alert thresholds
for Information Security reporting.

OM.5.7 The use of monitoring data by information R M M
system, network and security administrators
should be overseen by Entity management to
ensure that abuses of access do not occur.

227
OM.5.8 Risk analysis findings should be regularly R M M
reviewed and updated, in light of actual status
confirmed via monitoring data.
OM.5.9 Where reliance is placed on monitoring data S S S

provided by third-party suppliers, the Entity
should independently verify the accuracy of the
data on a regular basis. The Entity should also
seek to satisfy itself that the data collection
method is appropriate to its requirements.

Control
Dependencies
References • NIST Special Publication 800-53 Revision 1 ‘Guide for

Applying the Risk Management Framework to Federal
Information Systems’
• NIST Special Publication 800-137 ‘Information Security
Continuous Monitoring (ISCM) for Federal Information
Systems and Organizations’
o CA-7 Continuous Monitoring

OM.6 Anti-Malware Protection Version 2.0
Suggested P1
Priority
Control The Entity shall implement protections against malicious
Standards software on its information systems and network devices.
q a Detective
q q Corrective
OM.6.1 The Entity should implement procedures and M M M
tools for real-time prevention, detection,
quarantining and removal of infection caused
by malicious software (malware) from its
information systems. (Malicious software may
include but not be limited to: viruses, spyware,
email spam, trojan horses, worms, root kits and
adware).
OM.6.2 Anti-malware protections should be deployed on M M M

devices at the boundary of the Entity’s network,
as well as on internal sensitive network segments
(e.g. Data Centre boundary) to limit the potential
for infection within the Entity’s core network.

OM.6.3 Anti-malware protections should be deployed M M M
on both servers and end-user workstations &
laptops inside the Entity’s core network.

OM.6.4 Electronic mail (email) attachments should M M M
be automatically scanned and files suspected
of malware infection should automatically be
quarantined.

OM.6.5 The Entity’s Information Security education and M M M
awareness programme should make users aware
of the dangers and attack vectors associated
with malware and the behaviours supportive of
preventing malware infection.
229
OM.6.6 The Entity’s service desk function(s) should be M M M
trained to recognise and respond to the attributes
of a potential malware infection. Priority should
be given to containing the events and avoiding
further dissemination of the malware to other
network hosts.

OM.6.7 The Entity’s boundary defences should be M M M
configured to prevent hosts on the core network
from disseminating malware to hosts outside of
the core network.

OM.6.8 Information systems should be configured to M M M
automatically poll the relevant trusted anti-virus
source for updated signature files on a frequent
basis. (The Entity may wish to provide a trusted
internal server from which signature files are
pushed to devices on the core network).

OM.6.9 The Entity should consider sourcing anti S S S
malware protection technology from multiple
vendors, to support early identification of a
malware signature that may not immediately be
known to all virus scanning software. Different
vendor offerings may be deployed on different
information system types (e.g. one product
being used for boundary devices and servers,
while an alternative is used for workstations).

OM.6.10 If removable media (e.g. DVDs, USB pen drives) R R R
is permitted to connect to Entity information
systems, the media should be scanned for
malware on each occasion that it is connected to
the information system.
OM.6.11 The Entity’s IT and security personnel should R R R

regularly review anti malware bulletins to ensure
their knowledge of actual and potential malware
infections remains current.


OM.6.12 Mobile computing devices connecting to, or R R R
transacting data with, the Entity’s core network
should have anti malware protections installed.

OM.6.13 The Entity may consider automatically isolating S S S
information systems, devices or network
segments that are known to be infected with
malware, with the view to prevent further
infection.

OM.6.14 The Entity is required to immediately notify M M M
ADSIC of any malware infection, with the aim of
aiding cross-governmental information sharing
and with the view to preventing its further
dissemination to other government Entities.

OM.6.15 The Entity’s security metrics and associated S S S
reporting should confirm relevant dimensions of
anti-malware performance, including:
• Number of malware instances detected,
quarantined and destroyed.
• The average age of anti-malware signature

files across the information systems estate.
• The number of incidents logged relating to

malware and the time taken to resolve them.
• The information systems performance impact

of any malware infection (e.g. % increase in
round trip delay).
OM.6.16 In the event of a confirmed malware infection R R R

that cannot be resolved by anti-virus software’s
eradication capabilities (e.g. rootkit detection)
the information system should be restored from
a gold master system image from the Entity’s
definitive software library.

231
OM.6.17 The Entity’s information system backup process S S S
should provide for the scanning of backup media
and the scanning of files being transferred to
the backup media, to avoid malware infections
spreading to the Entity’s backups.

OM.6.18 Application, utility and operating system R R R
software received from third-parties, whether
downloaded via public network, or received via
transferrable media (e.g. DVD, USB stick), should
be scanned by the Entity for malware. Supply
contracts for provision of software and software
maintenance (whether off-the-shelf or custom
development) should require the supplier to
warrant that the software will be malware-free
at the point of delivery.

OM.6.19 Supply contracts for the provision of hardware R R R
and hardware maintenance services should
require the supplier to warrant that the
equipment involved and any secondary storage
associated with it will be malware-free at the
point of delivery/return.
Control
Dependencies

o 10.4.1 Controls against malicious code
o SI-3 Malicious Code Protection

OM.7 Technical Vulnerability and Patch Version 1.0
Priority
Control Timely information about the technical vulnerabilities of
Standards information systems and networks shall be obtained, the
Entity’s exposure to such vulnerabilities evaluated, and
appropriate measures taken to address the associated risk.
q a Detective
q q Corrective
OM.7.1 The Entity shall maintain a current and complete M M M
inventory of assets (see AM.1 Inventory of
Information Assets and AM.6 Physical Asset
Management), as a prerequisite of technical
vulnerability management. (Specific information
needed to support vulnerability management
includes: software vendor, version numbers,
current state of deployment [e.g. what software
is installed on which information systems] and
the persons within the Entity responsible for the
software).
OM.7.2 The Entity should define the roles and M M M

responsibilities associated with technical
vulnerability management, including:
vulnerability monitoring, vulnerability risk
assessment, information system/network device
patching, asset tracking and any coordination
activities required. The Entity should ensure
that resource planning allows for vulnerability
assessment and patch management to be
prioritised.

OM.7.3 The Entity should develop and resource a M M M
plan that addresses its vulnerability and patch
management activities. The plan should ensure
that a timeline is defined for reacting to
notifications of potentially relevant technical
vulnerabilities (i.e. how soon after a vendor
release of a certain patch type will the Entity
implement it?).
233
OM.7.3 The plan should ensure that adequate budget M M M
(Cont.) and personnel are available for vulnerability
and patch management to be transacted as
a foundational capability within the Entity’s
Information Security control set.
OM.7.4 Once a potential technical vulnerability has been M M M

identified, the Entity should assess the associated
risk and the actions to be taken. Such action
could involve patching of vulnerable information
systems and/or applying other controls.

OM.7.5 If a patch is available, the risks associated with M M M
installing the patch should be assessed (the risks
posed by the vulnerability should be compared
with the risk of installing the patch).

OM.7.6 A patch should be tested and evaluated on a M M M
test information system, before it is installed on
production information systems – to ensure that it
is effective and does not result in side effects that
cannot be tolerated.
OM.7.7 If no patch is available, other controls should be M M M

considered such as:
• Turning off services or capabilities related to
the vulnerability
• Adapting or adding access controls
• Strengthening boundary defences
• Increasing monitoring to detect or prevent
actual attacks
• Raising awareness of vulnerabilities

OM.7.8 Security performance metrics and associated S S S
reporting should confirm the average delta
between when patches are released and when
they are applied.
OM.7.9 Development and test information systems M M M

should be patched, as well as production
OM.7.10 The sources of patches and service packs should M M M

be verified and should only be downloaded from
known, trusted sources.

OM.7.11 Non-critical patches should be batched and S R R
applied during scheduled maintenance windows,
to avoid ad-hoc disruption to production

OM.7.12 The Entity should consider deploying automated S S S
vulnerability scanning software relevant to its
supported information systems.

Control AM.1 Inventory of Information Assets

Dependencies AM.6 Physical Asset Management

o 12.6.1 Control of technical vulnerabilities
235
OM.8 Information Backup and Version 2.0
Restoration Suggested P1
Priority
Control The Entity shall back up information system data and shall have
Standards the capabilities necessary for its recovery.
OM.8.1 The Information Owner should define their M M M
information backup and restoration requirements
prior to the design and implementation of an
information system. The agreed attributes for
backup and restoration capabilities should be
confirmed within the service level agreement
applicable to the information system.
OM.8.2 The Entity should conduct backups of user data R R R

and information system-level information (e.g.
information system configuration files, software
images, software licenses, system configuration
graphics) in a manner consistent with the
Information Security Design.

OM.8.3 Backup media should only be sourced from R R R
known, trusted sources and should be confirmed
as being free of deficiencies and malware prior to
being added to the backup cycle.

OM.8.4 The Entity should consider a 3-2-1 approach to S S R
design its backup regime:
• x3 copies of data (1 primary and 2 backups)
• Files should held on at least x2 different types

of media (e.g. hard disk and optical drive)
• At least x1 copy of the data should be held

off-site

OM.8.5 Backup media should be uniquely identified R R R
with indelible physical marking to aid effective
management of the backup and restoration
process.
OM.8.6 The Entity should develop an information M M M

systems backup plan confirming:
• When information systems will be backed up
• What data items will be included and excluded

within the backup
• What backup type will be used (e.g. full,

incremental, differential) on the data
concerned
• The anticipated time the backup will take to

complete
• What specific, uniquely identified media will

be used to complete the backup
• When the media will be taken off-site
• How long the back-up will remain available

and when the backup will be destroyed
OM.8.7 The Entity should maintain a backup log M M M

confirming the degree to which its backup
plan has been met. Where there have been any
deviations from the plan (e.g. the backup failed
to complete on a given night) the log should
confirm the reason for the deviation and the
corrective action that will be applied to avoid
such a deviation occurring again in future.

237
OM.8.8 The Entity should identify an alternative storage R R M
site for the storage of backup media. The storage
site should be geographically separated from
the primary storage facility, so as to not be
susceptible to the physical and environmental
same hazards.
OM.8.9 Whether at the primary data processing facility or M M M

the alternate storage site, physical security and
environmental controls should be in place which
allow for the backup media’s confidentiality,
integrity and availability to be maintained (e.g.
fire-resistant safes, physical access control).
OM.8.10 The Entity should regularly test its backups to R M M

verify media reliability, confirm information
integrity and to quantify the likely restoration
time required.

OM.8.11 Restoration of data should be coordinated with R R R
the Entity Information Systems Continuity
Management provisions (see IC.1 Information
Systems Continuity Planning Framework).

OM.8.12 The Entity should apply cryptographic mechanisms S R M
to protect the confidentiality of backup media.

OM.8.13 The Entity should make use of mechanisms such R R M
cryptographic hashes or digital signatures to
protect the integrity of backup data.

OM.8.14 Where data is only available in hard/paper copy R R R
and not electronically, the Entity should ensure
that suitable copies are made and retained in
that format.

OM.8.15 Whenever possible, information system backup S S S
cycles should be run outside of core hours, to limit
impact upon the performance of the information
system.
Control
Dependencies

o 10.5.1 Information back-up
• NIST Special Publication 800-34 Revision 1 ‘Contingency
Planning Guide for Federal Information Systems,
o CP-9 Information System Backup
o CP-10 Information System Recovery and Reconstitution
239
OM.9 Network Boundary Defence Version 1.0
Suggested P1
Priority
Control The Entity shall define and defend the perimeter(s) of
Standards its information networks, with the view to preventing
unauthorised acc ess.
OM.9.1 The Entity should define a network architecture M M M
that clearly separates internal systems on its core
network from Demilitarized Zone (DMZ) and
extranet systems.
[DMZ Systems need to communicate with both

the core network and public networks. Extranet
Systems are those primarily in communication
with other information systems at a business
partner’s facility].
OM.9.2 Firewalls should be deployed to control the flow M M M

of network traffic between the perimeter of the
Entity’s core network and any external networks
that it connects to.

OM.9.3 Firewalls and/or router Access Control Lists (ACLs) M M M
should be deployed to control the flow of network
traffic internally within the Entity’s core network,
to distinguish between network segments
and information systems of different security
postures.

OM.9.4 When designing its network architecture, the M M M
Entity should consider the type of firewalls (e.g.
stateful, application, proxy) necessary for the
specific network location, the network traffic type
being transmitted and the security requirements
of the Information Owner.


OM.9.5 The Entity should deploy ingress and egress M M M
filtering and Unicast Reverse Path Forwarding on
its boundary routers to limit the potential for IP
address spoofing.
OM.9.6 The Entity should consider the deployment of S S S

anomaly detection and multiverification process
(MVP) technologies to detect and limit the impact
of Distributed Denial of Service (DDoS) attacks.
OM.9.7 Firewall rule sets should be defaulted to M M M

disallowing all access unless and until
specifically authorised by the Entity’s Chief
Information Security Officer (CISO) on the basis
of documented business justification. Services
and ports not used by the Entity should not be
enabled on the firewall. All changes to firewall
configurations, placement and rule sets must be
approved via the Entity’s Change Management
process.
OM.9.8 All outbound connections to public networks M M M

should be via proxy firewalls, with session activity
logged and analysed for potential Information
Security breaches.
OM.9.9 All inbound connections initiated from public M M M

networks, wireless hotspots and mobile devices
should arrive to the core network via a firewall.
OM.9.10 Firewalls should be monitored by the Entity’s R R R

Intrusion Detection and Prevention Services
(IDPS), with the view to identifying if/when a
firewall has been compromised.
OM.9.11 The Entity should consider the deployment of R R R

multiple firewalls and boundary routers to provide
defence-in-depth for the connection between its
core network and public networks.
241
OM.9.12 Where software-based firewalls are used for R R R
boundary protection, the computing devices’
operating system should be hardened and the
firewall should be the only application permitted
to run on the computing device.
OM.9.13 The Entity should consider blocking all encrypted S S S

traffic at the firewall unless the source and
destination have been approved for secure
communication. The Entity may consider an
approach where data is de-encrypted at the
firewall and then re-encrypted for onward
transmission to the destination.
OM.9.14 The Entity should periodically scan for back R R R

channel connections to public networks that
seek to bypass boundary defences, including
unauthorised VPN connections and dual-homed
hosts (connected to both the Entity’s core
network and other networks).
OM.9.15 Firewalls, routers and other boundary devices R R R

should be prioritised for the application of
patches and other vendor software updates, due
to their exposure to public networks.
Control
Dependencies
References • SANS
o Critical Control 5: Boundary Defence
o ES-1 Executive Summary

OM.10 Intrusion Detection and Prevention Version 1.0
Suggested P1
Priority
Control The Entity shall monitor information systems and networks,
Standards analysing them for signs of possible violation of computer
security policies, acceptable use policies, or standard security
practices.
q a Detective
q q Corrective
OM.10.1 The Entity should deploy an Intrusion Detection R R M
and Prevention System (IDPS) to identify
possible security incidents, log information about
them, attempt to stop them, and report them to
security administrators.
OM.10.2 When designing its security architecture, the S R R

Entity should select one or more IDPS solutions
that meet the specific needs of its environment
and which are relevant to its information asset
base and its risk profile.
Main IDPS types include:

Network-Based - monitor network traffic of
particular segments or devices and analyse the
network and application protocol activity to
identify suspicious activity.
Wireless - monitor wireless network traffic and

analyse it to identify suspicious activity.
Network Behaviour Analysis (NBA) - examine

network traffic to identify threats that generate
unusual traffic flows, such as distributed denial of
service (DDoS) attacks, certain forms of malware,
and policy violations (e.g. a client system
providing network services to other systems).
243
OM.10.2 Host-Based - monitor the characteristics of a S R R
(Cont.) single host and the events occurring within that
host for suspicious activity.
Application-Based - monitor the characteristics

of specific applications (e.g. Oracle, SQL, MS
Exchange).
The Entity should consider the fundamentally

different information gathering, logging,
detection, and prevention capabilities of each
IDPS type and the benefits they offer.
OM.10.3 The components of the IDPS (e.g. sensors/agents, R R M

management servers, database servers, user
and administrator consoles, and management
networks) should have their operating systems
and applications kept fully up-to-date, and all
software-based IDPS components should be
hardened against threats.
OM.10.4 The security of IDPS components should be R R M

reviewed on an on-going basis, including
verifying that the components are functioning
as desired, monitoring the components for
security issues, performing regular vulnerability
assessments, responding appropriately to
vulnerabilities in the IDPS components, and
testing and deploying IDPS software updates.
OM.10.5 The response techniques of IDPS technologies R R M

(e.g. stopping the attack itself, changing
the security environment, changing the
attack’s content) should be tested, to ensure
that responses do not generate negative or
unanticipated consequences.

OM.10.6 Where the Entity plans to use multiple types S S S
of IDPS technology, or multiple products of
the same IDPS technology type, consideration
should be given as to whether or not the IDPS
instances should be integrated.
Integration may possibly be achieved through

the deployment of a Security Information and
Event Management (SIEM) solution.
Control
Dependencies
References • NIST Special Publication 800-94: Guide to Intrusion

Detection and Prevention Systems (IDPS)
o ES-1 Executive Summary
245
OM.11 Information Extrusion Detection Version 1.0
and Prevention Suggested P3
Priority
Control The entity shall protect its information assets from leaving
Standards its information networks and information systems without
approval.
q a Detective
q q Corrective
OM.11.1 The entity should monitor all outbound network S R R
traffic at egress points (e.g. Internet proxies,
email gateways) to:
• Detect anomalies (e.g. large file transfers,
long/persistent connections, unusual protocols
and ports).
• Identify if information of classification

of ‘Confidential’ or above is leaving the
organisation without permission.
OM.11.2 The entity should consider deploying an S S S

automated tool on its network boundary (i.e. a
network-based Data Loss Prevention solution)
and on its workstations (i.e. a host-based Data
Loss Prevention solution) that monitors for
information types defined by the entity e.g.:
• personally identifiable information
• keywords
• other document characteristics
to discover unauthorised attempts to exfiltrate

data across network boundaries and block such
transfers, while alerting Information Security
personnel.

OM.11.3 The entity should consider blocking data of S S S
classification ‘Confidential’ or above from leaving
the organisation (via the use of data extrusion
prevention technology), unless its transmission
has been overtly approved.
OM.11.4 The entity should conduct periodic scans of S S R

its servers to determine whether data types
of specific interest to the entity (e.g. personal
identity, health, credit card, and classified
information) are present on the information
systems in clear text. (Tools which search for
patterns that indicate the presence of such
information can help identify if a business or
technical process is leaving behind or otherwise
leaking such information).
OM.11.5 The entity should identify and isolate any network S S S

traffic that has been subjected to cryptographic
processing without authorisation.
Control • IS.6 Information Leakage Prevention

Dependencies • OM.9 Network Boundary Defence
• IS.10 Network Segregation
• OM.16 Control of Removable Digital Media
References • SANS
o Critical Control 15: Data Loss Prevention
o SC-7 Boundary Protection
o AC-4 Information Flow Enforcement
247
OM.12 Network Port, Protocol and Service Version 2.0
Protection Suggested P2
Priority
Control The Entity shall control access to network ports, protocols and
Standards services.
q a Detective
q q Corrective
OM.12.1 The Entity should limit network devices to M M M
activating only those ports, protocols and
services required to support agreed information
services. Unnecessary capabilities of the network
device should not be enabled.
OM.12.2 Any changes that enable or disable ports, M M M

protocols or services on network devices should
be managed under the direction of the Entity’s
OM.12.3 Automated scans of network ports should be M M M

conducted by the Entity’s Information Security
personnel or approved third party and compared
to a known, agreed configuration baseline.
If a new port is found open an alert should be
generated and reviewed.
OM.12.4 Network services should be reviewed (at least R R R

every six months) via the Entity’s Change
Management process, to ensure they continue
to have business justification. Where network
services are enabled for short-term needs (e.g.
to support project work) they should be disabled
when no longer required.

OM.12.5 All in-band (i.e. over the network) or out-of-band R R R
(direct) connections to network device diagnostic
ports should be logged and the Entity’s Information
Security personnel should review the audit logs for
anomalies and/or suspicious activity.
Control
Dependencies

Requirements:
o 11.4.4 Remote Diagnostic and Configuration Port
Protection
o AC-6 Least Privilege
o AC-17 Remote Access
o AC-18 Wireless Access
o MA-3 Maintenance Tools
o MA-4 Non-Local Maintenance
249
OM.13 Secure Software Management Version 1.0
Suggested P3
Priority
Control The Entity shall manage its software assets in a manner
Standards supportive of effective security.
q a Detective
q q Corrective
OM.13.1 The Entity should develop and maintain a R R R
catalogue of approved and supported software
(with the catalogue potentially being in the form
of a database). It should also maintain details of
previously approved software that is now retired.
The catalogue should confirm:
• The name of the software
• Its business purpose
• Its version
• The unique identifier applied to the software
version
• The software’s system requirements
• Its licensing terms
• Date of security testing
• Approver of security testing
• The status of the software version(s) within
the Entity e.g.
- Under development
- Under testing
- In production
- Retired or Replaced

OM.13.1 • The date that the software version(s) achieved R R R
(Cont.) the given status
• The departments or user communities
authorised to use the software
• The device type the software relates to
• The parties responsible for providing first,
second and third-level support of the software
• The unique identifiers of previous, related
versions of the software
The software types recorded in the catalogue

should include:
• Operating Systems
• Middleware
• Applications
• Utilities
The software types may have potential

applicability to a variety devices including:
• Mobile devices
• Workstations and laptops
• Servers
• Peripherals (e.g. printers, scanners)
• Network attached storage
• Network devices (e.g. switches, routers,
wireless access points)
OM.13.2 The Entity should maintain a Definitive Software R R R

Library (DSL) for all entries within its software
catalogue. A direct one-to-one correlation should
be maintained at all times between the entries in
the software catalogue and the entries in the DSL.
251
OM.13.3 The DSL should contain security-tested master R R R
images of current and previously approved
versions of the software, which may serve as
a definitive reference of known and trusted
software assets.
OM.13.4 Software images in the DSL should only come R R R

from known, trusted sources – either internally
developed software that has been subject to
security testing, or from verified third-party
software developers.
OM.13.5 Software images within the DSL should be write- R R R

protected and have their integrity protected
via digital signature or cryptographic hashing
algorithm.
OM.13.6 Access to the DSL should be logged and the logs R R R

analysed by the Entity’s Information Security
function.
OM.13.7 Any changes to the software catalogue and the R R R

DSL should be approved via the Entities Change
Management process. As a minimum, the
approver group for such changes should include
Committee and/or the Entity’s Chief Information
Security Officer (CISO).
OM.13.8 Access to the DSL should be subject to access R R R

control, with only approved network and
system administrators having access to add/
delete content or to download image copies for
installation on information systems and network
devices.

OM.13.9 The Entity should regularly scan (at least R R R
quarterly) its production information systems
estate to identify any software that is not shown
as having ‘production’ status within its software
catalogue. Where deviations are identified, the
Entity should investigate the cause with the
view to the software being removed or records
corrected.
OM.13.10 Where a workstation or Entity-managed mobile R R R

device deviates from its agreed software image,
the Entity should consider deploying tooling
that automatically restores the device to its
approved software image when the information
system/device initiates a connection to the
Entity network.
OM.13.11 The use of software that has the capability of R R R

overriding information system and application
controls, or bypassing other Information
Security controls, shall be restricted and tightly
controlled. The use of such software must be
approved by the Entity’s Information Security
Governance Committee and/or CISO.
OM.13.12 All third-party software should be subject to R R R

security testing. The Entity should pay particular
attention to the security of open source, freeware
and shareware software offerings.
OM.13.13 The Entity should consider restricting work- S S S

stations and mobile devices to running without
administrative privileges and preventing the
downloading/installing of software executables
by end users.
253
OM.13.14 A back-up of the DSL should be available at the S S S
Entity’s recovery site, to allow for the secure
reinstallation of software in the event of a major
incident.
OM.13.15 The contents of the DSL should be effectively S S S

structured and segregated to avoid potential
confusion as regards the target software being
accessed and to avoid software images of
different types being collocated (i.e. utilities
not being stored alongside applications in the
storage hierarchy).
OM.13.16 Retired software versions should only be S S S

removed from the software catalogue, and
correspondingly the DSL, once it has been fully
verified that there is no likely further need for
access to the software. The Entity should be
mindful of its data retention obligations and the
potential need to access archived data via legacy
software.
Control • SG.5 Legal and Regulatory Requirements

Dependencies

o 12.5.3 Restrictions on changes to software packages
o SA-6 Software Usage Restrictions
o SA-7 User-Installed Software

OM.14 Electronic Mail Security Version 1.0
Suggested P2
Priority
Control The Entity shall ensure that electronic mail systems and
Standards associated messages are protected in a manner appropriate to
the information being stored and transmitted.
q a Detective
q q Corrective
OM.14.1 The Entity should size its electronic mail systems M M M
to provide adequate processing and storage
capacity to address current and anticipated
future demand.
OM.14.2 The Entity should prohibit the use of electronic M M M

mail for the transfer of information of
classification ‘Confidential’ or above, unless
secure email controls have been implemented
(e.g. S/MIME, PGP or AES encryption through
tools such as WinZip). Where email encryption is
proposed for secure communication, the Entity
should ensure that the receiving party has the
capability to participate in the secure transaction.
OM.14.3 The Entity should scan inbound and outbound R R R

email traffic for:
• Viruses
• Malware
• Spam
• Inappropriate content (as determined by the
Entity’s Acceptable Usage provisions)
• Executable code
• Potential data extrusion
The Entity should consider blocking the above

traffic types when identified.
255
OM.14.4 All email messages sent by the Entity to outside R R R
parties should contain a footer that confirms the
terms under which the message is sent.
OM.14.5 The Entity’s email systems should be backed up M M M

and the associated data archived in a manner
consistent with:
a) The Service Level Agreement defined for the
electronic mail service.
b) The Entity’s data retention obligations.
OM.14.6 Generic email addresses should only be created R R R

if a legitimate business need for such has been
demonstrated. Generic addresses should be
retired once the need is no longer applicable (e.g.
the related project or campaign has finished).
Mail sent to generic email addresses should
always route to one or more accounts that
directly correspond to a named user. The use of
generic email accounts should be prohibited.
OM.14.7 Users of electronic mail should be educated as M M M

to the secure use of such information systems,
including:
• Appropriate and inappropriate usage of
electronic mail.
• The dangers of mobile code, attached

executable files and compressed file
attachments.
• The legal consequences of statements made

via electronic mail.

OM.14.7 • The avoidance of using accounts other than M M M
(Cont.) those specifically assigned to the named user.
• The use of secure email provisions (where
available) e.g. how to apply encryption to
messages.
• The avoidance of forwarding chain messages.
• The avoidance of spam messages.
OM.14.8 The Entity should consider the enhancing of S S S

email client software security by disabling:
• Automatic message preview
• Automatic opening of messages
• Automatic loading of pictures in messages
• Downloading and processing of active content
OM.14.9 Email accounts and associated data should not R R R

be retained after the named user has left the
Entity (other than in the form of a backup of the
account and its data being captured). If there is
an anticipated need for future access to the data,
it should be migrated to an active data source
(e.g. forwarded to a current email user, saved as
text files etc.)
OM.14.10 Plug-ins intended to augment the functionality R R R

of email client software should only be installed
by authorised system administrators and should
only be sourced from known, trusted sources.
OM.14.11 Web-based access to Entity-provided email M M M

services should be only via SSL/TLS encrypted
sessions, with a minimum key length of 256 bits.
257
Control • OM.7-Technical Vulnerability and Patch Management

Dependencies • IS 3-System and Network Device Hardening
• OM.5 Monitoring of System and Network Performance and
Usage
• TA.1-Security Induction
• TA.4-Security Training Development and Delivery

o 10.8.4 Electronic messaging
• NIST Special Publication 800-45: Guidelines On Electronic

Mail Security

OM.15 Detection of Authorised and Version 2.0
Unauthorised Equipment Suggested P2
Priority
Control The Entity shall restrict access to its core network to only those
Standards devices approved for connection.
q a Detective
q q Corrective
OM.15.1 The Entity should maintain an inventory of M M M
devices and equipment types authorised for
connection to its core network.
OM.15.2 The Entity should confirm to information system M M M

users which types of equipment are acceptable
for connection to its core network and confirm
the sanctions that will apply for unauthorised
connection.
OM.15.3 Access to network services (e.g. printers, file M M M

servers) should only be granted to devices after
the user and/or information system has been
authenticated.
OM.15.4 The Entity should apply physical address R R R

(MAC) filtering on network switches to prevent
unauthorised devices from establishing a
connection to its core network. Where such a
preventive control is not in place, the Entity
should consider isolating unauthorised devices
from the rest of the network, once discovered.
259
OM.15.5 The Entity should monitor connections to its R R R
core network. Attempts by unauthorised devices
to establish a connection should be identified
and investigated. The Entity should consider the
deployment of an automated asset inventory
discovery tool to confirm the presence of
authorised and unauthorised devices.
OM.15.6 Parties wishing to connect currently non- R R R

approved devices to the core network should first
seek permission of the Entity’s Chief Information
Security Officer.
OM.15.7 The Entity should undertake a regular (at least R R R

annual) physical audit of its IT equipment, to
identify any unauthorised devices.
Control
Dependencies

o 11.4.1 Policy on use of network services

OM.16 Management of Removable Version 2.0
Digital Media Suggested P1
Priority
Control The Entity shall manage and control the use of removable
Standards media.
OM.16.1 The Entity should have in place procedures that M M M
address the handling of information systems
digital removable media. (Digital removable
media includes disks, tapes, removable hard
drives, USB/flash drives, compact disks and
digital video).
Physical and technical security measures

for the protection of digital media should
be commensurate with the classification or
sensitivity of the information residing on the
media.
OM.16.2 The Entity should undertake risk assessment to R R R

determine the appropriate selection of media
for the information type to be contained on
that media. The Entity should document and
communicate what media and information
types require restricted access (e.g. information
of a certain classification cannot be stored/
distributed on a given media type).
OM.16.3 The Entity should consider restricting the S R R

ability of information systems to write data to
removable digital media, where the information
type is of classification ‘Confidential’ or above.
OM.16.4 The Entity should consider the use of S R R

cryptographic mechanisms to protect and
restrict access to information on removable
digital media.
261
OM.16.5 The Entity should consider the physical marking S R M
of media (both digital and paper-based) to
indicate the information classification of the
contents and the restrictions that apply to its
usage and its distribution.
OM.16.6 The Entity should control physical access to S R M

information systems media to ensure that it can
only be accessed by authorised personnel.
OM.16.7 The Entity should ensure that removable media S R M

is protected during its transportation. This
protection seeking to prevent:
• The media itself from being stolen
• The information held on the media from being

accessed/copied/stolen
• The integrity of the data being compromised
OM.16.8 The Entity should maintain a log of removable S R M

media which is of specific interest to the Entity
(e.g. media used for systems backup) to confirm:
• Its purpose
• The classification of information held on the

media
• The media custodian (i.e. the person/team

with primary responsibility for its safe keeping)
• Its location
• Its unique identifier (to help distinguish this

media from others of the same type)

OM.16.9 The Entity should sanitise digital media prior S M M
to disposal, release out of organisational
control, or release for reuse. The sanitisation
mechanisms should be of a strength and
integrity commensurate with the classification
or sensitivity of the information.
The Entity should document and verify media

sanitisation actions, and periodically test
sanitisation equipment/procedures to ensure
correct performance. Sanitisation should include:
• Removing all labels, markings, and activity
logs
• Degaussing and overwriting memory locations
Control
Dependencies

o 11.4.1 Policy on use of network services
o MP-2 Media Access
o MP-5 Media Transport
o MP-6 Media Sanitization
o PE-16 Delivery and Removal
• NIST Special Publication 800-88: Guidelines For Media
Sanitization
263
OM.17 Management of Paper Media Version 2.0
Suggested P1
Priority
Control The Entity shall manage and control the use of paper media and
Standards the method of its disposal.
q a Detective
q q Corrective
OM.17.1 The Entity should have in place procedures that M M M
address the handling of paper media applicable
to the Entity’s information assets. (Paper media
encompasses hand-written information, as well
as output from information systems, such as
contracts, memos, financial data, reports etc.)
Physical and technical security measures

for the protection of paper media should
be commensurate with the classification or
sensitivity of the information recorded on the
paper.
OM.17.2 The Entity should undertake risk assessment R R R

to determine the information types that may
be recorded on paper media. The Entity should
document and communicate what information
types can/cannot be recorded on paper and what
restrictions should apply to their access and
distribution.
OM.17.3 All paper outputs from the Entity’s information R R R

systems should carry an information classification
label within the document header or footer. The
classification should correspond to one of those
shown in AM.3 Information Classification.
Where a paper output is missing its information

classification label, management and Information
Security personnel should assess the content and
mark it with what is deemed to be the appropriate
classification label.

OM.17.3 If they are unable to identify the content then R R R
(Cont.) they should regard its classification as being
‘Confidential’ unless and until the Information
Owner applies an updated classification label.
OM.17.4 Paper materials of classification ‘Confidential’ M M M

or above should be disposed of securely. Secure
disposal should be achieved via ‘cross-cut’
or ‘crypto-cut’ shredding, with a maximum
paper strip width of 2mm (DIN3) or less. [See
References].
OM.17.5 Where the Entity has a high volume of paper S S S

waste of classification ‘Confidential’ or above, it
should consider engaging a specialist third-party
provider to remove and shred these materials.
To aid compliance with any secure disposal of
provisions, the Entity should consider deploying
demarcated waste bins for the disposal of such
materials.
Control AM.3 Information Classification

Dependencies
References • DIN 32757-1 Standard

o MP-2 Media Access
o MP-6 Media Sanitization
• Abu Dhabi Government Service Security Categorisation
265
OM.18 Technical Configuration Definition Version 1.0
Enforcement Suggested P3
Priority
Control The Entity shall define configuration parameters for its
Standards information systems and networks and ensure compliance to
them.
q a Detective
q q Corrective
OM.18.1 The Entity should define technical policies that M M M
information systems and network devices must
adhere to in order to support a requisite level of
performance and security.
OM.18.2 The Entity should deploy a Network Access R R R

Protection (NAP)/Network Admission Control
(NAC) capability to detect any deviations from
approved information system configurations
and to apply automatic remediation.
Control
Dependencies
References

OM.19 Physical Media in Transit and Version 2.0
Off-Site Storage Suggested P2
Priority
Control The Entity shall protect physical media in transit and in off-site
Standards storage against unauthorised access, misuse, or corruption
when the media is beyond the Entity’s physical boundaries.
q a Detective
q q Corrective
OM.19.1 The Entity should control information system M M M
media (paper and digital) and restrict the pickup,
receipt, transfer, and delivery of such media to
only authorised personnel.
OM.19.2 For information of classification ‘Confidential’ or S R M

above that is in transit, the Entity should consider
deploying cryptographic mechanisms to protect
the information’s confidentiality and integrity.
Where cryptographic controls cannot be
deployed in support of media this classification,
compensating controls should be deployed to
protect the media in transit e.g.
• Entity staff or trusted couriers should be
engaged for the purpose of transporting
media.
• Locked containers and tamper-proof seals

should limit the potential for access to media
and aid detection of unauthorised access.
• Delivery to the recipient should be confirmed

within an acceptable time frame from the date
and time of dispatch.
OM.19.3 Access to physical media at off-site storage M M M

facilities should be restricted to authorised
personnel. An inventory of media held at the
facility should be kept and a log recording which
media was accessed, when, by whom and for
what purpose should be maintained.
267
OM.19.4 Environmental controls at off-store facilities S R M
should ensure the continued integrity and
availability of physical media. Operating
temperatures should be within a range supportive
of the media’s preservation in an accessible form.
OM.19.5 On a regular basis (at least annually) the S R R

Information Owner should determine if
physical media held at off-site storage facilities
is still required. The review should take into
consideration the Entity’s business needs and its
data retention obligations.
Control
Dependencies

Requirements:
o 9.2.5 Security of Equipment Off-Premises
o 10.8.3 Physical Media in Transit
o PE-17 Alternate Work Site

OM.20 Information System and Network Version 2.0
Log Management and Analysis Suggested P1
Priority
Control The Entity shall capture log data relating to its information
Standards systems. The data shall be analysed for security-related trends
and anomalies.
q q Corrective
OM.20.1 The Information Security Design for the M M M
information system or network device should
confirm:
• What attributes of information system activity
and access will be logged e.g.:
- User activity (actual and attempted)
- Administrator/super user activity
(actual and attempted)
- System utilisation
- System performance
- System error states
• How frequently logs will be updated
• How long log data will be retained for
• Where log data will be stored
• The anticipated storage needed for log data
throughout the information system’s lifecycle
OM.20.2 The Entity should consider the potential benefit R R R

of a given level of system logging and balance
this against the potential impact upon system
performance. The Entity may consider applying
summarised logging for day-to-day operational
purposes but have the ability to move to verbose
logging when required to support incident
investigations.
269
OM.20.2 The log should capture sufficient information to, R R R
(Cont.) as a minimum, confirm:
• Date and time of the event
• The component of the information system to
which the event relates
• The type of the event (e.g. access request,
error etc.)
• The identity of the subject involved (e.g. the
user requesting access)
• The identity of the object involved (e.g. the
file to which they are requesting access)
• The before and after value of modified data
OM.20.3 The retention period defined for information S R M

system logs should be influenced by the Entity’s
broader data retention obligations and the
possible need to conduct investigations of
potential information system attacks and access
violations. As a minimum, log data should be
retained for at least one month on the live
information system, after the date and time of
the given system event. It should be available
for at least another five months within the log
management archive, for potential retrieval.
OM.20.4 Information system logs should be protected S R R

from accidental or intentional modification. The
Entity should consider writing log data to WORM
(Write Once, Read Many) media and/or using
cryptographic hashes or digital signatures to
provide assurance of log integrity.

OM.20.5 The confidentiality of information system S R R
logs should be protected via access control
mechanisms. Only authorised IT and Information
Security personnel should have access to system
logs. The access given to such personnel should
be ‘read only’. (Information systems alone
should be able to create and purge log records).
OM.20.6 The Entity should consider centralising the S R R

storage of logs, to aid their protection and
analysis.
OM.20.7 The Entity should consider retaining a back-up S S S

of system log data at an off-site location, with
consideration to the potential for the primary
logs to be erased or compromised intentionally
or unintentionally.
OM.20.8 On a regular basis (at least annually) the accuracy S S R

of log data should be verified by comparison of
known, timed events with their corresponding
log entries.
OM.20.9 The Entity should ensure that the internal clocks M M M

of information systems are synchronised with
a common, independent time source to ensure
that chronological information within log data
can be relied upon.
271
OM.20.10 The Entity should regard its information system R R M
log data as a primary source for determining
activities relevant to its security posture. Log
data should be analysed regularly (at least
monthly) to identify:
• System utilisation and performance trends
• Policy and procedure violations
• Access control anomalies
• Signs of potential attack on information
systems (whether internally or externally
initiated)
OM.20.11 The Entity should consider the deployment of S R R

log analysis tooling, to automate the process
of reviewing system logs and filtering data of
specific relevance and interest.
OM.20.12 The Entity should consider the deployment a S S R

Security Information and Event Management
(SIEM) tool to provide an aggregated
perspective on the security profile of its
information systems. The SIEM should be
configured to receive information system log
data as a primary input and report on attributes
of most interest and relevance to the Entity’s
Information Security programme.
OM.20.13 On an on-going basis, the Entity should monitor S R R

the storage available for information system log
data. This should be evaluated against a capacity
threshold defined within the information
system’s Information Security Design.

OM.20.13 In the event of the log storage capacity being S R R
(Cont.) reached, the information system should alert the
appropriate Entity officials (e.g. IT department and
CISO) and relevant action should be taken e.g.
- Increasing storage capacity
- Over-writing older log entries
- Temporarily suspending logging
When considering such steps, the Entity should

consider the risks associated with deviating from
its standard log management approach for the
system concerned. The suspension of logging
should not be undertaken lightly.
OM.20.14 The Entity should integrate its information S S R

system monitoring and logging activities with its
Incident Management process. The Entity should
define, in advance, what activities and thresholds
will trigger an alert, to whom and when.
At the start of a major incident’s management

lifecycle, the Entity should consider if:
• Adequate monitoring data is available to
manage the incident. (If not, it should consider
whether additional short-term measures can
be taken to improve visibility of the incident).
• The level of information system logging is

currently sufficient to support the analysis and
management of the incident. (If not, the level
of verbosity in the log data should be increased
for the duration of the incident management
lifecycle).
273
OM.20.14 • If logs have been afforded a sufficient level of S S R
(Cont.) protection from modification and/or deletion.
This being particularly important where an
attack is suspected as the potential root cause
of the incident. (If logs have not previously
been protected, steps should be taken to make
write-once copies, while the incident is being
contained).
Control
Dependencies
References • ISO 27001 A.10.10.1
• NIST SP 800-53
o AU-1 Audit and Accountability Policy and
o Procedures
o AU-2 Auditable Events
o AU-3 Content of Audit Records
o AU-4 Audit Storage Capacity
o AU-5 Response to Audit Processing Failures
o AU-8 Time Stamps
o AU-11 Audit Record Retention
o AU-12 Audit Generation
• NIST SP 800-92 ‘Guide to Computer Security Log

Management’
• NIST SP 800-137 ‘Information Security Continuous

Monitoring For Federal Systems’

OM.21 Secure Information Systems Version 1.0
Maintenance Suggested P2
Priority
Control Information systems shall be correctly maintained to ensure
Standards their continued security.
OM.21.1 The Entity should schedule, perform, document, M M M
and review records of maintenance and repairs
on information system components, conducted
in accordance with manufacturer or vendor
specifications and/or organisational requirements.
OM.21.2 Maintenance activities should only occur under M M M

the direction and approval of the Entity’s Change
Management process.
OM.21.3 The Entity should retain control and oversight of M M M

all maintenance activities, whether performed
on site or remotely and whether the equipment is
serviced on site or removed to another location.
OM.21.4 Removal of an information system or system R M M

components from Entity facilities for off-site
maintenance or repairs should be explicitly
approved by a designated Entity official.
OM.21.5 The Entity should ensure that equipment is S M M

sanitised to securely remove all information from
associated media, prior to removal from Entity
facilities for off-site maintenance or repairs.
275
OM.21.6 The Entity should check all potentially impacted R R M
security controls to verify that the controls are
still functioning properly following maintenance
or repair actions.
OM.21.7 The Information Security obligations applicable M M M

to third-party maintenance providers should be
defined in the Entity’s contract with the supplier
and should be monitored for compliance.
OM.21.8 The Entity should establish a process for R M M

maintenance personnel authorisation and should
manage a current list of authorised maintenance
organisations and personnel.
OM.21.9 The Entity should ensure that personnel R M M

performing maintenance on the information
system have required access authorisations to
access its facilities and equipment. Alternatively,
it may choose to designate organisational
personnel with required authorisations and
technical competence to supervise information
system maintenance when maintenance
personnel do not possess the required access
authorisations.
OM.21.10 The Entity should retain the maintenance S R R

coverage and/or spare parts necessary for the
defined level of information system availability
to be maintained, as defined within the relevant
Service Level Agreement.

OM.21.11 The Entity should develop and maintain a S S S
plan for undertaking proactive and preventive
maintenance, with the view to enhancing
information system availability and lessening
the need for reactive maintenance.
Control • OM.16- Control of Removable Media

Dependencies

Requirements:
o 9.2.4
o MA-1 System Maintenance Policy and Procedures
o MA-5 Media Transport
• NIST Special Publication 800-88 ‘Guidelines For Media
Sanitization’
277
OM.22 Secure Disposal and Re-use Version 2.0
of Equipment Suggested P2
Priority
Control The Entity shall ensure that the disposal or re-use of equipment
Standards is handled in a secure manner.
a a Detective
q q Corrective
OM.22.1 Equipment shall have all Entity information M M M
cleared/purged from its storage, prior to the
equipment’s disposal or re-use. (Equipment
requiring such action may not be confined to
information systems but may also encompass
items such as peripherals).
Re-use may encompass both re-deployment

within the Entity as well as its sale or donation to
an external party.
Data may be cleared by:

• Overwriting the storage space with data
of classification ‘Public’. (This may include
overwriting not only the logical storage
location of the files(s) but may include all
addressable locations).
• For ATA disk drives, the overwriting may

be achieved via the firmware ‘Secure Erase’
command.
• Degaussing (i.e. exposing the magnetic media

to a strong magnetic field in order to disrupt
the recorded magnetic domains. A degausser
is a device that generates a magnetic field
used to sanitise magnetic media).
OM.21.2 The effectiveness of information clearance/ S R R

purging activities should be verified to confirm
that Entity data does not remain in an accessible
form on the equipment.

OM.22.3 For information systems hosting information S S M
of classification ‘Confidential’ or above, the
Entity may additionally consider subjecting its
storage media to secure destruction as part of
the information system disposal process. Secure
destruction methods include:
• Disintegration
• Incineration
• Pulverization
• Melting
These sanitisation methods are designed to

completely destroy the media. They are typically
carried out at an outsourced metal destruction or
incineration facility with the specific capabilities
to perform these activities effectively, securely,
and safely.
OM.22.4 Prior to its disposal, any asset tags or other visual M M M

references that would allow the equipment to be
associated with the Entity should be removed.
OM.22.5 The Entity’s asset records should be updated to M M M

confirm:
• The date of the equipment’s disposal or
re-allocation.
• Who approved the disposal or re-allocation.
• How it was prepared for reallocation or
disposal.
• Where it was disposed of or re-allocated to.
Control
Dependencies
References • NIST Special Publication 800-88 ‘Guidelines For Media

Sanitization’
279
12.11 Information Security Incident Management
IM.1 Information Security Incident Version 1.0
Modelling Suggested P2
Priority
Control The Entity shall evaluate the potential types of Information
Standards Security incidents that may arise in relation to its information
assets.
IM.1.1 Prior to the introduction of information assets M M M
and the commissioning of associated information
systems, the Entity should seek to model the
potential Information Security incidents that
may arise in relation to those assets.
Modelling should take as input:

• Entity risk assessment data.
• Information classification and information

system and/or service categorisation.
• Vendor data on common incident types.
• Procedures applicable to the information

asset’s creation, usage and disposal.
• Procedures applicable to the information

system’s design, testing, commissioning and
management.
• Configuration diagrams and documentation

applicable to the information system.
• The information system’s Information

Security Design (including the definition of
use cases and the Information Security
controls intended to address them).

IM.1.1 • The Service Level Agreement that applies to M M M
(Cont.) the given information system or service and
any associated Operating Level Agreements
and Third Party Supplier Contracts.
• Records of past changes and incidents

applicable to predecessor information system
types.
IM.1.2 Modelling should seek to confirm: M M M
• The category of incident that may occur

(e.g. virus outbreak, defacement of web site,
distributed denial of service).
• The triggers that would give rise to the

categories of incident occurring (i.e. what
exploit would need to apply to what
vulnerability).
• The symptoms that could be anticipated to

be associated with the attack (e.g. specific
error messages, degradation of information
system performance, increased number of
information system account lock-outs).
• The factors that might be anticipated to

amplify or perpetuate the incident (e.g. lack
of network segmentation, lack of information
system patching, lack of user awareness of
social engineering techniques).
• The key skills that would be needed to identify,

diagnose, contain and eradicate the given
incident type (e.g. Unix system administration,
network architecture, security engineering,
incident management).
• The key inputs that would be needed to contain

and manage the given incident type (e.g.
configuration graphics, Information Security
Design, intrusion detection reports).
281
IM.1.3 After modelling, incident types should be M M M
ranked using the Abu Dhabi Information Security
Risk Management Guide. Potential incidents of
highest probability and highest impact should be
prioritised for further attention.
IM.1.4 Information Security incident modelling should be R R R

repeated whenever there is significant change in:
• The information asset or information system
• The business process and/or organisation it
relates to
• The configuration of the information system
• The security control set applied
• The Service Level Agreement associated with
the asset or information system
Control
Dependencies

o IR-3 Incident Response Testing and Exercises
• NIST Special Publication 800-61 Revision 1 ‘Computer

Security Incident Handling Guide’
• Abu Dhabi Information Security Risk Management Guide

Management Roles and Suggested P1
Responsibilities Priority
Control The Entity shall define and allocate roles and responsibilities
Standards for the management of Information Security incidents.
IM.2.1 On the basis of its incident modelling data (see M M M
IM.1 Information Security Incident Modelling), the
Entity should define and allocate the roles and
responsibilities necessary to manage the most
significant Information Security incident types it
potentially faces.
The specific configuration of roles and

responsibilities may potentially vary, based
upon the type of incident, the area of business
affected, the technology concerned, the
geographical location of assets etc.
IM.2.2 The Entity should ensure that individuals M M M

involved in the management of Information
Security incidents have the necessary skills,
experience, competencies and training to
undertake their defined roles.
IM.2.3 The Entity should ensure that the range of M M M

roles and responsibilities address, as a minimum:
• Planning and resourcing of Incident
Management capabilities.
• Definition of Incident Management policy and

procedural content.
• Training of personnel involved in Incident

Management.
283
IM.2.3 • Testing and verification of Incident Manage- M M M
(Cont.) ment capabilities in advance of incidents
occurring.
• End-to-end management of the incident

response lifecycle.
• Containment of the incident (to limit its

potential to increase in impact).
• Technical investigation and analysis of the

incident’s symptoms and root cause.
• Communication with key stakeholders.
• Restoration of the information service to

pre-incident parameters.
• Recording of key decisions and activities

during the incident lifecycle.
• Post incident analysis.
• Application of agreed corrective actions and

improvements.
Depending on the size of the organisation a

single individual may undertake one or a number
of the roles outlined above.

IM.2.4 When designing security roles and responsibilities R R R
the Entity should seek to ensure sufficient
breadth and depth of skills, while avoiding
incident response teams being over-manned.
Involvement in incident response should be
confined to individuals with a defined, value-
adding role that is clearly demarcated from
others roles. Involvement of peripheral parties
without a key role to play may increase the
communication burden and slow down decision-
making during critical phases of an incident
response.
Control IM.1 Information Security Incident Modelling

Dependencies

o IR-2 Incident Response Training
o IR-3 Incident Response Testing and Exercises

285
Management Planning Suggested P2
Priority
Control The Entity shall develop plans and define procedures to ensure
Standards a prompt, effective response to Information Security incidents.
IM.3.1 The Entity should have a primary orientation M M M
toward the avoidance of Information Security
incidents through:
• The effective exercising of information
ownership responsibilities
• Prudent administration and stewardship of

information systems and networks
• Awareness of the Entity’s risk profile and the

application of appropriate controls to avoid,
mitigate, transfer or accept those risks
• Regular analysis of and eradication of known

vulnerabilities
• Training and awareness of information users
• Design of information systems and networks

that are resilient and robust
However much this proactive orientation is

embraced, the Entity should anticipate that
security incidents can and will arise. It should
plan effectively for them to ensure:
• They are promptly recognised when they occur
• Their impact is limited as much as is possible

through timely, targeted and effective
intervention

IM.3.2 Based upon its incident modelling data (see IM.1 M M M
Information Security Incident Modelling), the Entity
should develop an Information Security Incident
Management Plan, subsidiary to its Information
Security Programme Plan (see SG.1 Information
Security Programme Management) that:
• Provides the organisation with a roadmap
for implementing its Incident Management
capabilities.
• Describes the structure and organisation of

the incident response capability.
• Provides a high-level approach for how the

Incident Management responsibility fits into
the overall organisation.
• Meets the unique requirements of the

organisation, which relate to mission, size,
structure and functions.
• Defines reportable incidents.
• Provides metrics for measuring the incident

response capability, within the Entity.
• Defines the resources and management

support needed to effectively maintain and
mature the Entity’s incident response capability.
• Is reviewed and approved by the Entity’s

IM.3.3 The Entity should coordinate its planning efforts M M M

with relevant external parties (e.g. ADSIC,
aeCERT) to ensure that proposed Incident
Management capabilities are effectively
integrated with applicable activities and services
in those other organisations.
287
IM.3.3 Whenever reviewing its Incident Management M M M
(Cont.) plans, the Entity should consider the Incident
Management interfaces and notification
obligations between itself and such external
stakeholders.
IM.3.4 The Entity should develop procedures and R R R

incident handling checklists for the incident
categories it defined during its incident modelling
(see IM.1 Information Security Incident Modelling).
The checklists should outline the key activities
and responsibilities that should be taken in
responding to, containing and eradicating the
specific incident type concerned.
For scenarios where a given incident would not

map to any other category, a generic incident
handling checklist should be provided.
(Checklist-based documentation should be

preferred over longer form documentation, to
ensure that quick reference can be made to key
activities needing to be undertaken during an
incident response)
IM.3.5 The Entity should implement mechanisms that M M M

would allow both internal information users
and also outside parties to report Information
Security-related incidents. The Entity should
publish telephone and email contact details to
allow such incident notifications to be received.
IM.3.6 Access to Incident Management plans, M M M

procedures and checklists should be restricted,
due to the potentially sensitive nature of an
incident. However, plans, procedures and check-
lists should be readily available to the Incident
Management team from any location where
they may reasonably anticipate undertaking
incident response activities, including
contingency sites.

IM.3.7 The Entity should apply the following M M M
prioritisation framework for determining how
finite resources should be deployed to support
the management of potentially multiple
concurrent Information security incidents.
Priority 1 – Major Incident

Substantial, possibly wide-ranging, actual or
potential damage to the confidentiality, integrity
or availability of the Entity’s critical information
assets and information systems. (This criticality
may be indicated through the business value or
the classification of the information/information
system). Such incidents will have serious and
sustained impact on the organisation’s capability
to operate and/or its reputation.
Example: Sustained distributed Denial of

Service attack against an Entity with public-
facing services.
Priority 2 – Significant Incident

Contained actual or potential damage to the
confidentiality, integrity or availability of the
Entity’s information assets and information
systems. Example: unauthorised extrusion of
data by a limited number of employees.
Invocation of the Entity’s Information Systems

Continuity Management Plan may be a necessary
consideration when addressing a Priority 1 or
Priority 2 incident.
Priority 3 – Minor Incident

Limited actual or potential damage to the
confidentiality, integrity or availability of the
Entity’s information assets and information
systems. Example: virus or trojan detection on a
single work station.
289
IM.3.7 The Entity should anticipate that the priority of M M M
(Cont.) an Information Security incident may change
during its lifecycle, as more information becomes
available, or as the effects of the incident change.
IM.3.8 The Entity should baseline the normal behaviours R R R

and performance parameters of information
networks, information systems, applications and
users and these should be communicated to
support staff and incident responders. Familiarity
with the expected baseline can help determine
a) if an incident is occurring, b) its level of
impact and c) the effectiveness of corrective
interventions applied.
IM.3.9 The Entity should consider developing and S S S

maintaining a central knowledgebase of
information. Such can provide a consistent and
up-to-date source of relevant information for
incident diagnosis and response. The knowledge
base may include general information, such as
commonly used network port numbers, links to
malware information etc., as well as records from
previous incidents.
IM.3.10 The Entity should consider developing an incident S S S

diagnosis matrix for first responders (e.g. help
desk staff, system administrators) and incident
response team members. Such a diagnosis matrix
can assist personnel in determining what type of
incident may be occurring. The matrix may list
incident categories and the symptoms associated
with each, providing advice as regards what type
of incident is occurring, how the diagnosis can be
validated and what next steps should be taken.

IM.3.11 The Entity should establish and maintain S S S
cooperative relationships between its incident
response capability and external providers of
information system protection (e.g. Computer
Emergency Response Teams). Such relationships
may help the Entity remain current with
Information Security incident trends and best
practice on how to manage incident response.
IM.3.12 The Entity’s executive management should S S S

consider giving informed, prior approval to
the special permissions and rights that may be
required by incident response teams in order to
contain or eradicate an incident e.g. reallocation
of resources, suspension of services, revoking of
access rights.
The incident planning process should ensure that

these requests are anticipated and discussed in
advance of them being required.
Control IM.1 Information Security Incident Modelling

Dependencies

Requirements:
o 13.2.1 Responsibilities and Procedures

o IR-1 Incident Response Policy and Procedures

291
Training and Simulation Suggested P2
Priority
Control The Entity shall train personnel in their incident response roles
Standards and responsibilities to ensure response plans can be invoked
effectively.
q a Detective
q q Corrective
IM.4.1 The Entity should train personnel in the scope R R M
and application of their incident response duties.
This should include regular simulation of incident
response scenarios, as part of an on-going cycle
of Information Security Incident Management
training.
The Entity should not assume that Information

Security incident response plans can be invoked
smoothly and without issue. The speed of events,
the sometimes contradictory or partial data and
the pressures involved during a live incident may
contribute to poor decision making and poor
plan execution.
IM.4.2 Incident simulations should seek to provide a R R R

realistic replication of the attributes of common
Information Security incident types in order to
prepare incident response capabilities for future
events.
IM.4.3 A coordinator independent of the incident R R R

response team should be tasked with preparing
the necessary scenario data and facilitating
incident simulation. The coordinator should also
facilitate the capturing, analysis and reporting of
lessons learned from the training.

IM.4.4 Findings and associated improvements from R R R
incident response training and simulations
should be fed back into revised Incident
Management plans, procedures, training and
security appliance configuration.
IM.4.5 The coordinator of the incident simulation R R R

should consider substituting members of the
incident response team without prior notice, to
determine if response capabilities can still be
managed effectively if the primary role holder
would not to be available.
IM.4.6 Refresher training should be provided regularly S S S

(at least annually) to incident response
personnel to ensure they remain aware of their
responsibilities and that their knowledge of
incident management techniques stays current.
Control IM.3 Information Security Incident Management Planning

Dependencies TA.4 Security Training Development and Delivery

293
IM.5 Reporting Information Security Version 2.0
Weaknesses and Events Suggested P2
Priority
Control The Entity shall require information users and system
Standards administrators to report Information Security events and
weaknesses.
q a Detective
q q Corrective
IM.5.1 The Entity should obligate all information M M M
users and information systems administrators
(whether employees, contractors or other third
parties) to report any observed or suspected
Information Security weaknesses or events.
IM.5.2 Information Security awareness campaigns M M M

should support the objectives of information
users being:
• Able to recognize the attributes of a given type
of Information Security weakness or event.
• Informed as to the expected reporting channel

for their communication of the weakness or
event.
• Aware of the consequences for failing to report

relevant weaknesses or security events.
Control HR.5 Security Induction

Dependencies TA.2 General Awareness Message Delivery
TA.3 Security Training Development


IM.6 Management of Security Incident Version 1.0
Response Suggested P2
Priority
Control The Entity shall ensure that Information Security incidents are
Standards managed effectively and with an orientation toward learning.
q q Corrective
a
IM.6.1 The Entity should ensure that Information M M M
Security incidents are managed by an
incident response team that has the requisite
empowerment and management support to
fully investigate and resolve the matter at hand.
IM.6.2 The incident response team should be protected R R R

from time and organisational pressures that
could prevent or impede it from conducting an
independent and thorough investigation.
IM.6.3 The Information Security incident response M M M

should be managed throughout its full lifecycle i.e.:
• Detection
• Analysis
• Containment
• Eradication
• Recovery
• Improvement
IM.6.4 For major Information Security incidents, a M M M

single incident manager should be allocated
to assume end-to-end responsibility for the
incident response. The incident manager should
be empowered to direct and re-allocate Entity
resources as required to ensure the maximum
effectiveness of the incident response capabilities.
295
IM.6.5 The Entity should align and integrate its M M M
capabilities with its:
a) Information System Continuity Management
capabilities
b) Incident Management capabilities applicable
to other management disciplines
To ensure that:
• The disciplines are mutually supportive.
• Efforts are not duplicated across the disciplines
within the Entity.
• There is a consistent and well understood
interface to ensure a clean hand-off between
the processes.
IM.6.6 The Entity should coordinate its incident M M M

response capabilities with ADSIC and aeCERT
(as applicable) when Priority 1 and Priority 2
incidents occur (see IM.3 Information Security
Incident Management Planning).
Priority 1 and Priority 2 incidents should be

reported immediately to ADSIC upon the Entity
recognising them as having this designation.
The Entity should ensure that relevant external

stakeholders receive timely and accurate
communications on the cause and status of
the incident, with the view to limiting potential
exposure in other areas of government and to
promote cross-functional learning arising from
incident occurrence.

IM.6.7 Information Security Incident Managers should M M M
ensure that Information Security incidents
are managed in accordance with the Abu Dhabi
Information Security Incident Response Checklist.
Control IM.3 Information Security Incident Management Planning

Dependencies

o IR-4 Incident Handling
• Abu Dhabi Information Security Incident Response
Checklist.
297
IM.7 Management of Security Evidence Version 2.0
Suggested P2
Priority
Control The Entity shall manage the collection and preservation of
Standards Information Security-related evidence conforming to the rules
for evidence laid down in the relevant jurisdiction(s).
q a Detective
q q Corrective
IM.7.1 The Entity should develop internal procedures M M M
to direct the collection, preservation and
presentation of Information Security-related
evidence. Such evidence having the potential to
serve as input to one or more of the following
outcomes:
• An internal disciplinary action handled within
the Entity
• A criminal investigation undertaken by the
police
• A civil action pursued through the courts
IM.7.2 The Entity’s evidence management procedures M M M

and practices should demonstrate alignment to
the following four distinct phases:
1) Collection. Data is identified and the evidence

is labelled in a format that confirms its source,
its purpose and its intended storage location.
Collection procedures should preserve the
integrity of the data. Data should be collected
in a timely manner to avoid the loss of
dynamic data, such as a list of current network
connections, and the data held in mobile
devices (e.g. cell phones, smart phones, tablets,
PDAs, and other battery-powered devices).

IM.7.2 2) Examination. The data that is collected should M M M
(Cont.) be examined using a combination of automated
and manual methods to assess and extract data
of particular interest for the specific situation,
while preserving the integrity of the data.
3) Analysis. The results of the examination should

be analysed, using well-documented methods
and techniques, to derive useful information
that addresses the questions that were the
impetus for the collection and examination.
4) Reporting. The results of the analysis should be

reported to relevant senior stakeholders. Items
to be reported may include: a description of the
actions employed; an explanation of how tools
and procedures were selected; a determination
of any other actions that should be performed,
such as forensic examination of additional data
sources, securing identified vulnerabilities
and recommendations for improvements to
policies, guidelines, procedures, tools, and
other aspects of the forensic process.
IM.7.3 Personnel involved in the collection, analysis and M M M

management of Information Security-related
evidence should be trained in the specific skill
areas necessary to achieve accurate capture and
custodianship of that evidence.
IM.7.4 The integrity of all evidential material should be M M M

protected. Any forensics work should only be
performed on copies of the evidential material.
No action taken in the collection of evidence

should change data held on an information
system, or other media, which may subsequently
be relied upon in Court.
299
IM.7.4 Copying of evidential material should be M M M
(Cont.) supervised by trustworthy personnel and the
following data relating to the evidence should be
logged:
• What evidence was copied
• When and where the copying process was
executed
• Who performed the copying activities
• Which collection methods, tools and
programs were utilised
IM.7.5 An audit trail or other record of all processes M M M

applied to computer based evidence should be
created and preserved. An independent party
should be able to examine those processes,
assess an exhibit, and achieve the same result.
IM.7.6 Where an Information Security incident M M M

investigation identifies the potential need for
evidence collection and retention, the Entity
should involve a lawyer or the police early in the
incident lifecycle and take advice on the evidence
required.
IM.7.7 Copies of digital evidence taken from computer M M M

disks should be extracted with write blocking
capabilities enabled on the target device. Such
being to avoid potential modification of the
data during the copying process. Captured disk
images should be made to sanitised, write-
protected or write-once media.
IM.7.8 In exceptional circumstances, where it is M M M

necessary to access original data held on
an information system that is a target of
investigation, the person undertaking the access
must be competent to do so and should be able
to give evidence explaining the relevance and
the implications of their actions.

IM.7.9 Collected evidence should be catalogued and M M M
stored in a secure area. Any movements of
evidence into and out of the secure area should
be documented and approved by senior Entity
personnel.
IM.7.10 Information system and network logs will M M M

frequently serve as a primary source of digital
evidence. They should be protected in accordance
with the guidance described in OM. 20 System
and Network Log Management and Analysis.
Control OM.20 System and Network Log Management and Analysis

Dependencies TA.3 Tailored Awareness Security Training

Requirements:
o 13.2.3 Collection of evidence
o AU-9 Protection of Audit Information
o IR-4 Incident Handling
• NIST Special Publication 800-86 ‘Guide To Integrating
Forensic Techniques Into Incident Response’
• ISO/IEC 27037 — IT Security — Security techniques —
Guidelines for identification, collection, acquisition, and
preservation of digital evidence (DIS)
• Association of Chief Police Officer (ACPO) ‘Good Practice
Guide For Computer-Based Electronic Evidence’
301
IM.8 Post-Incident Analysis, Reporting Version 2.0
and Corrective Action Suggested P2
Priority
Control The Entity shall monitor the effectiveness of its Information
Standards Security Incident Management capabilities and apply corrective
actions as required.
q a Detective
q q Corrective
a
IM.8.1 Following Priority 1 and 2 Information Security M M M
incidents, the Entity should undertake formal
post-incident review to establish:
• The type of incident that occurred.
• The priority that was assigned to the incident.
• The symptoms of the incident.
• The business impact (financial, reputational
and productivity-related) of the incident.
• The cause(s) of the incident.
• The key milestones within the incident lifecycle
and when they were reached.
• Whether the incident cause can be correlated
to one or more vulnerability that was, or could
have been, known by the Entity.
• The key interventions made to contain,
diagnose and eradicate the incident and their
level of effectiveness.
• The performance of the incident management
process and the incident response team.
• The timeliness and quality of data and tools
utilised by the incident response team.

IM.8.1 • The cost of the incident response activities. M M M
(Cont.)
• The lessons learned and the prioritised
corrective action steps and improvements
that will be implemented. Corrective actions
should be overtly accepted by the control
owner and a timeline for when these will be
implemented should be agreed.
IM.8.2 Post-incident review should involve those with M M M

a direct involvement with the incident – both
members of the incident response team and
parties impacted by the incident (e.g. business
unit representatives).
IM.8.3 The key findings from post-incident reviews M M M

should be documented and reported to key
stakeholders. Due to the sensitive nature of
some Information Security incidents, careful
consideration should be given to the appropriate
distribution of post-incident reports.
IM.8.4 The Entity’s Information Security Governance R R R

Committee should be a mandatory approver of
any draft post incident report, before its official
release.
IM.8.5 Corrective actions arising from incident reviews S S S

should have an orientation toward:
• Improving the Entity’s ability to recognise and
treat Information Security-related threats and
vulnerabilities, with the view to avoiding such
incidents occurring again, in future.
• Implementing process and control improve-

ments that would lessen the probability and
impact of such an incident.
303
IM.8.5 • Improving the quality and transaction speed S S S
(Cont.) of the Entity’s Information Security Incident
Management process.
• Determining if additional or improved

information and tooling would be required
to manage such an incident type in future.
• Improving the training and skills of incident

responders.
• Determining if existing controls are sufficiently

robust, mutually supportive and if sufficient
defence-in-depth is demonstrated in the
security control set.
Control
Dependencies

Requirements:
o 13.2.2 Learning from Information Security incidents

12.12 Information Systems Continuity Management
IC.1 Information Systems Continuity Version 2.0
Planning Framework Suggested P2
Priority
Control The Entity shall maintain a single framework for information
Standards systems continuity planning to ensure consistency in continuity
planning and testing.
q a Preventive
IC.1.1 The Entity should document procedures defining M M M
how information systems continuity activities
will be undertaken and by which roles within the
organisation. A common method for planning
and testing continuity capabilities should apply
to all information systems.
IC.1.2 The Entity should develop checklists for: S S S

• The development of continuity plans
• The testing of continuity plans
• The management of continuity-related
incidents
(Given the demands that arise when continuity

provisions need to be invoked, checklists may
provide an effective mechanism for quickly
accessing key data).
IC.1.3 The Entity’s Information Systems Continuity R R R

Management framework should be integrated
with its Information Security Incident
Management capabilities, to ensure that
continuity provisions can be evoked in an
effective and timely manner.
Integration should include consideration of:

• The criteria that would need to be met in
order for the Information Systems Continuity
Management plan to be invoked.
305
IC.1.3 • Avoiding duplication of effort and roles in R R R
(Cont.) Information Systems Continuity Management
and Information Security Incident Management.
• The alerting mechanisms required within

Information Security Incident Management in
order to make relevant stakeholders aware of
an actual or potential continuity scenario.
IC.1.4 The Entity’s Information Systems Continuity S R R

Management framework should seek to provide
for service continuity beyond just addressing
disaster recovery scenarios. Preventive controls
that would limit the need for a disaster recovery
capability needing to be invoked may include:
• Disk mirroring
• Server clustering
• Load balancing
• Parallel processing
IC.1.5 The Entity’s Information Systems Continuity M M M

Management framework should be integrated
with its Business Continuity capabilities, where
such are in effect within the Entity.
Control
Dependencies

Requirements:
o 14.1.1 Including Information Security in the business
continuity management process
Planning Guide for Federal Information Systems’

Requirements Suggested P2
Priority
Control The Entity shall capture and analyse requirements for continuity
Standards management provisions in support of required and agreed
levels of information systems availability.
IC.2.1 The Entity should solicit the Information System S M M
Owner’s and Information Owner’s inputs to
determine the level of service availability
required. This should be confirmed within a
Service Level Require-ments document that
serves as the primary input to a Service Level
Agreement.
Availability requirements should be expressed in

terms of:
• Core operating hours during which the
information system should be fully available.
• Extended operating hours during which the
information system should be either fully or
partially available.
• Maximum tolerable planned maintenance
outage times in a given period (both in
terms of single total outage and cumulative
maintenance for the given period).
To address exceptional circumstances (i.e.

events that take the service outside of its normal
operating parameters), availability requirements
should additionally address:
• The Recovery Time Objective (i.e. how quickly
the service must be recovered in the event of
an exceptional outage).
• The Recovery Point Objective (i.e. the

maximum tolerable amount of data that can
be lost following an exceptional outage).
307
IC.2.2 Continuity requirements should be validated via R R R
the conducting of a Business Impact Analysis
(BIA) that seeks to confirm the anticipated
harm that would be caused in the event of the
information system being unavailable. (However
the ability to conduct such an exercise may be
contingent upon the presence and maturity of
Business Continuity Management within the
Entity).
IC.2.3 Requirements for information systems R R R

continuity should be pragmatic (rather than
aspirational) and should be mindful of the
genuine availability needs for the information
being hosted on the information system.
Stakeholders should be prompted to consider
the cost vs. benefit of continuity provisions when
expressing their requirements.
IC.2.4 Information system continuity requirements R R R

should be considered in the broader context of
the Entity Business Continuity Management
framework, where such is in effect.
IC.2.5 Requirements for information systems R R R

continuity should be responded to with a set
of costed options from which the Information
System Owner may chose an optimal solution,
on the basis of their business need, the risks
presented and the available resources.

Control IS.1 – Security Requirements

Dependencies

Requirements:
o 14.1.1 Including Information Security in the business
continuity management process
309
Plan Suggested P2
Priority
Control The Entity shall develop and maintain information systems
Standards continuity plans that define how continuity provisions will be
delivered to achieve agreed service recovery parameters.
q a Detective
q q Corrective
IC.3.1 The Entity’s information system continuity plans S R M
should confirm:
• The assets involved in the composition and

support of the target information system.
• The anticipated impact of possible continuity

scenarios (e.g. data centre fire, virus outbreak,
loss of network connectivity).
• Recovery Point and Recovery Time Objectives

for the information system.
• The projected costs to recover the information

system vs. the financial impact of its being
unavailable.
• The key roles and responsibilities in executing

the continuity plan, including which parties
may authorise key activities (e.g. deciding to
move data processing from the primary facility
to the recovery facility).
• The infrastructure and preventive, detective

& corrective controls that will be/have
been deployed to provide for continuity at
the requisite level of information system
availability and performance and the current
status of these controls.

IC.3.1 • How key post-holders will be trained in the S R M
(Cont.) Continuity Management responsibilities.
• The essential steps to be taken in relation to

information system recovery including:
- Management of the event (via the Incident
Management process)
- Containment of the issue
- Recovery of the service (how and where)
- Communication of status to key
stakeholders
- Maintenance of data confidentiality and
integrity during recovery activities
• The location of essential documentation e.g.

- Information system designs and blueprints
- Third Party Supplier contracts
- Contact lists
• How and when tests against the continuity

plan will be conducted.
• How test results will be documented and

communicated.
• How invocations of the continuity plan will be

recorded, analysed and reported upon.
IC.3.2 The Entity should hold up-to-date copies of its S R M

continuity plans at both primary and back-up
locations (especially at any designated recovery
location).
311
IC.3.3 If continuity plans are maintained on a per service S R M
basis, the Entity should consider developing
a master continuity plan that has precedence
over each of these plans. The master plan
will confirm the priority in which information
systems should be recovered, in the event that
multiple information systems fail at the same
time (e.g. following the loss of a data centre).
IC.3.4 Continuity plans should be maintained and S R M

should remain current with information system
enhancements and organisational changes.
Changes to production information systems
should evaluated for their potential impact on
the continuity plan.
IC.3.5 The continuity plan should be approved prior to S S S

the information system moving to production
status. Where this does not occur, the Information
System Owner should formally document their
acceptance of quantified risks associated with
there not being continuity provisions in place.
Control
Dependencies
References • NIST Special Publication 800-34 Revision 1 ‘Contingency


IC.4 Testing of Information System Version 2.0
Continuity Plans Suggested P2
Priority
Control The Entity shall regularly test and update information system
Standards continuity plans to ensure their continued accuracy and
effectiveness.
q a Detective
q q Corrective
IC.4.1 The Entity should conduct tests of its information S R M
systems continuity plans to determine if
the recovery targets can be met and if the
documented approach to recovery is followed in
practice.
Testing should seek to address questions

including:
• Can the Recovery Time Objective be met?
• Can the Recovery Point Objective be met?
• Are parties clear on their roles and respon-

sibilities and the demarcation between them?
• Do parties exhibit the necessary competencies

and aptitudes required to undertake those
roles and responsibilities?
• Does the process of recovery contain the

minimum number of workflow steps required
in order to be effective? (Unnecessary process
definition may impede the potential for
recovery).
• Are key inputs required by the continuity

process (e.g. back-up media, standby
equipment, personnel, and documentation)
available when required to efficiently
implement an information system recovery?
313
IC.4.1 • Do preventive controls work as anticipated to S R M
(Cont.) lessen the potential for information system
interruption?
• Do detective controls work as anticipated to

identify conditions under which continuity
provisions would need to be invoked?
• Do corrective controls work as anticipated to

return the information system to a known and
required operating state?
• Can the information system be reconstituted

in a configuration consistent with it’s
a) approved information system & security
design and b) its last known approved state,
as approved via the Entity’s Change Manage-
ment process?
• Is there an effective approach to communica-

tion with key stakeholders?
• Is a requisite level of data confidentiality and

data integrity maintained during recovery
activities?
• Can information systems be recovered in a

prioritised way that reflects agreed business
criticality?
• Do environmental and telecommunications

facilities at recovery sites function as
anticipated?
• Can effective supply chain management in

support of continuity be demonstrated (e.g.
replacement equipment can be delivered
within time to compatible recovery targets)

IC.4.2 Depending on the criticality of the information S R M
system, continuity tests should be conducted in
one of several ways, including:
Tabletop Exercises
Discussion-based exercises where personnel
meet in a classroom setting or in breakout groups
to review a) their roles during an emergency and
b) their responses to a particular emergency
situation.
A facilitator should present a scenario and ask

the exercise participants questions related to
the scenario, initiating a discussion among the
participants regarding roles, responsibilities,
coordination, and decision making.
Functional Exercises
Allow personnel to validate their operational
readiness for emergencies by performing
their continuity-related duties in a simulated
operational environment.
Functional exercises are designed to practice

the roles and responsibilities of specific team
members, procedures, and application of the
assets involved in one or more functional aspects
of the continuity plan (e.g., communications,
emergency notifications, equipment setup).
Functional exercises may vary in complexity

and scope, from validating specific aspects of a
plan to full-scale exercises that address all plan
elements.
315
IC.4.3 When testing its continuity management S S S
provisions, the Entity should consider substituting
key personnel during testing exercises to
determine if recovery objectives can still be
met in the event of those individuals not being
available to undertake their roles.
IC.4.4 Results of continuity testing activities should be S S S

documented, analysed and recommendations
for improvement should be approved and
tracked by the Entity’s Information Security
Governance Committee.
Control IC.3 Information Systems Continuity Plan

Dependencies
References • NIST Special Publication 800-34 Revision 1 ‘Contingency


317
Appendices
Appendix A
320 Information Security Policies

Appendices
Acronyms
ADGE Abu Dhabi Government Entity
ADSIC Abu Dhabi Systems and Information Centre
AVS Anti-Virus Software
CISO Chief Information Security Officer
DMZ Demilitarised Zone
DNS Domain Name System
HR Human Resources
IDS/IPS Intrusion Detection System/Intrusion Prevention System
IS Information Security
ISGC Information Security Governance Committee
ISMS Information Security Management Systems
ISO/IEC International Organisation for Standardisation/International

Electrotechnical Commission
IT Information Technology
NIST National Institute of Standards & Technology
PDCA Plan-Do-Check-Act
SQL Structured Query Language
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
UTM Unified Threat Management
UAE United Arab Emirates
uRPF Unicast Reverse Path Forwarding
321
Appendix B

Appendices
Definitions
Accreditation The official management decision given by a senior Entity official
(e.g. chairman) to authorise the operation of a government service
and to explicitly accept the risk to Entity operations, assets or
individuals based on the implementation of an agreed-upon set of
security controls.
Adequate Security Security commensurate with the risk and the magnitude of
harm resulting from the loss, misuse or unauthorised access to
modification of information.
Audit A formal (independent) review of a project, business process

or information system to assess compliance with policy and
standards and to determine control adequacy.
Availability Ensuring timely and reliable access to, and use of, information.
Baseline The default state for an information system or a control that aligns
to it designed and expected operating parameters.
Confidentiality The act of preserving authorised restrictions on information access

and disclosure, including means for protecting personal privacy and
proprietary information.
Control The application of people, process and/or technology in support of

transacting business and managing risk. Controls can be technical
or managerial in nature.
Control Specification One or more elements of control implementation specifying how a

given control standard may be met.
Control Standard The security outcome needing to be realised in order to achieve

standards compliance and to ensure adequate security.
Corrective Controls Contribute to the return of an information asset to its last known
good state, with the view to removing a vulnerability, or reducing
its potential impact to an acceptable level.
(Example controls: information system reimaging to an approved
configuration baseline, lessons learned reporting).
Cost-Effective Control A control is judged to be cost effective when the cost of

implementing and maintaining it is economical in comparison to
the potential impact of the associated risk.
Detective Controls Identity vulnerabilities that either are being exploited, or

potentially could be exploited, to realise a threat.
(Example controls: system log analysis, network vulnerability
scanning).
Directive Controls Express management expectations of behaviours and activities

required for risk avoidance and risk mitigation, in support of the
Information Security programme.
(Example controls: Information Security policy, security-related
schedules within third-party supplier contracts).
323
Functional Controls The security controls for an information system that are primarily
implemented and executed by people (as opposed to technology).
General User An individual with a standard level of access to an information

system (compared to the ‘Privileged User’ defined below).
General users will typically be allowed access to information
assets in a manner appropriate to the approval given but will not
be allowed to substantially reconfigure the information system.
Information Any communication or representation of knowledge such as

facts, data or opinions in any medium or form; including textual,
numerical, graphic, cartographic, narrative or audio visual forms.
Information Asset Any knowledge or data, whether tangible or intangible, that has
a value to the organisation, such as information or information
systems.
Information Owner The party (individual or function) with responsibility for the
custodianship of a given information asset, on behalf of the Entity.
The Information Owner should have clear understanding of what
the information asset is, where it is located (physically and/or
logically), what business purpose it serves, what risks apply to the
information asset, who is authorised to have access to it and what
they are permitted to do with it. The Information Owner role will
typically be assigned within the business unit holding the primary
responsibility for the given category of information assets
(e.g. the Financial Department for financial records).
Information Security Protection of information and information systems from

unauthorised access, use, disclosure, disruption, modification
or destruction in order to provide confidentiality, integrity,
availability, authentication and non-repudiation.
Information Security Design Formal document that provides an overview of planned security
controls for a specific service, correlated to the security services
those controls are intended to provide and the requirements they
will address.
Information System A discrete set of information resources organised for the

collection, processing, maintenance, use, sharing, dissemination
or disposal of information, including manual processes or
automated processes. This includes information systems used by
an entity either directly or used by another entity, or a contractor
under a contractor with the entity that: (i) requires the use of such
information systems; or (ii) requires the use, to significant extent,
of such information systems in the performance of a service or
the furnishing of a product. Information systems may generate
outputs that are electronic and/or paper-based.

Appendices
Information System Owner The party (individual or function) with responsibility for the
custodianship of a given information system, on behalf of
the Entity. The Information System Owner should have clear
understanding of the information system’s component elements,
what purpose the information system serves, what information
assets are resident on the information system, where it is located
(physically and/or logically), what risks apply to the information
system, who the Information Owner has authorised to
access information assets held on it and how it is secured.
The Information System Owner responsibility may frequently
(but not always) be allocated within the Entity’s IT department.
Information Security Event An identified occurrence of an information system, service

or network state indicating possible breach of an Information
Security policy, breach of standards, failure of safeguards and/or
the introduction of a new vulnerability.
Information Security Incident A single or series of unwanted or unexpected Information Security

events that have a significant probability of compromising
business operations or threatening Information Security.
Information Technology Any equipment or interconnected information system or

subsystem of equipment that is used in the automatic acquisition,
storage, manipulation, management, movement, control, display,
switching, interchange, transmission, or reception of data.
Integrity The act of guarding against improper information modification or

destruction, and includes ensuring information non-repudiation
and authenticity.
IT Assets Computer equipment and devices (such as servers, workstations,

routers etc.) and software.
Key Security Indicator The most important security metrics that the organisation uses
to determine the performance and activity within its Information
Security programme.
Malicious Code Software or firmware intended to perform an unauthorised

process that will have an adverse impact upon the security of
an information system (e.g. virus, worm, Trojan horse or other
software code that infects a host).
Management Controls Security controls that focus on the management of risk and the
deployment of finite resources to address the organisation’s
security objectives.
Mitigation One of the main actions that can be taken in relation to risk.
Mitigation does not lessen the likelihood of a risk occurring
but is intended to lessen its impact when it does.
325
Personally Identifiable Information that readily identifies an individual
Information (e.g. name, address or other identifying number or code,
telephone number, email address etc.)
Policy Expression of management’s intention, direction and

expectations in relation to the required posture for a given
discipline (in this case Information Security).
Potential Impact The outcome that could occur in the event of a risk being
realised. Impact may be felt in a number of ways e.g. financial,
reputational, breach of confidentiality, breach of integrity etc.
The degree of impact may vary from moderate to high.
Preventive Controls Avoid security-related threats from being manifested, or limit

their potential to achieve their fullest potential impact.
(Example controls: network firewall, segregation of duties, email
spam filtering).
Privacy The protection of personal data that are being processed and/or
stored by the Abu Dhabi government entities.
Privileged User An individual with an enhanced level of access to an information

system, relative to the majority of the user population for that
information system e.g. IT system and network administrators
who utilise ‘root’ or ‘super user’ privileges in order to manage the
information system and makes changes to its configuration.
‘Production’ Information Information systems transition through a lifecycle of: i) ‘Design’

System ii) ‘Development’ iii) ‘Testing’ iv) ‘Production’ and v) ‘Retirement/
Replacement’.
Information systems will have ‘Production’ status when being

used to access, modify, transmit or store the entity’s business
records.
Residual Risk Risk that remains after the implementation of enhancement

of a control.
Risk Exposure to danger, harm or loss that may be encountered

when a vulnerability is exploited by a threat.
The level of impact on entity services, information assets,

or individuals resulting from the potential consequences of a
threat and the likelihood of that threat occurring.
Risk Management The steps taken by an entity in identifying, analysing,

Interventions responding to and/or monitoring a risk.

Appendices
Recovery Point The maximum tolerable period in which data might be lost.
Objective (RPO)
Recovery Time Objective The maximum tolerable outage that can be accepted on an
(RTO) information system.
Security Domain A collection of associated control standards. Within these

Standards the twelve domains of Information Security are those
described in section 2.1.3 of the document.
Spyware Software that is secretly or surreptitiously installed on an

information system.
System Interchangeable with ‘Information System’ unless otherwise

indicated.
Third Party An individual or organisation that is recognised as being

independent of the parties involved. In the context of these
Standards, the term ‘third party’ will normally refer to third-party
(i.e. external) suppliers, unless otherwise stated.
Third Party Supplier A Contract between an IT Service Provider (i.e. ADGE’s IT

Contract function) and a Third Party. The Third Party provides goods or
Services that support delivery of an IT Service to a Customer.
The Third Party Supplier Contract defines targets and
responsibilities that are required to meet the business
requirements.
Threat A potential cause of an unwanted incident, which may result

in harm to an information system or organisation.
Vulnerability A weakness within an asset, or group of assets, that can

be exploited by one or more threats to manifest a risk.
327
Appendix C

Appendices
Classification Matrix
The table below provides examples of the types of impact that a breach of classification would
manifest, were data of a given classification level to be compromised.
Impact Secret Confidential Restricted Public

Domain
Safety and Major and Exposure of key Exposure of minor Not Applicable
Security sustained government plans vulnerabilities
Impact disruption to the and capabilities in government
delivery of critical to respond to premises, services,
government national and information
services. Break pan-national systems and
down of social threats. Localised infrastructure.
cohesion and loss or intermittent
of critical national disruption to
assets. Risk to government
human life and services.
personal safety.
Economic Government-wide Significant Limited financial Not Applicable

Impact financial loss that financial loss loss occurring
has a substantial experienced within a single
effect on financial within a single Entity (e.g.
reserves. Entity. within a single
department/
contract/project)
Reputation Major harm to Limited or Minor Not Applicable

and the reputation of intermittent loss embarrassment
Confidence the government. of confidence by due to limited
Impact Profound loss citizens and other publication of
of confidence in stakeholders information
the credibility, in the design concerning the
integrity or and execution functioning of
competency of of government government.
government, by services.
the citizenry and
international
partners.
Privacy Breach Leakage of Compromise of Compromise Not Applicable

sensitive VIP critical personal of non-critical
personal data (e.g. data relating to personal data
properties, travel, citizens, residents relating to
health, financial and other citizens, residents
and security stakeholders (e.g. and other
protection data). financial records, stakeholders
health records). (e.g. profile of
government
service usage).
329
Appendix D

Appendices
V1 to V2 Standards Mapping
Note: where it is indicated below that there has been no change of control intent from v1 to v2, this should not be
taken to mean that there has been no change in the wording of specific clauses. Abu Dhabi Government Entities
should take the opportunity to review all elements of the v2 Control Standards. Due to changes made to v1 Control
Standards and the addition of new Controls Standards in v2, an Entity compliant with v1 Control Standards should
not assume compliance with the v2 counterparts.
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
ID Name ID Name
SP-1.1.101 Strategic N/A N/A All Control Standards for
Articulation which ADSIC had the primary
responsibility have been
removed in v2.
SP-1.1.201 Information N/A N/A All Control Standards for
Security Strategy which ADSIC had the primary
responsibility have been
removed in v2.
Security Road which ADSIC had the primary
Map responsibility have been
removed in v2.
Security which ADSIC had the primary
Interaction Model responsibility have been removed
in v2.
Processes responsibility have been
removed in v2.
SP-1.2.303 Chief Information SG.3 Information Further elaboration of the security
Security Officer Security organisation beyond the Chief
Organisation Information Security Officer is
provided in v2.
SP-1.3.103 Security SG.2 Information Control focus in v2 is toward
Categorisation Security reviewing the supporting guide
Categorisation for full details on Categorisation.
SP-1.3.303 Legal SG.5 Legal and No substantial change in the
Requirements Regulatory control intent.
Requirements
SP-1.3.403 Information IS.1 Security The primary focus of the v1
Security Plan Requirements control i.e. requirements capture
of Information is addressed in the IS.1 Control
Systems Standard of v2. However, elements
are also addressed in the IS.2
Control Standard.
PS-2.1.101 Government N/A N/A All Control Standards for
Information which ADSIC had the primary
Security Policy responsibility have been
removed in v2.
PS-2.1.203 Entity SG.8 Information More detail has been provided
Information Security Policy in v2 on areas of expected content
Security Policy in the policy.
331
ID Name ID Name
PS-2.2.101 Information N/A N/A All Control Standards for
Security Control which ADSIC had the primary
Objectives responsibility have been
removed in v2.
Security Control which ADSIC had the primary
Standards responsibility have been
removed in v2.
Security Process which ADSIC had the primary
Guidance responsibility have been removed
in v2.
Implementation responsibility have been
Guidance removed in v2.
RM-3.1.103 Risk Assessment RM.3 Risk Analysis v2 provides more direction on
the attributes of risk analysis that
needs to be considered.
RM-3.1.203 Risk Treatments RM.4 Risk Response v2 distinguishes been providing a
and Treatment response to a risk and treating it.
Not all risks will require treatment
(e.g. those that are knowingly
accepted).
RM-3.2.104 Security Testing IS.13 Information v2 Control Standard expanded
and Evaluation Systems and and made more tangible.
Network Security
Testing
RM-3.3.104 Certification and IS.13 Information V2 Control Standard focuses
Accreditation Systems and on informed acceptance of an
Network Security Information Security Test Plan as a
Testing precursor to information systems
authorisation by the designed
Entity-level Authorising Official.
RM-3.4.103 On-going RM.5 Risk Monitoring Renamed but no substantial
Monitoring and Corrective change in control intent.
Action
AT-4.1.104 General TA.2 General No substantial change in the
Awareness Awareness control intent.
Message Delivery Message Delivery
AT-4.1.203 Tailored TA.3 Tailored Control intent modified from
Awareness Awareness tailored awareness delivery based
Messages Security Training upon information system/service,
to tailored delivery based on
responsibilities.
AT-4.2.103 Security Training TA.4 Security Training Training Development and
Curriculum Development and Delivery-related clauses have been
Delivery combined into a unified v2 Control
Standard. A broader scoping has
been provided for planning and
development of training, beyond
just developing curricula.

ID Name ID Name
AT-4.2.203 Security Training TA.4 Security Training Training Development and
Delivery Development and Delivery-related clauses have been
Delivery combined into a unified v2 Control
Standard. A broader scoping has
been provided for planning and
AT-4.2.303 Security Training TA.4 Security Training Requirements for training record
Records Development and keeping subsumed into a broader
Delivery scoped control relating to the full
Information Security Development
and Delivery lifecycle.
CO-5.1.104 Tailored TA.3 Tailored Change of focus from shared
Information for Awareness ADSIC/Entity responsibility to
Stakeholders Security Training Entity only.
CO-5.1.204 Message N/A N/A All Control Standards for
Communication which ADSIC had the primary
responsibility have been removed
in v2.
CO-5.2.104 Communication TA.6 Information Control intent has changed to focus
Requirements Security exclusively on responsibilities of the
Communications Entity in developing its Information
Security-related communications
approach. The v1 Control Standard
focused on collaboration between
ADSIC and the Entity in this area.
CO-5.2.204 Communication N/A N/A All Control Standards for
Facilitation which ADSIC had the primary
responsibility have been removed
in v2.
PM-6.1.101 Pan-Governmental N/A N/A All Control Standards for
Strategic Metrics which ADSIC had the primary
and Tools responsibility have been removed
in v2.
PM-6.1.201 Strategic N/A N/A All Control Standards for
Performance which ADSIC had the primary
Monitoring responsibility have been removed
in v2.
PM-6.1.301 Strategic N/A N/A All Control Standards for
Performance which ADSIC had the primary
Analysis and responsibility have been removed
Reporting in v2.
PM-6.2.104 Entity SG.9 Information All Control Standards for
Programme Security which ADSIC had the primary
Metrics and Tools Performance responsibility have been removed
Management in v2.
333
ID Name ID Name
PM-6.2.203 Entity Programme SG.9 Information Specificity has been provided
Performance Security on the process of collecting and
Monitoring Performance managing performance data by
Management Entities.
PM-6.2.304 Entity Programme SG.9 Information All Control Standards for
Performance Security which ADSIC had the primary
Analysis and Performance responsibility have been
Reporting Management removed in v2.
PM-6.3.102 Audit Measures SG.10 Information v1 Control Standard had an
and Tools Security Audit orientation towards ADAA
Framework responsibilities. v2 provides
definitions of the planning
and competency expectations
applicable in relation to Entity’s
own security audit practices.
PM-6.3.202 Audit Execution SG.10 Information v1 Control Standard had an
Security Audit orientation towards ADAA
PM-6.3.302 Audit Analysis and SG.10 Information v1 Control Standard had an
Reporting Security Audit orientation towards ADAA
AM-7.1.103 Inventory of AM.1 Inventory of More specificity in the v2 Control
Information Information Standard as to what inventory
Assets Assets records should contain and how
it should be managed.
AM-7.1.203 Ownership of AM.2 Information Asset No substantial change in control
Information Ownership intent.
Assets
AM-7.1.303 Acceptable Use HR.3 Terms and No substantial change in the
Policy Conditions of control intent.
Employment
AM-7.2.103 Classification of AM.3 Classification Change in the definition of
Information of Information classification levels to make them
Assets more practically applicable.
Change in the name of
Classification “For Official Use
Only” in v1 to “Restricted” in v2.
AM-7.2.203 Information AM.4 Information More specify provided on how
Labelling and Labelling and assets should be labelled and
Handling Handling handled e.g. via the application
of multi-part labels.
HR-8.1.103 Roles and HR.1 Information No substantial change in the
Responsibilities Security control intent.
Roles and
Responsibilities

ID Name ID Name
HR-8.1.203 Pre-Employment HR.2 Security No substantial change in the
Screening Screening control intent.
HR-8.1.303 Terms and HR.3 Terms and Control intent extended to address
Conditions of Conditions of need for different terms and
Employment Employment conditions, based upon roles
and responsibilities.
HR-8.2.103 Management HR.1 Information Control intent subsumed into a
Roles and Security single Roles and Responsibilities
Responsibilities Roles and Control Standard (HR.1
Responsibilities Information Security Roles and
Responsibilities).
HR-8.2.203 Disciplinary HR.5 Disciplinary The v2 Control Standard gives
Process Process greater focus to the fair application
of the disciplinary process and
the learning of lessons from its
application.
HR-8.2.303 Screening During HR.2 Security No substantial change in the
Employment Screening control intent.
HR-8.3.103 Termination HR.6 End of More specificity is provided in
Responsibilities Employment the v2 Control Standard on the
Security activities required at the end of the
employment period.
HR-8.3.203 Return of Assets HR.6 End of More specificity is provided in
Employment the v2 Control Standard on the
employment period.
HR-8.3.303 Removal of HR.6 End of More specificity is provided in
Access Rights Employment the v2 Control Standard on the
employment period.
PE-9.1.103 Physical Security PE.2 Common Physical Physical and Environmental Control
Perimeter & Environmental Standards have been reengineered
Security Controls in v2 in recognition that different
types of control will need to be
applied in different environments.
Three principle divisions have been
defined: i) Common Physical and
Environmental Controls (that apply
to all environments), ii) Workspaces
iii) Data Centres and iv) Archive and
Storage Facilities.
PE-9.1.203 Physical Entry PE.2 Common Physical Physical and Environmental Control
Controls & Environmental Standards have been reengineered
Storage Facilities.
335
ID Name ID Name
PE-9.1.303 Physical Security PE.2 Common Physical and Environmental Control
Monitoring Physical and Standards have been reengineered
Environmental in v2 in recognition that different
Security Controls types of control will need to be
Storage Facilities.
PE-9.1.403 Secure Offices, PE.2 Common Physical Physical and Environmental Control
Rooms, and & Environmental Standards have been reengineered
Facilities Security Controls in v2 in recognition that different
Storage Facilities.
PE-9.1.503 External and PE.2 Common Physical Physical and Environmental Control
Environmental & Environmental Standards have been reengineered
Threat Protection Security Controls in v2 in recognition that different
Storage Facilities.
PE-9.1.603 Working Area PE.3 Workspace Physical and Environmental Control
Security Security Standards have been reengineered
in v2 in recognition that different
Storage Facilities.
PE-9.1.703 Public Access, PE.2 Common Physical Physical and Environmental Control
Delivery, and & Environmental Standards have been reengineered
Loading Areas Security Controls in v2 in recognition that different
Security types of control will need to be
Storage Facilities.

ID Name ID Name
PE-9.2.103 Equipment PE.2 Common Physical Physical and Environmental Control
Placement and & Environmental Standards have been reengineered
Protection Security Controls in v2 in recognition that different
Storage Facilities.
PE-9.2.203 Supporting PE.2 Common Physical Physical and Environmental Control
Utilities & Environmental Standards have been reengineered
Storage Facilities.
PE-9.2.303 Cabling Security N/A N/A Control intent is addressed within
Physical and Environmental Control
Standards
PE-9.2.403 Equipment OM.21 Secure Systems Control intent retained but more
Maintenance Maintenance detail added to the v2 Control
Standard.
PE-9.2.503 Off-Premise PE.2 Common Physical Physical and Environmental Control
Equipment & Environmental Standards have been reengineered
Security Security Controls in v2 in recognition that different
Storage Facilities.
PE-9.2.603 Secure Disposal OM.22 Secure Disposal Information regarding specific
and Re-Use of and Re-use of methods for secure disposal have
Equipment Equipment been included in the v2 Control
Standard.
PE-9.2.703 Removal of PE.2 Common Physical and Environmental Control
Property Physical and Standards have been reengineered
Environmental in v2 in recognition that different
Security Controls types of control will need to be
Storage Facilities.
337
ID Name ID Name
CM-10.1.103 Operating OM.1 Operational v2 Control Standard has been
Procedures Procedures and made more specific and expanded
Responsibilities to encompass control definition
applicable to operational
responsibilities.
CM-10.1.103 Operating OM.1 Operational No substantial change in control
Procedures Procedures and intent. More specific information
Responsibilities provided on the development and
management of procedures.
CM-10.1.203 Change OM.2 Operational v2 Control Standard has been
Management Change and made more specific and
Configuration practitioner-oriented.
Management
CM-10.1.303 Segregation of HR.4 Segregation of The v2 Control Standard requires
Duties Duties Entities to weigh the benefits vs.
disbenefits of duty segregation,
in a specific context.
CM-10.1.403 Separation of OM.3 Management of v2 Control Standard provides
Development, Development, specificity on example
Test, and Test and mechanisms for segregation
Operational Production of the environments.
Facilities Facilities
CM-10.2.103 Service Delivery TP.3 Security New Control Standard – v1 had a
Monitoring and narrow perspective on third-party
Review of Third supplier security, looked at only in
Party Services the context of information system
acquisition. V2 provides an end-
to-end lifecycle orientation to the
secure engagement, management
and release of products and services
from third-party suppliers.
CM-10.2.203 Monitoring and TP.3 Security New Control Standard – v1 had a
Review of Third Monitoring and narrow perspective on third-party
Party Services Review of Third supplier security, looked at only
Party Services in the the context of information
system acquisition. V2 provides
an end-to-end lifecycle orientation
to the secure engagement,
management and release of
products and services from third-
party suppliers.
CM-10.3.103 Capacity IS.2 Security Design Capacity Management have been
Management subsumed into Security Design.
CM-10.3.203 Information OM.4 Commissioning v2 Control Standard focused on the
System of Information process of commissioning, rather
Acceptance Systems and than just acceptance.
Networks

ID Name ID Name
CM-10.4.103 Malicious Code OM.6 Anti-Malware Greater detail and specificity
Protection Protection provided in the v2 Control
Standard.
CM-10.4.203 Mobile Code IS.7 Mobile Code No substantial change in control
Protection Protection intent.
CM-10.5.103 Information OM.8 Information More specificity provided in v2
Backup Backup and Control Standards on backup and
Restoration restoration.
CM-10.6.103 Network Controls IS.11 Routing, Switching More specific details provided on
and Network network security controls.
Patching Security
CM-10.6.203 Security of IS.11 Routing, Switching More specific details provided on
Network Services and Network network security controls.
Patching Security
CM-10.7.103 Management of OM.16 Management of v2 Control Standard provides
Removable Media Removable Digital more specificity on the secure
Media management of removable media.
CM-10.7.203 Disposal of Media OM.16 Management of v2 Control Standard provides
Removable Digital more specificity on the secure
Media management of media disposal.
CM-10.7.303 Information OM.16 Management of No substantial change in the
Handling Removable Digital control intent.
Procedures Media
CM-10.7.403 Security of AM.3 Classification of v2 Control Standard provides
Information Information Assets more specificity on the secure
System management of information
Documentation system documentation.
CM-10.8.103 Information SG.6 Framework for Control intent has been subsumed
Exchange Policies Information into the SG.6 Control Standard.
and Procedures Exchange
Agreements
CM-10.8.203 Exchange SG.6 Framework for More specificity on the expected
Agreements Information content of exchange agreements
Exchange has been provided in v2.
Agreements
CM-10.8.303 Physical Media in OM.19 Physical Media in v2 control extends the scope of
Transit Transit and Off-Site control intent, to cover off-site
Storage storage, as well as protecting
media in transit.
CM-10.8.403 Electronic OM.14 Electronic Mail v2 Control Standard provides
Messaging Security greater specificity on the secure
management of electronic mail.
CM-10.8.503 Business N/A N/A v1 Control Standards have been
Information retired due to the lack of specify.
Systems
CM-10.9.103 Electronic N/A N/A v1 Control Standards have been
Commerce retired due to the lack of specify.
CM-10.9.203 Online N/A N/A v1 Control Standards have been
Transactions retired due to the lack of specify.
339
ID Name ID Name
CM-10.9.303 Publicly Available N/A N/A v1 Control Standards have been
Information retired due to the lack of specify.
CM-10.10.103 Monitoring Policy OM.5 Monitoring of Control Intent is addressed within
and Procedures Information OM.5 Monitoring of Information
System and System and Network Performance
Network and Usage.
Performance
and Usage
CM-10.10.203 Audit Logging OM.20 Information The v2 Control Standard is
System and intended to give a broader and
Network Log more integrated of view of log
Management management and analysis, in
and Analysis comparison the multi Control
Standard approach evident in v1.
CM-10.10.303 Monitoring OM.20 Information The v2 Control Standard is
System Use System and intended to give a broader and
CM-10.10.403 Protection of Log OM.20 Information The v2 Control Standard is
Information System and intended to give a broader and
CM-10.10.503 Logging of OM.20 Information The v2 Control Standard is
Administrator System and intended to give a broader and
and Operator Use Network Log more integrated of view of log
CM-10.10.603 Fault Logging OM.20 Information The v2 Control Standard is
System and intended to give a broader and
CM-10.10.703 Clock OM.20 Information The v2 Control Standard is
Synchronisation System and intended to give a broader and
IA-11.1.103 Access Control IA.4 Privilege Control Intent is addressed with
Policy and Access in IA.4 Privilege and Access
IA-11.2.103 User Account IA.2 Account v2 Control Standard has a closer
Management Management focus on account management,
with matters relating to access
rights and privileges being dealt
with within Control Standard IA.3.
IA-11.2.203 User Privilege IA.4 Privilege User Privilege Management have
Management and Access been subsumed into privilege and
Management access management.

ID Name ID Name
IA-11.2.303 User Password IA.2 Account Control Intent is addressed with
Management Management in IA.4 Privilege and Access
Management
IA-11.2.403 Review of User IA.4 Privilege Review of User Access Rights have
Access Rights and Access been subsumed into privilege and
IA-11.3.103 Password Use IA.3 Information Control Intent is addressed
Policy System with in IA.3 Information System
Authentication Authentication
IA-11.3.203 Unattended User PE.3 Workspace Physical and Environmental Control
Equipment Security Standards have been reengineered
Storage Facilities.
IA-11.3.303 Clear Desk/Clear PE.3 Workspace Physical and Environmental Control
Screen Policy Security Standards have been reengineered
Storage Facilities.
IA-11.4.103 Authorised Use of IA.4 Privilege Control Intent is addressed with
Network Services and Access in IA.4 Privilege and Access
IA-11.4.203 User IA.5 Remote Access Focus of v2 Control Standard
Authentication expanded to the management
for External of remote access, not simply
Connections the authentication of external
connections.
IA-11.4.303 Equipment OM.15 Detection of v2 Control Standard has a broader
Identification in Authorised and focus than its v1 counterpart,
Networks Unauthorised seeking to address all unauthorised
Equipment connections, rather than just those
via remote access.
IA-11.4.403 Remote OM.12 Network The v2 Control Standard provides a
Diagnostic and Port, Protocol sharper focus on port protection, in
Configuration and Service comparison to the hybrid content
Port Protection Protection of the v1 Control Standard.
IA-11.4.503 Segregation in IS.10 Network More specificity on Network
Networks Segregation Segregation has been provided
in v2.
341
ID Name ID Name
IA-11.4.603 Network IS.10 Network The control intent expressed in
Connection Segregation the v1 Control Standard has been
Control rendered into more modular and
tangible form in v2.
IA-11.4.703 Network Routing IS.11 Routing, Switching More specificity on Routing &
Control and Network Switching Security has been
Patching Security provided in v2.
IA-11.5.103 Secure Logon IA.2 Account The control intent expressed in
Procedures Management the v1 Control Standard has been
rendered into more modular and
IA-11.5.203 User IA.1 Identity V2 Control Standard has been
Identification and Management rewritten for clarity and to provide
Authentication additional control definition.
IA-11.5.303 Password IA.3 Information Password management provisions
Management System have been subsumed into
System Authentication Information system authentication.
IA-11.5.403 Use of System OM.13 Secure Software Scope of the V2 Control Standard
Utilities Management broadened, in comparison to its
v1 counterpart. The original
Control Standard had a focus just
on information system utilities.
In contrast, the v2 Control Standard
seeks to address the secure
management of multiple
software types.
IA-11.5.503 Connection/ IA.7 Connection v2 Control Standard provides
Session Time Management specificity on areas of expected
Restrictions coverage within connection
agreements.
IA-11.5.603 Limitation on IA.7 Connection v2 Control Standard provides
Concurrent Management specificity on areas of expected
Sessions coverage within connection
agreements.
IA-11.6.103 Information IA.4 Privilege Access restrictions have been
Access and Access subsumed into privilege and access
Restrictions Management management.
IA-11.7.103 Mobile IS.12 Wireless Network v2 Control Standard focused to
Computing and Security wireless security and requirements
Telecommunications made more tangible.
IA-11.7.203 Telecommuting IA.5 Remote Access The control intent expressed in
the v1 Control Standard has been
IS-12.1.103 Security IS.1 Security The v2 Control Standard has been
Requirements Requirements focused to specifically address
Analysis and of Information control expectations applicable
Specification Systems to Requirements Management.
IS-12.1.201 Configuration IS.3 Information v1 Control Standard expressed
Settings System and the expectation of ADSIC defining
Guidelines Network Device configuration guidelines. Change
Hardening of control intent in v2 toward
Entities taking the necessary
initiative to harden their own

ID Name ID Name
IS-12.1.303 Secure IS.3 Information The control intent expressed in
Configuration System & the v1 Control Standard has been
Settings Network Device rendered into more modular and
Hardening tangible form in v2.
IS-12.2.103 Input Data IS.2 Security Design Input Data Validation have been
Validation subsumed into Security Design.
IS-12.2.203 Control of Internal IS.2 Security Design Control of Internal Processing
Processing have been subsumed into Security
Design.
IS-12.2.303 Message Integrity IS.2 Security Design Message Integrity have been
subsumed into Security Design.
IS-12.2.403 Output Data IS.2 Security Design Output Data Validation have been
Validation subsumed into Security Design.
IS-12.3.103 Cryptographic IS.5 Cryptographic Change of control focus in v2
Controls Policy Controls away from the v1 expectation of
a Cryptographic Controls policy.
Instead, attention is given to
IS-12.4.103 Control of OM.1 Operational The control intent expressed in
Operational Procedures & the v1 Control Standard has been
Software Responsibilities rendered into more modular and
IS-12.4.203 Protection of IS.15 Protection of V2 Control Standard has been given
System Test Data Information a tighter focus on protection of test
System Test Data date, with access control related
matters being addressed in Control
Standard IS.9.
IS-12.4.303 Source Code IS.4 Source Code No substantial change in control
IS-12.5.103 Change Control OM.2 Operational The control intent expressed in
Procedures Change & the v1 Control Standard has been
Configuration rendered into more modular and
Management tangible form in v2.
IS-12.5.203 Technical Review OM.2 Operational The control intent expressed in
of Applications Change & the v1 Control Standard has been
After Operating Configuration rendered into more modular and
System Changes Management tangible form in v2.
IS-12.5.303 Restrictions OM.2 Operational The control intent expressed in
on Changes Change & the v1 Control Standard has been
to Software Configuration rendered into more modular and
Packages Management tangible form in v2.
IS-12.5.403 Information IS.6 Information No substantial change in control
Leakage Leakage intent.
Prevention
IS-12.5.503 Outsourced TP.2 Security-Oriented New Control Standard – v1 had a
Software Contract narrow perspective on third-party
Development Definition supplier security, looked at only in
the context of information system
and release of products and
services from third-party suppliers.
343
ID Name ID Name
IM-13.1.104 Reporting IM.5 Reporting The v1 Control Standard was
Information Information oriented toward the Entity
Security Events Security reporting incident events to
Weaknesses ADSIC. The v2 Control Standard is
and Events oriented toward users reporting the
attributes of actual and potential
incidents to the Entity.
IM-13.1.203 Reporting IM.5 Reporting No substantial change in control
Information Information intent.
Security Security
Weaknesses Weaknesses and
Events
IM-13.2.104 Responsibilities IM.2 Information More specificity is provided in the
and Procedures Security Incident v2 Control Standard regarding the
Management type of Incident Management roles
Roles and that need to be considered by the
Responsibilities Entity.
IM-13.2.104 Responsibilities IM.3 Information New Control Standard – The v2
and Procedures Security Incident Control Standard has a much
Management broader scope, addressing multiple
Planning dimensions of planning the Entity’s
Information Security Incident
Management capabilities, beyond
just the production of procedures.
IM-13.2.203 Contact with TA.5 Contact With Control Standard moved from
Special Interest Special Interest the ‘Information Security Incident
Groups Groups Management’ section in v1 to the
‘Awareness and Training section
of v2. This reflects the need for
Entities to engage with external
interests groups for areas of shared
interest beyond just incident
management.
IM-13.2.303 Learn from IM.8 Post-Incident The v2 Control Standard provides
Information Analysis, specificity regarding the type
Security Incidents Reporting and of incident data that should be
Corrective Action captured and reported upon.
IM-13.2.303 Learn from IM.8 Post-Incident The v2 Control Standard provides
Information Analysis, specificity regarding the type
Security Incidents Reporting and of incident data that should be
Corrective Action captured and reported upon.
IM-13.2.403 Evidence IM.7 Management of The v1 Control Standard provided
Collection Security Evidence a general statement regarding the
need for evidence collection and
retention. The v2 Control Standard
provides more specific and
detailed information on Evidence
Management.

ID Name ID Name
BC-14.1.103 Information IC.1 Information The control intent expressed in
Security in Systems the v1 Control Standard has been
Business Continuity rendered into more modular
Continuity Planning focusing on the information system
Framework continuity and tangible form in v2.
BC-14.1.203 Business IC.3 Information The v2 Control Standard
Continuity Systems provides specificity regarding
Planning and Risk Continuity Plan the information expected to be
Assessment confirmed within a continuity plan.
BC-14.1.303 Business IC.3 Information The v2 Control Standard
Continuity Plans Systems provides specificity regarding
Continuity Plan the information expected to be
confirmed within a continuity plan.
BC-14.1.403 Business IC.1 Information Continuity Management in v2 has
Continuity Systems been re-scoped from Business
Planning Continuity Continuity Management to
Framework Planning Information Security Continuity
Framework Management.
BC-14.1.503 Testing and IC.4 Testing of The v2 Control Standard provides
Re-assessing Information specificity regarding a) the type of
Business System testing that may be conducted and
Continuity Continuity Plans b) the key questions that testing
Planning should seek to provide answers to.
345
Appendix E

V2 to V1 Standards Mapping
Note: where it is indicated below that there has been no change of control intent from v1 to v2, this should not be
taken to mean that there has been no change in the wording of specific clauses. Abu Dhabi Government Entities
should take the opportunity to review all elements of the v2 Control Standards. Due to changes made to v1 Control
Standards and the addition of new Controls Standards in v2, an Entity compliant with v1 Control Standards should
not assume compliance with the v2 counterparts.
ID Name ID Name
SG.1 Information N/A N/A New Control Standard - This version
Security of the Standards gives greater
Programme attention to the Entity having
Management a programmatic structure for
SG.2 Information SP-1.3.103 Security Control focus in v2 is toward
Security Categorisation reviewing the supporting guide for
Categorisation full details on Categorisation.
SG.3 Information SP-1.2.303 Chief Further elaboration of the security
Security Information organisation beyond the Chief
Organisation Security Officer Information Security Officer is
provided in v2.
SG.4 Security N/A N/A v1 controls relating to change
Programme management had an exclusive
Change focus on operational change. This
Management control is concerned with changes
to Entity’s Information Security
Programme.
SG.5 Legal and SP-1.3.303 Legal No substantial change in the control
Regulatory Requirements intent.
Requirements
SG.6 Framework for CM-10.8.203 Exchange More specificity on the expected
Information Agreements content of exchange agreements
Exchange has been provided in v2.
Agreements
SG.6 Framework for CM-10.8.103 Information Control intent has been subsumed
Information Exchange into the SG.6 Control Standard.
Exchange Policies and
Agreements Procedures
SG.7 Enterprise N/A N/A New Control Standard - This version
Architecture of the Standards expresses the need
to integrate Information Security
with the Enterprise Architecture,
where the latter is active within
the Entity.
SG.8 Information PS-2.1.203 Entity More detail has been provided in v2
Security Policy Information on areas of expected content in the
Security Policy policy.
SG.9 Information PM-6.2.104 Entity All Control Standards for
Security Programme which ADSIC had the primary
Performance Metrics and responsibility have been removed
Management Tools in v2.
347
ID Name ID Name
SG.9 Information PM-6.2.203 Entity Specificity has been provided on the
Security Programme process of collecting and managing
Performance Performance performance data by Entities.
Management Monitoring
SG.9 Information PM-6.2.304 Entity All Control Standards for
Security Programme which ADSIC had the primary
Performance Performance responsibility have been removed
Management Analysis and in v2.
Reporting
SG.10 Information PM-6.3.102 Audit Measures v1 Control Standard had an
Security Audit and Tools orientation towards ADAA
definitions of the planning and
competency expectations applicable
in relation to Entity’s own security
audit practices.
SG.10 Information PM-6.3.202 Audit Execution v1 Control Standard had an
Security Audit orientation towards ADAA
audit practices.
SG.10 Information PM-6.3.302 Audit Analysis v1 Control Standard had an
Security Audit and Reporting orientation towards ADAA
audit practices.
SG.11 Common Control N/A N/A New Control Standard – v2 requires
Catalogue Entities to identify and manage
controls that applies to multiple
information systems, in a holistic
way.
RM.1 Risk Management N/A N/A New Control Standard – A life cycle
Planning orientation has been given to the
Risk Management section of v2. This
Control Standard recognises the
need for planning at the outset of
the Risk Management process.
RM.2 Risk Identification N/A N/A New Control Standard – A life cycle
orientation has been given to the
Risk Management section of v2.
In v1 Risk Identification was not
sufficiently delineated from Risk
Assessment.
RM.3 Risk Analysis RM-3.1.103 Risk Assessment v2 provides more direction on the
attributes of risk analysis that needs
to be considered.
RM.4 Risk Response RM-3.1.203 Risk Treatments v2 distinguishes been providing a
and Treatment response to a risk and treating it.
Not all risks will require treatment
(e.g. those that are knowingly
accepted).

ID Name ID Name
RM.5 Risk Monitoring RM-3.4.103 On-going Renamed but no substantial change
and Corrective Monitoring in control intent.
Action
HR.1 Information HR-8.1.103 Roles and No substantial change in the control
Security Roles and Responsibilities intent.
Responsibilities
HR.1 Information HR-8.2.103 Management Control intent subsumed into a
Security Roles and Roles and single Roles and Responsibilities
Responsibilities Responsibilities Control Standard (HR.1 Information
Security Roles and Responsibilities).
HR.2 Security Screening HR-8.1.203 Pre-Employment Control intent extended to address
Screening the potential need for re-screening
during the period of employment.
HR.2 Security Screening HR-8.2.303 Screening No substantial change in the control
During intent.
Employment
HR.3 Terms and HR-8.1.303 Terms and Control intent extended to address
Conditions of Conditions of need for different terms and
Employment Employment conditions, based upon roles
and responsibilities.
HR.3 Terms and AM-7.1.303 Acceptable Use No substantial change in the control
Conditions of Policy intent.
Employment
HR.4 Segregation of CM-10.1.303 Segregation of The v2 Control Standard requires
Duties Duties Entities to weigh the benefits vs.
disbenefits of duty segregation, in a
specific context.
HR.5 Disciplinary HR-8.2.203 Disciplinary The v2 Control Standard gives
Process Process greater focus to the fair application
of the disciplinary process and
the learning of lessons from its
application.
HR.6 End of HR-8.3.103 Termination More specificity is provided in
Employment Responsibilities the v2 Control Standard on the
employment period.
HR.6 End of HR-8.3.203 Return of Assets More specificity is provided in
Employment the v2 Control Standard on the
employment period.
HR.6 End of HR-8.3.303 Removal of More specificity is provided in
Employment Access Rights the v2 Control Standard on the
employment period.
TP.1 Security-Oriented N/A N/A New Control Standard – v1 had a
Supplier Selection narrow perspective on third-party
supplier security, looked at only in
349
ID Name ID Name
TP.2 Security-Oriented IS-12.5.503 Outsourced New Control Standard – v1 had a
Contract Definition Software narrow perspective on third-party
Development supplier security, looked at only in
TP.3 Security CM-10.2.103 Service Delivery New Control Standard – v1 had a
Monitoring and narrow perspective on third-party
Review of Third supplier security, looked at only in
TP.3 Security CM-10.2.203 Monitoring and New Control Standard – v1 had a
Monitoring and Review of Third narrow perspective on third-party
Review of Third Party Services supplier security, looked at only in
TP.4 Security-Oriented N/A N/A New Control Standard – v1 had a
Contract narrow perspective on third-party
Termination supplier security, looked at only in
and Renegotiation the context of information system
TA.1 Security Induction N/A N/A New Control Standard – a
requirement for information users
to be inducted into the Information
Security process at the start of their
engagement with the Entity was not
a feature of the v1 ‘Awareness and
Training’ section.
TA.2 General Awareness AT-4.1.104 General No substantial change in the
Message Delivery Awareness control intent.
Message
Delivery
TA.3 Tailored Awareness AT-4.1.203 Tailored Control intent modified from
Security Training Awareness tailored awareness delivery based
Messages upon information system/service,
to tailored delivery based on
responsibilities.
TA.3 Tailored Awareness CO-5.1.104 Tailored Change of focus from shared ADSIC/
Security Training Information for Entity responsibility to Entity only.
Stakeholders

ID Name ID Name
TA.4 Security Training AT-4.2.103 Security Training Development and Delivery-
Development and Training related clauses have been combined
Delivery Curriculum into a unified v2 Control Standard.
A broader scoping has been
provided for planning and
TA.4 Security Training AT-4.2.203 Security Training Development and Delivery-
Development and Training related clauses have been combined
Delivery Delivery into a unified v2 Control Standard.
A broader scoping has been
provided for planning and
TA.4 Security Training AT-4.2.303 Security Requirements for training record
Development and Training keeping subsumed into a broader
Delivery Records scoped control relating to the full
Information Security Development
and Delivery lifecycle.
TA.5 Contact With IM-13.2.203 Contact with Control Standard moved from
Special Interest Special Interest the ‘Information Security Incident
Groups Groups Management’ section in v1 to the
‘Awareness and Training section
of v2. This reflects the need for
Entities to engage with external
interests groups for areas of shared
interest beyond just incident
management.
TA.6 Information CO-5.2.104 Communication Control intent has changed to focus
Security Requirements exclusively on responsibilities of the
Communications Entity in developing its Information
Security-related communications
approach. The v1 Control Standard
focused on collaboration between
ADSIC and the Entity in this area.
AM.1 Inventory of AM-7.1.103 Inventory of More specificity in the v2 Control
Information Assets Information Standard as to what inventory
Assets records should contain and how it
should be managed.
AM.2 Information Asset AM-7.1.203 Ownership of No substantial change in control
Ownership Information intent.
Assets
AM.3 Classification of AM-7.2.103 Classification of Change in the definition of
Information Assets Information classification levels to make them
more practically applicable.
Change in the name of Classification

“For Official Use Only” in v1 to
“Restricted” in v2.
AM.3 Classification of CM-10.7.403 Security of v2 Control Standard provides
Information Assets Information more specificity on the secure
System management of information system
Documentation documentation.
351
ID Name ID Name
AM.4 Information AM-7.2.203 Information More specify provided on how
Labelling and Labelling and assets should be labelled and
Handling Handling handled e.g. via the application
of multi-part labels.
AM.5 Information N/A N/A Retention and information lifecycle
Management management not addressed in a
and Retention specific v1 control.
AM.6 Physical Asset N/A N/A New Control Standard – v2 provides
Management delineation between the inventory
management of information assets
(AM.1) and the same for physical
assets (AM.6).
PE.1 Physical and N/A N/A New Control Standard – the need to
Environmental plan for the deployment of physical
Security Planning and environmental controls was not
included in v1.
PE.2 Common Physical PE-9.2.203 Supporting Physical and Environmental Control
and Environmental Utilities Standards have been reengineered
Storage Facilities.
PE.2 Common Physical PE-9.1.303 Physical Physical and Environmental Control
and Environmental Security Standards have been reengineered
Security Controls Monitoring in v2 in recognition that different
Storage Facilities.
PE.2 Common Physical PE-9.2.503 Off-Premise Physical and Environmental Control
and Environmental Equipment Standards have been reengineered
Security Controls Security in v2 in recognition that different
Storage Facilities.

ID Name ID Name
PE.2 Common Physical PE-9.1.103 Physical Physical and Environmental Control
and Environmental Security Standards have been reengineered
Security Controls Perimeter in v2 in recognition that different
Storage Facilities.
PE.2 Common Physical PE-9.1.203 Physical Entry Physical and Environmental Control
and Environmental Controls Standards have been reengineered
Storage Facilities.
PE.2 Common Physical PE-9.1.403 Secure Offices, Physical and Environmental Control
and Environmental Rooms, and Standards have been reengineered
Security Controls Facilities in v2 in recognition that different
Storage Facilities.
PE.2 Common Physical PE-9.1.503 External and Physical and Environmental Control
and Environmental Environmental Standards have been reengineered
Security Controls Threat in v2 in recognition that different
Protection types of control will need to be
Storage Facilities.
PE.2 Common Physical PE-9.1.703 Public Access, Physical and Environmental Control
and Environmental Delivery, and Standards have been reengineered
Security Controls Loading Areas in v2 in recognition that different
Security types of control will need to be
Storage Facilities.
353
Control Control Name Control Control Between the Versions
ID ID Name
PE.2 Common Physical PE-9.2.103 Equipment Physical and Environmental Control
and Environmental Placement and Standards have been reengineered
Security Controls Protection in v2 in recognition that different
Storage Facilities.
PE.2 Common Physical PE-9.2.703 Removal of Physical and Environmental Control
and Environmental Property Standards have been reengineered
Storage Facilities.
PE.3 Workspace IA-11.3.203 Unattended Physical and Environmental Control
Security User Equipment Standards have been reengineered
Storage Facilities.
PE.3 Workspace IA-11.3.303 Clear Desk/Clear Physical and Environmental Control
Security Screen Policy Standards have been reengineered
Storage Facilities.
PE.3 Workspace PE-9.1.603 Working Area Physical and Environmental Control
Security Security Standards have been reengineered
Storage Facilities.

ID Name ID Name
PE.4 Data Centre N/A N/A Physical and Environmental Control
Security Standards have been reengineered
Storage Facilities.
PE.5 Archive and N/A N/A Physical and Environmental Control
Storage Facility Standards have been reengineered
Security in v2 in recognition that different
Storage Facilities.
IS.1 Security IS-12.1.103 Security The v2 Control Standard has been
Requirements Requirements focused to specifically address
of Information Analysis and control expectations applicable to
Systems Specification Requirements Management.
IS.1 Security SP-1.3.403 Information The primary focus of the v1
Requirements Security Plan control i.e. requirements capture
of Information is addressed in the IS.1 Control
Systems Standard of v2. However, elements
are also addressed in the IS.2
Control Standard.
IS.2 Information N/A N/A New Control Standard – v2
Security Design places an emphasis upon a
clear expression of Information
Security requirements (Control
Standard IS.1), complemented by a
structured design to address those
requirements (Control Standard
IS.2). The Information Security
Design replaces the v1 concept of
an ‘Information Security Plan’ as the
definitive reference for the security
controls applicable to a given
information system.
355
ID Name ID Name
IS.2 Information IS-12.2.103 Input Data Input Data Validation have been
Security Design Validation subsumed into Security Design.
IS.2 Information IS-12.2.203 Control Control of Internal Processing
Security Design of Internal have been subsumed into Security
Processing Design.
IS.2 Information IS-12.2.303 Message Message Integrity have been
Security Design Integrity subsumed into Security Design.
IS.2 Information IS-12.2.403 Output Data Output Data Validation have been
Security Design Validation subsumed into Security Design.
IS.2 Information CM-10.3.103 Capacity Capacity Management have been
Security Design Management subsumed into Security Design.
IS.3 System and IS-12.1.201 Configuration v1 Control Standard expressed
Network Device Settings the expectation of ADSIC defining
Hardening Guidelines configuration guidelines. Change of
control intent in v2 toward Entities
taking the necessary initiative
to harden their own information
systems.
IS.3 System and IS-12.1.303 Secure The control intent expressed in
Network Device Configuration the v1 Control Standard has been
Hardening Settings rendered into more modular and
IS.4 Source Code IS-12.4.303 Source Code No substantial change in control
IS.5 Cryptographic IS-12.3.103 Cryptographic Change of control focus in v2
Controls Controls Policy away from the v1 expectation of
a Cryptographic Controls policy.
Instead, attention is given to
IS.6 Information IS-12.5.403 Information No substantial change in control
Leakage Leakage intent.
Prevention
IS.7 Mobile Code CM-10.4.203 Mobile Code No substantial change in control
IS.8 Security Appliance N/A N/A New Control Standard – due to their
and Security profile of usage and sensitivity,
Software Design control expectations specific to
the implementation and testing of
security appliances and software
have been provided in v2.
IS.9 Management of N/A N/A New Control Standard – the
Development and attributes specific and different to
Test Access managing access during information
system development (as opposed
to on-going, production-status
access) were not addressed in a
clearly delineated control in v1.
IS.10 Network IA-11.4.603 Network The control intent expressed in
Segregation Connection the v1 Control Standard has been
Control rendered into more modular and

ID Name ID Name
IS.10 Network IA-11.4.503 Segregation in More specificity on Network
Segregation Networks Segregation has been provided in v2.
IS.11 Routing, Switching CM-10.6.103 Network More specific details provided
and Network Controls on network security controls.
Patching Security
IS.11 Routing, Switching CM-10.6.203 Security of More specific details provided on
and Network Network network security controls.
Patching Security Services
IS.11 Routing, Switching IA-11.4.703 Network More specificity on Routing &
and Network Routing Control Switching Security has been
Patching Security provided in v2.
IS.12 Wireless Network IA-11.7.103 Mobile v2 Control Standard focused to
Security Computing and wireless security and requirements
Telecommunications made more tangible.
IS.13 Information RM-3.2.104 Security Testing v2 Control Standard expanded
Systems and and Evaluation and made more tangible.
Network Security
Testing
IS.13 Information RM-3.3.104 Certification V2 Control Standard focuses
Systems and and on informed acceptance of an
Network Security Accreditation Information Security Test Plan as a
Testing precursor to information systems
authorisation by the designed
Entity-level Authorising Official.
IS.14 Domain Name N/A N/A New Control Standard – no v1
Service Security Control Standard addressed
securing the Entity’s DNS
infrastructure.
IS.15 Protection of IS-12.4.203 Protection of V2 Control Standard has been given
Information Information a tighter focus on protection of test
System Test Data System Test date, with access control related
Data matters being addressed in Control
Standard IS.9.
IA.1 Identity IA-11.5.203 User V2 Control Standard has been
Management Identification rewritten for clarity and to provide
and additional control definition.
Authentication
IA.2 Account IA-11.2.103 User Account v2 Control Standard has a closer
Management Management focus on account management, with
matters relating to access rights and
privileges being dealt with within
Control Standard IA.3.
IA.2 Account IA-11.2.303 User Password Control Intent is addressed with
Management Management in IA.4 Privilege and Access
Management
IA.2 Account IA-11.5.103 Secure Logon The control intent expressed in
Management Procedures the v1 Control Standard has been
357
ID Name ID Name
IA.3 System IA-11.5.303 Password Password management provisions
Authentication Management have been subsumed into
System information system authentication.
IA.3 System IA-11.3.103 Password Use Control Intent is addressed
Authentication Policy with in IA.3 Information System
Authentication
IA.4 Privilege IA-11.6.103 Information Access restrictions have been
and Access Access subsumed into privilege and access
Management Restrictions management.
IA.4 Privilege IA-11.1.103 Access Control Control Intent is addressed with
and Access Policy in IA.4 Privilege and Access
Management Management.
IA.4 Privilege IA-11.2.203 User Privilege User Privilege Management have
and Access Management been subsumed into privilege and
IA.4 Privilege IA-11.2.403 Review of User Review of User Access Rights have
and Access Access Rights been subsumed into privilege and
IA.4 Privilege IA-11.4.103 Authorised Use Control Intent is addressed with
and Access of Network in IA.4 Privilege and Access
Management Services Management.
IA.5 Remote Access IA-11.4.203 User Focus of v2 Control Standard
Authentication expanded to the management
for External of remote access, not simply
Connections the authentication of external
connections.
IA.5 Remote Access IA-11.7.203 Telecommuting The control intent expressed in
the v1 Control Standard has been
IA.6 Directory N/A N/A New Control Standard – the security
Management of directory services was not
addressed in v1.
IA.7 Connection IA-11.5.503 Connection/ v2 Control Standard provides
Management Session Time specificity on areas of expected
Restrictions coverage within connection
agreements.
IA.7 Connection IA-11.5.603 Limitation on v2 Control Standard provides
Management Concurrent specificity on areas of expected
Sessions coverage within connection
agreements.
OM.1 Operational CM-10.1.103 Operating v2 Control Standard has been
Procedures and Procedures made more specific and expanded
Responsibilities to encompass control definition
applicable to operational
responsibilities.
OM.1 Operational CM-10.1.103 Operating No substantial change in control
Procedures and Procedures intent. More specific information
Responsibilities provided on the development and
management of procedures.
OM.1 Operational IS-12.4.103 Control of The control intent expressed in
Procedures and Operational the v1 Control Standard has been
Responsibilities Software rendered into more modular and

ID Name ID Name
OM.2 Operational CM-10.1.203 Change v2 Control Standard has been made
Change and Management more specific and practitioner-
Configuration oriented.
Management
OM.2 Operational IS-12.5.103 Change Control The control intent expressed in
Change and Procedures the v1 Control Standard has been
Configuration rendered into more modular and
Management tangible form in v2.
OM.2 Operational IS-12.5.203 Technical Review The control intent expressed in
Change and of Applications the v1 Control Standard has been
Configuration After Operating rendered into more modular and
Management System Changes tangible form in v2.
OM.2 Operational IS-12.5.303 Restrictions The control intent expressed in
Change and on Changes the v1 Control Standard has been
Configuration to Software rendered into more modular and
Management Packages tangible form in v2.
OM.3 Management of CM-10.1.403 Separation of v2 Control Standard provides
Development, Test Development, specificity on example
and Production Test, and mechanisms for segregation
Facilities Operational of the environments.
Facilities
OM.4 Commissioning CM-10.3.203 Information v2 Control Standard focused on the
of Systems and System process of commissioning, rather
Networks Acceptance than just acceptance.
OM.5 Monitoring N/A N/A New Control Standard – In v1
of System operational monitoring was spread
and Network across multiple controls, rather
Performance and than there being a consolidated
Usage perspective on information system
and network monitoring.
OM.5 Monitoring CM-10.10.103 Monitoring Control Intent is addressed within
of System Policy and OM.5 Monitoring of System and
and Network Procedures Network Performance and Usage.
Performance and
Usage
OM.6 Anti-Malware CM-10.4.103 Malicious Code Greater detail and specificity
Protection Protection provided in the v2 Control
Standard.
OM.7 Technical N/A N/A New Control Standard – Patch
Vulnerability and management and vulnerability
Patch Management management were referenced in
passing in several v1 control areas
but no specific Control Standard
for these disciplines was provided
before v2.
OM.8 Information CM-10.5.103 Information More specificity provided in v2
Backup and Backup Control Standards on backup and
Restoration restoration.
OM.9 Network Boundary N/A N/A New Control Standard – no specific
Defence Control Standard provided in v1
application to boundary/perimeter
protection.
OM.10 Intrusion Detection N/A N/A New Control Standard – the
and Prevention terms “IDS” and “IPS” were given
definition in v1 but a specific
Control Standard applicable
to this area did not exist.
359
ID Name ID Name
OM.11 Information N/A N/A New Control Standard – Not
Extrusion addressed within a targeted control
Detection and in v1
Prevention
OM.12 Network Port, IA-11.4.403 Remote The v2 Control Standard provides a
Protocol and Diagnostic and sharper focus on port protection, in
Service Protection Configuration comparison to the hybrid content of
Port Protection the v1 Control Standard.
OM.13 Secure Software IA-11.5.403 Use of Scope of the V2 Control Standard
Management Information broadened, in comparison to its
System Utilities v1 counterpart. The original
Control Standard had a focus just
on information system utilities.
In contrast, the v2 Control
Standard seeks to address the
secure management of multiple
software types.
OM.14 Electronic Mail CM-10.8.403 Electronic v2 Control Standard provides
Security Messaging greater specificity on the secure
management of electronic mail.
OM.15 Detection of IA-11.4.303 Equipment v2 Control Standard has a broader
Authorised and Identification in focus than its v1 counterpart,
Unauthorised Networks seeking to address all unauthorised
Equipment connections, rather than just those
via remote access.
OM.16 Management of CM-10.7.103 Management v2 Control Standard provides
Removable Digital of Removable more specificity on the secure
Media Media management of removable media.
OM.16 Management of CM-10.7.203 Disposal of v2 Control Standard provides
Removable Digital Media more specificity on the secure
Media management of media disposal.
OM.16 Management of CM-10.7.303 Information No substantial change in the control
Removable Digital Handling intent.
Media Procedures
OM.17 Management of N/A N/A New Control Standard – References
Paper Media to the management of paper-based
information assets were spread
across multiple Control Standards
in v1.
OM.18 Technical N/A N/A New Control Standard – the
Configuration detection of deviations from a
Definition known good baseline and the
Enforcement automatic remediation of such
deviations did not have Control
Standard definition within v1.
OM.19 Physical Media in CM-10.8.303 Physical Media v2 control extends the scope of
Transit and Off-Site in Transit control intent, to cover off-site
Storage storage, as well as protecting
media in transit.

ID Name ID Name
OM.20 System and CM-10.10.203 Audit Logging The v2 Control Standard is
Network Log intended to give a broader and
Management more integrated of view of log
and Analysis management and analysis, in
comparison the multi Control
OM.20 System and CM- Protection of The v2 Control Standard is
Network Log 10.10.403 Log Information intended to give a broader and
Management more integrated of view of log
OM.20 System and CM-10.10.303 Monitoring The v2 Control Standard is
Network Log Information intended to give a broader and
Management System Use more integrated of view of log
OM.20 System and CM-10.10.503 Logging of The v2 Control Standard is
Network Log Administrator intended to give a broader and
Management and Operator more integrated of view of log
and Analysis Use management and analysis, in
OM.20 System and CM-10.10.703 Clock The v2 Control Standard is
Network Log Synchronisation intended to give a broader and
Management and more integrated of view of log
Analysis management and analysis, in
OM.20 System and CM- Fault Logging The v2 Control Standard is
Network Log 10.10.603 intended to give a broader and
Management and more integrated of view of log
Analysis management and analysis, in
OM.21 Secure Systems PE-9.2.403 Equipment Control intent retained but more
Maintenance Maintenance detail added to the v2 Control
Standard.
OM.22 Secure Disposal PE-9.2.603 Secure Disposal Information regarding specific
and Re-use of and Re-Use of methods for secure disposal have
Equipment Equipment been included in the v2 Control
Standard.
IM.1 Information N/A N/A New Control Standard – The full
Security Incident Incident Management lifecycle was
Modelling not addressed in v1. Modelling of
potential incidents before their
occurrence was not covered.
IM.2 Information IM-13.2.104 Responsibilities More specificity is provided in
Security Incident and Procedures the v2 Control Standard regarding
Management the type of Incident Management
Roles and roles that need to be considered
Responsibilities by the Entity.
361
ID Name ID Name
IM.3 Information IM-13.2.104 Responsibilities New Control Standard – The v2
Security Incident and Procedures Control Standard has a much
Management broader scope, addressing multiple
Planning dimensions of planning the Entity’s
Information Security Incident
Management capabilities, beyond
just the production of procedures.
IM.4 Information N/A N/A New Control Standard – the need for
Security Incident incident simulation as mechanism
Training and for response preparation and
Simulation learning was not included within v1.
IM.5 Reporting IM-13.1.104 Reporting The v1 Control Standard was
Information Information oriented toward the Entity reporting
Security Security Events incident events to ADSIC. The v2
Weaknesses Control Standard is oriented toward
and Events users reporting the attributes of
actual and potential incidents to
the Entity.
IM.5 Reporting IM-13.1.203 Reporting No substantial change in control
Information Information intent.
Security Security
Weaknesses Weaknesses
and Events
IM.6 Management of N/A N/A New Control Standard – a specific
Security Incident control relating to incident
Response management/handling was
not included within v1.
IM.7 Management of IM-13.2.403 Evidence The v1 Control Standard provided
Security Evidence Collection a genera statement regarding
the need for evidence collection
and retention. The v2 Control
Standard provides more specific and
detailed information on Evidence
Management.
IM.8 Post-Incident IM-13.2.303 Learn from The v2 Control Standard provides
Analysis, Reporting Information specificity regarding the type
and Corrective Security of incident data that should be
Action Incidents captured and reported upon.
IC.1 Information BC-14.1.403 Business Continuity Management in v2 has
Systems Continuity Continuity been re-scoped from Business
Planning Planning Continuity Management to
Framework Framework Information Security Continuity
Management.
IC.1 Information BC-14.1.103 Information The control intent expressed in
Systems Continuity Security in the v1 Control Standard has been
Planning Business rendered into more modular
Framework Continuity focusing on the information system
continuity and tangible form in v2.
IC.2 Information N/A N/A New Control Standard – The need
Systems Continuity to capture and analyse service
Requirements continuity requirements was not
overtly addressed within in v1.

ID Name ID Name
IC.3 Information BC-14.1.203 Business The v2 Control Standard provides
Systems Continuity Continuity specificity regarding the information
Plan Planning and expected to be confirmed within a
Risk Assessment continuity plan.
IC.3 Information BC-14.1.303 Business The v2 Control Standard provides
Systems Continuity Continuity Plans specificity regarding the information
Plan expected to be confirmed within a
continuity plan.
IC.4 Testing of System BC-14.1.503 Testing and The v2 Control Standard provides
Continuity Plans Re-assessing specificity regarding a) the type of
Business testing that may be conducted and
Continuity b) the key questions that testing
Planning should seek to provide answers to.
363

Adsic ND 133684 en PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Adsic ND 133684 en PDF

Caricato da

Copyright:

Formati disponibili

Information Security Standards

Abu Dhabi Government

Question and Comments should be directed to:

3 Information Security Framework 8

4 Compliance and Enforcement 13

5 Application of this Version 14

8 Implementation Priorities - When & How to Apply Controls 25

10 Common vs Tailored Security Controls 31

11 Alignment to International Standards 33

12 Abu Dhabi Information Security Standards 34

On-the-ground insights have been gained by Abu Dhabi Government Entities

1. Executive level ownership and oversight of Entity Information Security

3. Entity Information Security Programmes should be resourced in a manner, and

4. Information Owners should assume an informed position concerning the security

5. A holistic view of Information Security controls should be taken that reflects

2 Information Security Standards

7. Control Standards should be given a suggested prioritisation that recognises that

9. Emphasis should be given by Entities to ‘designing in’ security, rather than

The Control Standards contained within this document provide an expression of

Entities have the responsibility of understanding the Control Standards defined

4 Information Security Standards

The Abu Dhabi Information Security Standards document is supported by

Information Security Risk Management

Human Resources Third Party

Information Security Information Asset

Physical & Information Systems

Identity and Access Information Systems

Information Security Information Systems

Figure 1: Abu Dhabi Information Security Domains

The functional scope of this document extends beyond Information Technology,

Government Entities are required to use security controls to meet Information

Low The information system is categorised as LOW if the loss

6 Information Security Standards

High The information system is categorised as HIGH if the loss

The diagram below defines the key elements of such a framework.

Abu Dhabi Other Entity

Information Entity Enterprise Domain- Common

Design & Implementation Methodology

Risk Management - Change Management - Continuous Monitoring

Figure 2: Abu Dhabi Information Security Framework

8 Information Security Standards

1 Programme Abu Dhabi This document – it provides All

3 Programme Entity The Entity’s high-level plan SG.1

The Programme Plan should

5 Programme Entity The documented expression SG.8

The asset inventory confirms

10 Information Security Standards

9 Programme Domain- Depending on the size of the SG.1

The Enterprise Information

13 System System Entities are required to implement IS.3-IS.12

12 Information Security Standards

17 Ongoing Change With its potential to introduce SG.4/

4 Compliance and Enforcement

The Entity should maintain its own self-assessment capabilities to determine if

Information systems (including network devices) found to be non-compliant with

5 Application of this Version

Appendix D of this document provides a mapping of content from version 1 of the

14 Information Security Standards

6.1 Alignment with Related Government Standards

These Standards are intended to provide a coherent perspective on multiple

• Enterprise Risk Management

Absent government-wide Standards in any associated areas, then Entities may

6.2 Supporting Documents