Académique Documents
Professionnel Documents
Culture Documents
This document has been developed and is maintained by the Information Security
Programme of the Abu Dhabi Systems and Information Centre.
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
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
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.
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.
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.
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.
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.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
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.
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.
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.
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.
3 5 8 9 10
Entity
Activities
4 6
Key Information
Security Asset
Indicators Inventory
(System+Data)
System Level
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
9
Item Framework Component Description Primary
No. Level Related
Control
Standard(s)
11
Item Framework Component Description Primary
No. Level Related
Control
Standard(s)
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 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.
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.
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.
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:
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
17
Change Description
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.
Control Specification 7 8 L M H
XX.4.1 Control Specification Definition M M M
19
Key Change Description
An example being:
AM.1
This simply means that this is the first control in
the Information Asset Management section of
the Standards.
AM.1.2
Simply means that this is the second element
of Control Specification applicable to the AM.1
Control Standard.
21
Key Change Description
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
Key Change Description
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.
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.
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.
25
Suggested Priority (Cont.)
2) Deploying basic preventive controls to stop very common threats from being
manifested.
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.
• Whether the role of Chief Information Security Officer (CISO) should be full or
part time.
• 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.
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 Control Specification application is expanded upon in the table below.
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.
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.
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:
• Protection and enhancement of the reputation of Abu Dhabi, at home and abroad
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.
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.
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:
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.
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.
35
Control Specification L M H
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
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.
Control
Dependencies
References • NIST Special Publication 800-53 Revision 3:
o RA-2 Security Categorization
39
Control Specification L M H
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.
Control
Dependencies
References • NIST Special Publication 800-53 Revision 3:
o PM-1 Information Security Program Plan
o PM-2 Senior Information Security Officer
• Abu Dhabi Entity Information Security Roles &
Responsibilities
• Abu Dhabi Information Security Governance Guide
• Abu Dhabi Information Security Programme Plan Template
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
Information Security.
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.
45
Control Specification L M H
SG.6.4 • The intellectual property rights that will apply M M M
(Cont.) to the exchanged information.
47
Control Specification L M H
SG.7.2 The Enterprise Information Security Architecture M M M
should be approved by the Entity’s Information
Security Governance Committee.
49
Control Specification L M H
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.
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 Governance Guide
• Abu Dhabi Information Security Policy Template
51
SG.9 Information Security Performance Version 1.0
Management Suggested P1
Priority
Control The Entity shall develop, report against and analyse key
Standards performance indicators relating to its Information Security
programme.
53
Control Specification L M H
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
Control None
Dependencies
References • NIST Special Publication 800-53 Revision 3:
o PM-6 Information Security Measures Of Performance
• NIST Special Publication 800-55 Revision 1:
o Section 3.3 Type of Measures
• Abu Dhabi Information Security Programme Level Key
Performance Indicators
• Abu Dhabi Information Security Governance Guide
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.
57
Control Specification L M H
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.
Control None
Dependencies
References • NIST Special Publication 800-53 Revision 3:
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
• Abu Dhabi Information Security Governance Guide
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.
Control Type a Directive
q q Preventive q Detective q Corrective
Control Specification L M H
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).
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.
Control Type a Directive
q q Preventive q Detective q Corrective
Control Specification L M H
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.
63
Control Specification L M H
RM.1.3 • How risk management will be integrated M M M
(Cont.) within other Information Security disciplines
within the Entity.
65
Control Specification L M H
RM.1.7 • Compliance obligations M M M
(Cont.)
• Supporting technologies and infrastructure
• Supply chain configuration
• Service requirements
67
Control Specification L M H
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.
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
o RA-2 Security Categorization
• 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
Control Specification L M H
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.
71
Control Specification L M H
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
73
Control Version History
Control None
Dependencies
References • Abu Dhabi Information Security Risk Management Guide
75
Control Specification L M H
RM.3.4 Proximity – If the risk were to be manifested, when M M M
(Cont.) would this be likely to occur?
Control None
Dependencies
References • Abu Dhabi Information Security Risk Management Guide
• NIST Special Publication 800-37 ‘Guide for Applying the
Risk Management Framework to Federal Information
Systems’
• NIST Special Publication 800-53
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.
Control Type q Directive q Preventive
a q Detective
a q Corrective
Control Specification L M H
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:
79
Control Specification L M H
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?
Control None
Dependencies
References • Abu Dhabi Information Security Risk Management Guide
• NIST Special Publication 800-37 ‘Guide for Applying the
Risk Management Framework to Federal Information
Systems’
81
Control Specification L M H
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).
83
Control Specification L M H
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
References • Abu Dhabi Information Security Risk Management Guide
• NIST Special Publication 800-37 ‘Guide for Applying the
Risk Management Framework to Federal Information
Systems’
• NIST Special Publication 800-53
o RA-5 Vulnerability Scanning
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.
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 8.1 Prior to employment
o 8.1.2 Screening
• NIST Special Publication 800-53 Revision 3:
o PS-3 Personnel Screening
87
Control Specification L M H
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
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 8.1.3 Terms and conditions of employment
• NIST Special Publication 800-53 Revision 3:
o PL-4 Rules Of Behavior
89
Control Specification L M H
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
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 10.1.3 Segregation of duties
Control Specification L M H
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.
91
Control Version History
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 8.2.3 Disciplinary process
93
Control Specification L M H
HR.6.2 • The status of the items identified (i.e. return or M M M
(Cont) not returned)
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 8.3.1 Termination responsibilities
• NIST Special Publication 800-53 Revision 3:
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.
97
Control Specification L M H
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.
Control None
Dependencies
References • Abu Dhabi Information Security Third Party Supplier Guide
99
Control Specification L M H
TP.2.3 • Relationships with sub-contractors R R R
(Cont.)
• Technology
• Business culture
• Premises
Control None
Dependencies
References • Abu Dhabi Information Security Third Party Supplier Guide
101
Control Specification L M H
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.
Control None
Dependencies
References • Abu Dhabi Information Security Third Party Supplier Guide
Control None
Dependencies
References • Abu Dhabi Information Security Third Party Supplier Guide
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.
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
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.
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Information Security management systems —
Requirements:
o 5.2.2 Training, awareness and competence
• NIST Special Publication 800-53 Revision 3:
o AT-2 Security Awareness
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Information Security management systems —
Requirements:
o 5.2.2 Training, awareness and competence
• NIST Special Publication 800-53 Revision 3:
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
109
Control Specification L M H
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
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Information Security management systems —
Requirements:
o 6.1.7 Contact with special interest groups
• NIST Special Publication 800-53 Revision 3:
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
Control None
Dependencies
References • ISO 27002 Information technology — Security techniques
— Information Security management systems —
Requirements:
o 5.2.2 Training, awareness and competence
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.
Control Type a Directive
q q Preventive a Detective
q q Corrective
Control Specification L M H
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.
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
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
Control
Dependencies
References • ISO 27002 Information technology — Security techniques
— Information Security management systems —
Requirements:
o 7.1.2 Ownership of Assets
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
AM.3.1 All Abu Dhabi information assets must be M M M
classified based upon the sensitivity of their
potential disclosure.
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.
Secret
Information that requires substantial and multi-
level protection due to its highly sensitive nature.
119
Control Specification L M H
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.
121
Control Specification L M H
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.
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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)
125
Control Specification L M H
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.
127
Control Specification L M H
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.
129
Control Specification L M H
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)
Control
Dependencies
References • NIST Special Publication 800-53 Revision 3:
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.
Control Type q Directive
a q Preventive
a q Detective q Corrective
Control Specification L M H
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.
Control
Dependencies
References • NIST Special Publication 800-53 Revision 3:
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.
135
Control Specification L M H
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.
137
Control Specification L M H
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.
Control
Dependencies
References • ISO 27002 Information technology — Security techniques
— Code of practice for Information Security management:
o 11.3.3 Clear Desk and Clear Screen Policy
• NIST Special Publication 800-53 Revision 3:
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
141
Control Specification L M H
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.
Control
Dependencies
References • ISO 27002 Information technology — Security techniques
— Information Security management systems —
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
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
145
Control Version History
Control Specification L M H
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)
147
Control Specification L M H
IS.1.3 Information Security requirements should be M M M
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.
149
Control Specification L M H
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.
151
Control Specification L M H
IS.2.1 • What risks (including potential impact) would M M M
(Cont.) be manifested if the control were to fail or be
compromised.
153
Control Specification L M H
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.
155
Control Specification L M H
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.
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.
Control Type a Directive
q a Preventive
q q Detective q Corrective
Control Specification L M H
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.
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
IS.4.1 Program source libraries should not be stored in R M M
operational information systems.
Control
Dependencies
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.
Control Type a Directive
q a Preventive
q q Detective q Corrective
Control Specification L M H
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.
163
Control Specification L M H
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
165
Control Specification L M H
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 Version History
167
Control Specification L M H
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 Version History
Control
Dependencies
169
Control Specification L M H
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).
Control
Dependencies
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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).
173
Control Specification L M H
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.
175
Control Specification L M H
IS.11.5 • Disabling unused ports M M M
(Cont.)
• Disabling unnecessary message types received
on a network interface
177
Control Specification L M H
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.
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
• Abu Dhabi Information Security Design, Development and
Testing Guide
179
Control Specification L M H
IS.12.5 Workstations and mobile devices should be R R R
restricted from accepting inbound wireless
connections while their wireless cards are
enabled.
181
Control Specification L M H
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.
Control
Dependencies
183
Control Specification L M H
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.
185
Control Specification L M H
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.
187
Control Specification L M H
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.
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
Control
Dependencies
193
Control Specification L M H
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.
Control HR.2-Screening
Dependencies
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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
information systems.
197
Control Specification L M H
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.
199
Control Specification L M H
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).
201
Control Specification L M H
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.
Control
Dependencies
203
Control Specification L M H
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.
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
207
Control Specification L M H
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.
209
Control Specification L M H
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’.
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
Control
Dependencies
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.
Control Type a Directive
q q Preventive q Detective q Corrective
Control Specification L M H
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.
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.
Control Type a Directive
q a Preventive
q a Detective
q q Corrective
a
Control Specification L M H
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.
217
Control Specification L M H
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.
219
Control Specification L M H
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.
Control
Dependencies
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
information systems.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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)
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
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.
Control Type q Directive q Preventive a Detective
q q Corrective
Control Specification L M H
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.
227
Control Specification L M H
OM.5.8 Risk analysis findings should be regularly R M M
reviewed and updated, in light of actual status
confirmed via monitoring data.
Control
Dependencies
229
Control Specification L M H
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.
231
Control Specification L M H
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
233
Control Specification L M H
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.
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
237
Control Specification L M H
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.
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
241
Control Specification L M H
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.
Control
Dependencies
References • SANS
o Critical Control 5: Boundary Defence
• NIST Special Publication 800-41 Revision 1:
o ES-1 Executive Summary
243
Control Specification L M H
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.
Control
Dependencies
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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).
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
Control
Dependencies
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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
251
Control Specification L M H
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.
253
Control Specification L M H
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.
255
Control Specification L M H
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.
257
Control Version History
259
Control Specification L M H
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.
Control
Dependencies
261
Control Specification L M H
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.
• Its location
Control
Dependencies
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.)
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
Control
Dependencies
References
267
Control Specification L M H
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.
Control
Dependencies
269
Control Specification L M H
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
271
Control Specification L M H
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)
273
Control Specification L M H
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
• 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
275
Control Specification L M H
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.
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.
Control Type q Directive q Preventive
a a Detective
q q Corrective
Control Specification L M H
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).
Control
Dependencies
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.
Control Type q Directive a Preventive
q q Detective q Corrective
Control Specification L M H
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.
281
Control Specification L M H
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.
Control
Dependencies
283
Control Specification L M H
IM.2.3 • Testing and verification of Incident Manage- M M M
(Cont.) ment capabilities in advance of incidents
occurring.
285
IM.3 Information Security Incident Version 2.0
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.
Control Type a Directive
q q Preventive q Detective q Corrective
Control Specification L M H
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
287
Control Specification L M H
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.
289
Control Specification L M H
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.
291
IM.4 Information Security Incident Version 1.0
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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.
Control Specification L M H
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.
295
Control Specification L M H
IM.6.5 The Entity should align and integrate its M M M
Information Security Incident Management
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.
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).
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
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
299
Control Specification L M H
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
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
a
Control Specification L M H
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.
303
Control Specification L M H
IM.8.5 • Improving the quality and transaction speed S S S
(Cont.) of the Entity’s Information Security Incident
Management process.
Control
Dependencies
305
Control Specification L M H
IC.1.3 • Avoiding duplication of effort and roles in R R R
(Cont.) Information Systems Continuity Management
and Information Security Incident Management.
Control
Dependencies
307
Control Specification L M H
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).
309
IC.3 Information Systems Continuity Version 2.0
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.
Control Type q Directive a Preventive
q a Detective
q q Corrective
Control Specification L M H
IC.3.1 The Entity’s information system continuity plans S R M
should confirm:
311
Control Specification L M H
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).
Control
Dependencies
313
Control Specification L M H
IC.4.1 • Do preventive controls work as anticipated to S R M
(Cont.) lessen the potential for information system
interruption?
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.
Functional Exercises
Allow personnel to validate their operational
readiness for emergencies by performing
their continuity-related duties in a simulated
operational environment.
315
Control Specification L M H
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.
Acronyms
ADGE Abu Dhabi Government Entity
HR Human Resources
IS Information Security
IT Information Technology
PDCA Plan-Do-Check-Act
321
Appendix B
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.
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.
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).
323
Functional Controls The security controls for an information system that are primarily
implemented and executed by people (as opposed to technology).
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 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 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.
Key Security Indicator The most important security metrics that the organisation uses
to determine the performance and activity within its Information
Security programme.
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.)
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.
Privacy The protection of personal data that are being processed and/or
stored by the Abu Dhabi government entities.
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.
327
Appendix C
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.
329
Appendix D
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.
SP-1.1.301 Information N/A N/A All Control Standards for
Security Road which ADSIC had the primary
Map responsibility have been
removed in v2.
SP-1.2.101 Information N/A N/A All Control Standards for
Security which ADSIC had the primary
Interaction Model responsibility have been removed
in v2.
SP-1.2.201 Information N/A N/A All Control Standards for
Security which ADSIC had the primary
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
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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.
PS-2.2.201 Information N/A N/A All Control Standards for
Security Control which ADSIC had the primary
Standards responsibility have been
removed in v2.
PS-2.3.101 Information N/A N/A All Control Standards for
Security Process which ADSIC had the primary
Guidance responsibility have been removed
in v2.
PS-2.3.201 Information N/A N/A All Control Standards for
Security which ADSIC had the primary
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.
333
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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
Framework responsibilities. v2 provides
definitions of the planning
and competency expectations
applicable in relation to Entity’s
own security audit practices.
PM-6.3.302 Audit Analysis and SG.10 Information v1 Control Standard had an
Reporting 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.
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
335
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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
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.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
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.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
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.603 Working Area PE.3 Workspace Physical and Environmental Control
Security Security Standards have been reengineered
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.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
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.
337
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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
339
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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
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.403 Protection of Log OM.20 Information The v2 Control Standard is
Information 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.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
Management management and analysis, in
and Analysis comparison the multi Control
Standard approach evident in v1.
CM-10.10.603 Fault 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.703 Clock OM.20 Information The v2 Control Standard is
Synchronisation 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.
IA-11.1.103 Access Control IA.4 Privilege Control Intent is addressed with
Policy and Access in IA.4 Privilege and Access
Management Management
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.
341
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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
tangible form in v2.
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
rendered into more modular and
tangible form in v2.
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
information systems.
343
V1 V1 V2 V2 Description of Change
Control Control Control Control Between the Versions
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.
345
Appendix E
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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
Information Security.
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
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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
Framework responsibilities. v2 provides
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
Framework responsibilities. v2 provides
definitions of the planning and
competency expectations applicable
in relation to Entity’s own security
audit practices.
SG.10 Information PM-6.3.302 Audit Analysis v1 Control Standard had an
Security Audit and Reporting orientation towards ADAA
Framework responsibilities. v2 provides
definitions of the planning and
competency expectations applicable
in relation to Entity’s own security
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).
349
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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
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.
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
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.
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
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.
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
acquisition. V2 provides an end-
to-end lifecycle orientation to the
secure engagement, management
and release of products and services
from third-party suppliers.
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
351
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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
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.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
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.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
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.
353
V2 V2 V1 V1 Description of Change
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
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.2 Common Physical PE-9.2.703 Removal of Physical and Environmental Control
and Environmental Property 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.3 Workspace IA-11.3.203 Unattended Physical and Environmental Control
Security User Equipment Standards have been reengineered
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.3 Workspace IA-11.3.303 Clear Desk/Clear Physical and Environmental Control
Security Screen Policy Standards have been reengineered
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.3 Workspace PE-9.1.603 Working Area Physical and Environmental Control
Security Security Standards have been reengineered
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.
355
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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
tangible form in v2.
IS.4 Source Code IS-12.4.303 Source Code No substantial change in control
Protection Protection intent.
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
Protection Protection intent.
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
tangible form in v2.
357
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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
Management access management.
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
Management access management.
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
rendered into more modular and
tangible form in v2.
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
tangible form in v2.
359
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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.
361
V2 V2 V1 V1 Description of Change
Control Control Control Control Between the Versions
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.
363