DOE Cybersecurity Framework

Abu Dhabi Department of Energy
Cybersecurity Framework
Foreword
The Abu Dhabi Department of Energy aims to
facilitate secure and sustainable development of
the energy sector.
Emerging technology trends in energy sector have

created vast opportunities for organizations to
embark upon transformation journeys to
modernize infrastructure and enhance operational
efficiencies.
Modernization of energy infrastructure through

introduction and increased adoption of new
technologies like IoT, cloud, artificial intelligence,
big data, smart meters and digital grids is driving a
“
transformation in energy systems, which are
increasingly becoming distributed and digitally
The ongoing structural shift in enabled.
the energy sector with Energy companies looking to thrive in a new
integration of new technologies energy world need to both seize the opportunities
and digitization has delivered from digitally driven transformative change as well
significant benefits while at the as protect themselves from the associated risks to
same time, it has exposed the maintain the trust of their customers, stakeholders
“
sector to new cyber challenges
that must be proactively
and regulators. Having robust cybersecurity
capabilities has become vital in this era of digital
disruption in the energy sector.
addressed.
With this backdrop and to ensure that the energy
HE Eng. Awaidha Murshed Al Marar sector safely and securely traverses the
transformation journey, the Abu Dhabi Department
Chairman of the Department of Energy of Energy has developed the ‘Cybersecurity
Framework’ for the Energy Sector that outlines the
core set of principles and defines the necessary
building blocks for establishing a resilient
cybersecurity program.
Classification code – Classification: Public 1

Foreword
Digital intelligence driven by integrated data has
become a key factor, helping utilities optimize the
way energy is delivered and this digitization is set
to accelerate further. Smart grids, renewables,
electric vehicles and connected workforce will
continue to drive connectivity across energy
infrastructure.
Information Technology (IT) and Operational

Technology (OT) are converging at an increasingly
rapid pace. This convergence has expanded the
cyber threat landscape to critical infrastructure
where segregated or isolated networks used to be
the norm. As a result, multiple aspects of a utility’s
“
operations are exposed to security risks and the
attack surface has exponentially increased.
Emerging technology trends in
Cyber risk in energy sector extends far beyond the
energy sector are leading to
company and physical location of a cyber-attack.
gradual IT and OT Such events, whether deliberate or inadvertent,
convergence. The rapid digital threaten public and employee safety, national
transformation is exposing the economic stability, reliability and resiliency of
sector to variety of cyber operations and consumer privacy. Thus it is
threats. It is vital for the sector imperative for the sector to adopt a proactive,
pragmatic, and strategic approach to manage
to implement measures to
cybersecurity risks.
prevent cyber-attacks as well
and respond to the inevitable

“
as establish the ability to detect Effective and efficient cyber resilience demands an
enterprise-wide response to cyber threats. Utilities
attacks. need to manage physical, IT and OT security in a
cohesive, coordinated and interdependent manner
and assess security risks across the entire
HE Eng. Ahmed Mohamed Al Rumaithi landscape.
Undersecretary- Department of Energy To help the sector in navigating the cyber risks
effectively, the Abu Dhabi Department of Energy
has developed a sector specific cybersecurity
framework, that caters to the cybersecurity
requirements of both IT and OT environments, and
can be adapted to any operational environment,
from generation, transmission to distribution
utilities.

Contents
Section Page
1 Introduction 5
2 Abbreviation and Glossary 8
3 Scope and Compliance 15
4 Framework Overview 20
5 Security Domains 22
CSG Cybersecurity Governance 24
CSRM Cybersecurity Risk Management 40
CSPE Cybersecurity Performance Evaluation 51
AM Asset Management 58
BM Backup Management 78
CS Cloud Security 86
CCM Configuration and Change Management 94
CC Cryptography Control 104
CSCM Cybersecurity Continuity Management 110
CSPM Cybersecurity in Project Management 116
CSIM Cybersecurity Incident Management 125
DPP Data Protection and Privacy 143
HRS Human Resource Security 146
IAM Identity Access Management 157
LCRC Legal, Contractual and Regulatory Compliance 175
LM Logging and Monitoring 181
NSM Network Security Management 191

Contents
Section Page
PES Physical and Environment Security 210
TPRM Third Party Risk Management 228
VM Vulnerability Management 243
6 Domain Mapping 252
Annexures
I Cybersecurity Risk Management Process 257
II Change Prioritization Guide 265
III Personal Data Protection Goals 266
IV Fair Information Practices 267
V Privacy by Design Principles 268
VI Personal Data Security Measures 269
VII Social Media Policy 274
VIII Social Media Security Controls 275
IX Cybersecurity Workforce Development 277
X ICS/ OT Systems Password Management 279
XI Network Segmentation 281

Wireless Communication Cybersecurity
XII 283
Considerations for ICS/ OT Environment
XIII Statement of Applicability Template 285
XIV Cybersecurity Incident Handling Process 286
XV Cybersecurity Incident Response Team Roles 287
XVI Cybersecurity Incident Classification Matrix 289
XVII References 290

Introduction 01
1.1. Background
Digital trends like Distributed Energy Resources, Electric
Vehicles, Digital Substations, Advance Metering
Infrastructure, and Home Automation will drive adoption of
new technologies like Cloud, Internet of Things (IoT),
Analytics, Artificial Intelligence (AI), and Machine
Learning. These emerging trends and technologies are
increasing the connectivity of devices across Information
Technology (IT) and Operation Technology (OT)
environments and leading towards IT and OT
convergence.
Historically, OT environments have been isolated with

limited connectivity to external networks beyond the
physical site and utilized vendor-specific protocols and
proprietary technologies. This change in the IT and OT
landscape has contributed to a growing and complex
range of cybersecurity threats to energy sector.
Since energy sector is deemed as critical infrastructure

and an integral component of national security, it is
becoming a target for organized cyber criminals and
notably highly sophisticated state-sponsored threat actors.
Energy is an attractive sector for the more sophisticated,
often state-sponsored, threat actors, due to the significant
disruption a successful attack can cause, not only to the
target organization, but to society overall.
Protecting the energy infrastructure has become more

critical now than ever, regulators around the globe have
started to pay closer attention to these risks and are
establishing minimum standards and expectations of what
utilities need to do to protect themselves.
To help the sector navigate the ever-evolving threat

landscape, and support the sector in this transformation
journey, Abu Dhabi Department of Energy has developed
the sector specific cybersecurity framework, that is
aligned with global and industry best practices as well as
in adherence to the applicable and relevant national laws
and regulations.
Embracing the cybersecurity framework will help in

managing the ever-expanding range of cyber threats
across the entire energy sector ecosystem. It will help in
develop capabilities that increases trust in systems’ safety
and security and thus enable the sector to transform the
digital landscape with confidence in a complete digital
ecosystem.
1.2. Purpose
The cybersecurity should not be seen as impediment to
modernization of energy infrastructure, but as a way to
enable this transformation securely and safely, with
confidence and trust. The framework intends to ensure
that appropriate safeguards are implemented to maintain
acceptable level of Safety, Confidentiality, Integrity, and
Availability of information and operations, handled by
licensed entities.
The purpose of the Abu Dhabi Department of Energy

Cybersecurity Framework is to provide comprehensive
and structured guidance, that can be leveraged to create
custom cybersecurity programs, tailored for the particular
entity’s needs. The Abu Dhabi Department of Energy
Cybersecurity Framework lays down the approach that
the licensed entities can adopt to develop or improve
existing cybersecurity programs in a systematic and risk
prioritized manner.
The framework would be supplemented with an ongoing

compliance measurement program, aimed at gradual and
continual improvement of the cybersecurity posture of
energy sector.

Abbreviations and Glossary 02
2.1. Abbreviations
Abbreviation Details
ACL Access Control List
ADMS Advanced Distribution Management System
AM Asset Management
AMI Automatic Metering Infrastructure
BCM Business Continuity Management
BIA Business Impact Analysis
BM Backup Management
BMS Backup Media Storage
BYOD Bring Your Own Device
C, I, A, S Confidentiality /Integrity/ Availability /Safety
CAB Change Advisory Board
CC Cryptography Control
CCM Configuration and Change Management
CISO Chief Information Security Officer
CPU Central Processing Unit
CS Cloud Security
CSCM Cybersecurity Continuity Management
CSG Cybersecurity Governance
CSIM Cybersecurity Incident Management
CSP Cybersecurity Policy
CSPE Cybersecurity Performance Evaluation
CSPM Cybersecurity in Project Management
CSRM Cybersecurity Risk Management
CSSC Cybersecurity Steering Committee
CST Cybersecurity Team
CVE Common Vulnerabilities and Exposures
CVSS Common Vulnerability Scoring System
DCS Distributed Control Systems

2.1. Abbreviations
DHCP Dynamic Host Configuration Protocol
DLP Data Loss Prevention
DMZ De-Militarized Zone
DNS Domain Name Server
DoE Abu Dhabi, Department of Energy
DoS Denial of Service
DPO Data Protection Officer
DPP Data Protection and Privacy
DRM Disaster Recovery Management
EMM Enterprise Mobility Management
EMS Energy Management System
EPP End Point Protection
FAT Factory Acceptance Test
FIM File Integrity Monitoring
GPO Group Policy Object
GPS Global Positioning System
GRC Governance, Risk and Compliance
HMI Human Machine Interface
HR Human Resource
HRS Human Resource Security
HTTPS Hypertext Transfer Protocol Secure
IaaS Infrastructure as a Service
IAM Identity and Access Management
ICS Industrial Control System
IDS Intrusion Detection System
IED Intelligent Electronic Device
IEEE The Institute of Electrical and Electronics Engineers
IP Internet Protocol
IPS Intrusion Prevention System

2.1. Abbreviations (contd.)
ISP Internet Services Providers
IT Information Technology
KPI Key Performance Indicator
LAN Local Area Network
LCRC Legal, Contractual and Regulatory Compliance
LM Logging and Monitoring
MAC Media Access Control
MTD Mobile Threat Defense
NAC Network Access Control
NAT Network Address Translation
NCEMA National Emergency Crisis and Disasters Management Authority
NSM Network Security Management
NTP Network Time Protocol
OEM Original Equipment Manufacturer
OS Operating System
OT Operational Technology
PaaS Platform as a Service
PAM Privileged Access Management
PES Physical and Environmental Security
PGP Pretty Good Privacy
PLC Programmable Logic Controller
PMU Phasor Measurement Unit
POP3 Post Office Protocol 3
PT Penetration Testing
RPO Recovery Point Objective
RTO Recovery Time Objective
RTU Remote Terminal Unit
SaaS Software as a Service
SAM Software Asset Management

2.1. Abbreviations (contd.)
SAN Storage Area Network
SAT Site Acceptance Test
SCADA Supervisory Control And Data Acquisition
SIEM Security Information and Event Management
SIS Safety Instrumented System
SLA Service-Level Agreement
SNMP Simple Network Management Protocol
SOC Security Operation Centre
SOP Standard Operating Procedure
SSID Service Set Identifier
SSL Secure Sockets Layer
TEE Trusted Execution Environment
TLS Transport Layer Security
TPRM Third-party Risk Management
UAE United Arab Emirates
UAT User Acceptance Test
UHF Ultra High Frequency
UTC Universal Time Coordinated
VHF Very High Frequency
VM Vulnerability Management
VPN Virtual Private Network

2.2. Glossary
Term Definition
Access Ability and means to enter a facility, to communicate with or
otherwise interact with a system, to use system resources, to gain
information the system contains, or to control system components
and functions.
Access Control Limiting access to organizational assets only to authorized entities
(e.g., users, programs, processes, or other systems).
Asset Something of value to the organization. Assets can include
software, hardware, information, personnel, facilities in IT and OT/
ICS environments. They may be applications, servers, database,
switches, routers, firewalls, security tools, utility software, networks
within and interfacing to the OT/ ICS, PLCs, DCS, SCADA,
instrument-based systems that use monitoring device such as an
HMI, systems that use routable protocol or are dial-up accessible
Authentication Verifying the identity of a user, process, or device, often as a
prerequisite to allowing access to resources.
Availability Ensuring timely and reliable access to information and systems.
Business Impact Analysis The process of determining the criticality of business activities and
associated resource requirements to ensure operational resilience
and continuity of operations during and after a business disruption.
Confidentiality The preservation of authorized restrictions on information access

and disclosure. Confidentiality is information being accessible only
to authorized people, processes, and devices.
Controls The management, operational, and technical methods, policies, and
procedures, manual or automated to protect the Confidentiality,
Integrity, Availability and Safety of the systems and information.
Critical Infrastructure Critical infrastructure are systems and assets, whether physical or
virtual, vital to UAE, incapacity or destruction of which would have a
debilitating impact on national security, economic stability, public
health or safety, or any combination of these.
Department of Energy Abu Dhabi, Department of Energy.
Domain Logical grouping of cybersecurity practices.
Governance Process of providing strategic direction and oversight for ensuring
that organization manages risk, compliance, and alignment of
cybersecurity program with organization’s strategic objectives.
Identity The set of attributes by which an person is recognizable and is
sufficient to distinguish that person from any other person.
Information Assets Information that is of value to the organization, such as operational
data, intellectual property, customer information, and contracts.
2.2. Glossary (contd.)
Term Definition
Cybersecurity The preservation of Confidentiality, Integrity, Availability and Safety
of IT/ OT systems and processing facilities.
Cybersecurity Event Any observable occurrence in a system or network that is related to
cybersecurity (confidentiality, integrity, or availability).
Cybersecurity Risk The risk to organizational (including financial, legal, regulatory,
functions, reputation), due to the potential for unauthorized access,
disclosure, disruption, modification, or destruction/ damage of IT
and ICS/ OT systems.
Information Technology Electronic information resources organized for the collection,
processing, maintenance, use, sharing, dissemination, or
disposition of information.
Logging Logging typically refers to automated recordkeeping of system,
network, or user activity. Logging may also refer to keeping a
manual record (e.g., a sign-in sheet) of physical access by
personnel to a protected asset or restricted area, although
automated logging of physical access activity is commonplace.
Monitoring Critically observe the activity, process, or system that is being
monitored.
Operations Technology Programmable systems or devices that interact with the physical
environment (or manage devices that interact with the physical
environment). Examples include industrial control systems, building
management systems, fire control systems etc.
Policy Document stating the management’s direction and expectations
with high level directives.
Procedure Step wise guidance, detailing the way of carrying out a process.
Process Series of activities or tasks that contribute to the fulfilment of a task.
Purdue Reference Model The Purdue model, also known as Purdue Enterprise Reference
Architecture (PERA) is a reference architecture that was adopted
by ISA-99 as a concept model for ICS network segmentation.
Service Level Agreement Defines specific responsibilities of the service provider and sets the
customer's expectations regarding the quality of service.
Standard Standard is a document that describes mandatory set of
requirements.
Threat Any circumstance or event with the potential to adversely impact
the confidentiality, integrity, availability and safety of information/
systems.
Vulnerability Vulnerability is a weakness or flaw in IT, ICS/ OT systems, network,
procedures or controls that can be exploited by a threat.
Scope and Compliance 03
3.1. Scope
Abu Dhabi Department of Energy Cybersecurity
Framework is applicable to the entities holding a license
issued by the Abu Dhabi Department of Energy.
The framework’s cybersecurity controls shall apply to

both Information Technology (IT) and Operational
Technology (OT) environments and cover, including but
not limited to their employees, consultants, contractors,
vendors, and visitors engaged with licensed entities
through various means. This framework is applicable to
any information regardless of its type and medium (e.g.
Printed, Electronic, Verbal, Written, etc.) that may be
owned, leased, or otherwise in the possession, custody,
or control of the licensed entities.
Licensed entities are expected to establish, implement,

maintain, and continuously improve the cybersecurity
controls mentioned in the framework across all the
divisions/ departments, physical locations within an entity
and all systems including but not limited to information
technology systems and operational technology
systems.
The organizations referred to as “Licensed Entities” in

the framework are the organizations holding a license
issued by Abu Dhabi Department of Energy.
3.2. Ownership & Revision

Abu Dhabi Department of Energy is owner of this
Cybersecurity Framework. Department of Energy
reserves all rights to revise this framework based on
change in cybersecurity landscape, emerging threats,
changing trends in energy sectors as and when deemed
necessary.
New controls might be added or amendments in existing

controls might be made as the risk environment evolves
over time.

3.3. Compliance
All the entities holding a license issued by the Abu Dhabi Department of Energy shall comply
with all the requirements of the Abu Dhabi Department of Energy Cybersecurity Framework. The
licensed entity are required to address and monitor their compliance with this framework.
Licensed entities are also required to generate, maintain, and protect the records to demonstrate
the due diligence undertaken to comply with this framework. These records, in support of the
compliance efforts may be requested by the Department of Energy. Assessment of compliance
will be based on evidence.
The Department of Energy will evaluate licensed entity’s compliance with the framework on an
ongoing basis, through multiple methods such as reviewing self-assessment questionnaires,
independent third-party evaluation reports or on-site visits.
The licensed entities are required to submit their compliance status to the Department of Energy
annually in accordance with the Abu Dhabi Department of Energy “Cybersecurity Audit
Guidelines” and other relevant provisions mentioned in this framework.
The Department of Energy seeks to ensure that effective cybersecurity risk management
measures are implemented and maintained across the energy sector. Remedial actions when
deemed necessary would be undertaken by Department of Energy to address the instances of
non-compliance. The remedial actions would be aligned with the specific nature of the risk posed
by non-compliance and would factor impact the non-compliance may have on the energy sector
as well as the urgency to resolve the issue. The remedial action may include, but not limited to:
• Support : The Department of Energy will provide focused support and structured guidance to
entities to support their compliance efforts.
• Assist : Where an entity is non-compliant, the Department of Energy will seek to establish an
agreed course of action with the entity to achieve desired compliance levels.
The Department of Energy expects the majority of its compliance enforcement involvement to
focus on supporting and assisting entities.
• Correct : In extreme cases where non-compliance presents an intolerable risk to the energy
sector and/or national security, or cases where a serious risk unexpectedly presents itself and
must be addressed urgently, the Department of Energy may escalate to enforcement
measures to achieve compliance and mitigate the identified risk. In these cases, the
Department of Energy will seek to maintain communication and cooperation with the entity as
much as circumstances allow.
Compliance to existing laws, or any other legislations in the future pertaining to Cybersecurity,
will take precedence over the Abu Dhabi Department of Energy Cybersecurity Framework.

3.4. Statement of Applicability
The Abu Dhabi Department of Energy Cybersecurity Framework contains controls that cover a
broad range of cybersecurity aspects holistically. These controls are arranged in twenty (20)
security domains.
All controls in the three (3) domains, namely Cybersecurity Governance (CSG), Cybersecurity
Risk Management (CSRM) and Cybersecurity Performance Evaluation (CSPE) are mandatory.
The nature of these controls is such that they would always be applicable in all environments as
they are the foundational controls, necessary to successfully build, run and maintain a well
functioning cybersecurity program.
The controls in the remaining seventeen (17) domains are risk-based, i.e., applicability of
controls of the remaining seventeen (17) domains would be derived from Risk Assessment.
Owing to the diverse licensee landscape, with different operating environments like power and/or
water generation, transmission, distribution, and sewerage, it is a possible that some sub
controls mentioned in the seventeen (17) risk-based domains may not be applicable to some
entities. The licensed entity shall document the Statement of Applicability (as per template
provided in Annexure XIII: Statement of Applicability Template), providing the justification for
implementation and exclusion of sub controls mentioned in the Department of Energy
Cybersecurity Framework. In cases, where there is a valid justification for a sub control not being
applicable, the exclusion of such sub controls should be supported by appropriate justification
that is approved by the entity’s senior management.
It is important to note that the applicability is to be determined at the sub control level. Further,
the “Implementation Guidance” provided in all sub controls is only a suggestive way to achieve
the control objectives, it is not mandatory. The entities may customize the implementation
guidance based on their specific needs and environments.
Cybersecurity Framework
Cybersecurity Governance
Cybersecurity Risk Management
Asset Backup Human Resource Identity Access Logging & Network Security
Management Management Security Management Monitoring Management
Configuration &
CS Continuity CS Project Third-party Risk Vulnerability
Cloud Security Change
Management Management Management Management
Management
Legal,
Cryptography Data Protection & CS Incident
Contractual & Physical & Environmental Security
Control Privacy Management
Regulatory
Cybersecurity Performance Evaluation

3.5. Stakeholder Roles and Responsibilities
Energy sector is deemed as critical infrastructure and it is vital for national security, economic
stability as well as public health and safety. Close collaboration and ongoing engagement
between Abu Dhabi Department of Energy and licensed entities is essential to achieve the
desired protection and security levels.
Stakeholder Roles & Responsibilities
Roles
Provide governance, guidance and support to enhance cybersecurity

maturity of energy sector and ensure adequate level of compliance by
licensed entities.
Responsibilities
Abu Dhabi,
Department of • Development and update of framework: Department of Energy has
Energy developed the Cybersecurity Framework and will regularly review and
update this framework based emerging sector trends, emerging
technologies, and evolving cybersecurity threats.
• Compliance Enforcement: Department of Energy will regularly
evaluate the licensed entity’s adherence to the requirements set forth
in the framework. Further the Department of Energy will provide
ongoing support and guidance to the licensed entities to help them
achieve satisfactory level of compliance.
Roles
Ensure sound cybersecurity risk management practices have been

implemented by complying with the requirement of the Cybersecurity
Framework.
Responsibilities
• Development of framework: Contribute in development and update of

Licensed Entity this framework by providing their feedback and participating in the
workshops arranged by the Department of Energy.
• Comply: The licensed entity shall comply with requirement of this
framework by establishing an cybersecurity governance structure,
conducting risk assessment, implementing security controls based on
the risk assessment and regularly evaluating performance of the
cybersecurity program.
• Information sharing: The licensed entity shall regularly share required
reports and artefacts mentioned in this framework with the
Department of Energy.

Framework Overview 04
4.1. Framework Overview
The Abu Dhabi Department of Energy has developed the Cybersecurity Framework to prescribe
the foundational set of requirements, designed to improve cyber resilience and secure the assets
critical for the secure and safe operation of energy sector IT and Industrial Control System (ICS)/
OT environments. These requirements are derived from and are aligned with international best
practices as well as applicable local laws and regulations.
This framework can be adapted to any IT and ICS/OT environments like power and/or water
generation, transmission, distribution, and sewerage treatment. It can be applied to any existing
cybersecurity program regardless of the overall maturity.
The framework has:

• Twenty (20) cybersecurity domains;
• Forty-seven (47) controls; and
• One hundred forty-four (144) sub controls.
Each domain has multiple controls, each of which is further divided into multiple sub controls.
The implementation guidance is provided at the sub control level. Further, additional guidance,
specific to the ICS/ OT environments where required has also been provided.
Furthermore, the order of the seventeen (17) risk-based domains does not imply the order of
their importance or priority. They have been arranged alphabetically.
“Implementation Guidance” and “ICS/ OT Systems Supplementary Guidance” is provided for
each sub control. The “Implementation Guidance” is applicable for both IT and ICS/OT
environments, whereas the “ICS/ OT Systems Supplementary Guidance” prescribes the
additional measures the entity has to implement, in the ICS/ OT environment supplementary to
the measures mentioned in the “Implementation Guidance”.

Security Domains 05
6.1. Domain Structure
Cybersecurity Framework have twenty (20) domains, where each domain is a logical grouping of
security controls that are related to the specific aspect of cybersecurity.
Each domain has multiple controls which in turn have one or several sub controls that
collectively aid in achieving the control’s specific security objectives.
Sub controls can include administrative, technical, people, process and physical aspects of
cybersecurity. Each sub control is supported by detailed implementation guidance.
Domain Name
Objective
Overall objective for implementing controls and sub controls related to specific area of security.
Description
Description of the domain, its purpose and constituents etc.
Applicability
Statement suggesting sub controls prescribed under the domain are mandatory or risk based.
IAM-1 (Control No.) Control Name

Objective Overall objective for implementing sub controls prescribed under the control.
IAM-1-1 (Sub control No.) Sub control Name

Descriptions of the safeguards required for achieving the particular security
Sub control
objective.
Implementation Guidance
Suggested methodology to implement the sub control in both IT systems and ICS/ OT systems. This is suggestive
guidance and the licensed entity can amend or customize it as per their requirements.
ICS/ OT Systems Supplementary Guidance

Additional information that is specific to ICS/ OT systems. It is important to note that this guidance is in addition to
the guidance provided in the “Implementation Guidance” section above in this table. Thus for ICS/ OT environments
the guidance mentioned in the section above as well as guidance mentioned in this section would apply.
IAM-1-1
IAM 1 1
Domain Control Sub Control

Cybersecurity Governance
CSG
Cybersecurity Governance (CSG)
Objective
To establish a formal governance framework for implementing, operating, monitoring, reviewing,

and maintaining the licensed entity’s cybersecurity risks, in line with its strategic objectives and
in accordance with relevant laws and regulations.
Description
Cybersecurity is an integral component of enterprise governance and should be aligned with

IT/OT requirements and integrated into corporate strategy, concept, design, implementation, and
operation. A formal cybersecurity governance framework comprising of cybersecurity
management organization structure, roles and responsibilities, relevant cybersecurity policies,
procedures and standards helps in ensuring that the cybersecurity risks are being managed
effectively and efficiently.
Applicability
It is mandatory for the licensed entity to implement the controls and sub controls prescribed in
this domain.
Cybersecurity Policy Cybersecurity Organization of

Cybersecurity
Governance

Cybersecurity Governance (CSG) (contd.)
CSG-1 Cybersecurity Policy
To develop, communicate, and maintain an entity-wide cybersecurity
policy that sets managements directives and outlines the principles of
protecting all the information assets of the entity from all threats,
Objective whether internal or external, deliberate or accidental such that the safety
is protected; confidentiality of information is maintained; integrity of
information can be relied upon; availability of information is ensured; and
all legal, regulatory, statutory and contractual obligations are met.
CSG-1-1 Cybersecurity Policy

The cybersecurity policy that provides management direction shall be
Sub control documented, established, and reviewed periodically in accordance with
business requirements and relevant laws and regulations.
The Cybersecurity Policy (CSP) sets the guiding principles on which the entity’s IT/ OT
environment security risk management measures are based on. While developing the CSP, the
licensed entity may refer to the following recommendations:
i. Policy Framework:
The licensed entity may choose to define a hierarchical policy framework wherein the level
of detail increases while traversing down the hierarchy. The hierarchical structure helps in
ensuring that whilst the management’s directives lay down the broad expectations and
security objectives, the stakeholders from respective areas/ domains can create relevant
procedures, standards, guidelines etc. with level of detail necessary to achieve the
objectives set out in the policy.
The levels can be customized based on entity’s specific requirements. A typical hierarchy is
illustrated below for reference:
• Level 1: The CSP should be approved by executive management (or relevant
management body like enterprise risk management committee, CSRM committee etc.)
and at a high-level outline entity’s approach to managing its IT/ OT security objectives;
• Level 2: The broad and high-level directives outlined in the CSP should be supported by
detailed domain/ area specific policies and procedures, standards, implementation
guidelines and templates. These supporting procedures should be derived from the policy
statements and provide the details of necessary actions to achieve the objectives of the
policy statement and aim at facilitating the implementation of the CSP directives; and
• Level 3: Forms, Templates, Checklists, Work Instructions, Device specific Standard
Operating Procedure (SOP) etc. that are aligned with and support the implementation of
the control objectives of Level 2 documents.

ii. Policy Owner:
The ownership and responsibility for the maintenance of the CSP should be formally
assigned. It may be assigned to an individual (e.g. Chief Information Security Officer (CISO))
or a management body like enterprise risk management committee, CSRM committee etc.
The policy owner is responsible for ensuring its review and update as well as its effective
implementation;
iii. Objectives of the policy:
The objectives of the policy should be documented, and these serve as the basis for other
IT/ OT security procedures, standards, guidelines etc. The objectives should convey
management’s direction and expectations from the cybersecurity function;
iv. Policy Scope and Applicability:
The scope and applicability of the CSP should be defined. The scope would include
employees, external/ third party personnel (i.e., third party resources, consultants, interns,
contractors employed with the entity who engage in work and have access to IT/ OT
Systems, IT/ OT processing facilities, physical locations etc.;
v. Policy Review and Approval:
The CSP should be reviewed at least annually or in events of any significant changes in the
existing IT/ OT security environment to ensure their continuing suitability, adequacy, and
effectiveness.
The policy owner should be responsible for making the necessary updated and changes in
the policy document.
The review should assess the following:
• Impact on the risk profile due to, but not limited to, the changes in IT/ OT security
environment (e.g., change in operations, change in technology, regulatory changes, major
security incidents, emerging threat landscape); and
• Effectiveness of CSP.
All changes to the policy should be communicated to all employees and third-party
personnel through appropriate forums and channels.
The policy may be approved by an individual (e.g., CISO) or a management body like
enterprise risk management committee, CSRM committee etc.;
vi. Roles and Responsibilities:
• The roles and responsibilities of individuals, working groups, teams’ committees etc.
responsible for implementation, maintenance, compliance and improvement of IT/ OT
security should be documented in the CSP; and

• The licensed entity may choose to mention the high-level roles and responsibilities in the
policy document, and elaborate them as necessary in the corresponding committee/
working group charters, area/ domain specific procedure, standards etc.
vii. Communication:
• The CSP should be made available to all the interested parties, as appropriate, through
timely communication. The communication should be in a form that is relevant, accessible
and understandable to the intended recipient; and
• The communication should highlight the importance of compliance with the CSP, and all
supporting cybersecurity policies and procedures, and consequences of violations.
viii. Compliance:
• All employees, stakeholders and third-party, contractors and consultants having access to
licensed entity’s information and information processing facilities should comply with the
CSP; and
• All violation or any attempted violation of the CSP should result in disciplinary action.
Disciplinary action should be consistent with the severity of the incident.
ix. Exception:
There might be instances where owing to technical or operational constraints, it might not be
possible to fully or partially adhere to the requirements of the CSP. Thus, it is important to
define a formal process for seeking approval for exceptions or deviations from the CSP or its
supporting procedures, standards etc.
The licensed entity can refer to the following considerations while defining the exception
process:
• Wherever warranted, the approval should only be provided after an appropriate
assessment of the risks arising out of providing the exception;
• Exceptions should not be universal but should be agreed on a case-by-case basis, upon
formal request made by the concerned stakeholder;
• The exception approval should be only provided for a limited period and should not be
perpetual (as changes in the environment might impact the considerations basis which the
approval was granted originally); and
• After the time period for which the exception is granted has elapsed, a reassessment of
the risks associated with the exception should be done and appropriate action should be
taken accordingly. This may be providing approval again for the defined time period,
consideration for implementing compensating controls etc.
Further, the licensed entity may consider the controls and sub controls mentioned in this domain
and include them in the CSG policy, as applicable, based on the risk assessment.

No additional information specific to ICS/ OT systems.

CSG-2 Organization of Cybersecurity
To establish a management framework to oversee, coordinate, and
Objective
control the implementation of cybersecurity within the licensed entity.
CSG-2-1 Cybersecurity Roles and Responsibilities

Roles and responsibility for IT/ OT security shall be defined, assigned,
Sub control
and communicated.
Effective implementation of IT/ OT security controls requires involvements of different
departments in the licensed entity including but not limited to Cybersecurity, IT/ OT, Physical
Security, Human Resource (HR), Safety, Legal, Internal Audit etc. Thus, a multi-disciplinary
approach involving co-operation and collaboration amongst different stakeholders is
recommended. Allocation of IT/ OT security responsibilities should be done in accordance with
the CSP (see CSG-1-1).
The roles and responsibilities would vary from strategic level roles for providing direction and
oversight, to operational responsibilities for control implementation. These responsibilities may
be documented at a high level in the CSP document, and elaborated as necessary in the
corresponding committee charters, area/ domain specific procedure, standards etc.
The licensed entity may consider establishing the below critical roles while implementing this
control. These are only suggested roles and the specific hierarchy, number and types of roles
etc. would depend on, and can be customized based on a particular licensed entity’s
requirements. The licensed entity may combine or segregate these suggested responsibilities
among one or more roles as deemed necessary, based on the entity’s requirements.
i. Cybersecurity Steering Committee (CSCC):
• CSSC should be established to oversees and govern the establishment, implementation,
maintenance, and continual improvement of cybersecurity in the entity; and
• Multiple cybersecurity controls require coordination and involvement of different
disciplines as mentioned above. Thus, establishing a cross functional committee, having
representation from these key disciplines would help in driving effective control
implementation across the licensed entity and aid in effective cooperation and
coordination among different functions.
Following are the considerations that the licensed entity may undertake while establishing
the CSSC:
• The CSSC should have senior management representation from departments like
Cybersecurity, IT/ OT, Physical Security, HR, Safety, Legal, Procurement, Internal Audit
etc.;
• The charter governing the functioning of CSSC should be developed;

• CSSC may be a subcommittee of other relevant management committees like Board Risk
Committee, Enterprise Risk Management Committee etc. or a standalone committee; and
• The CSSC should have permanent members and other guests may be included in the
committee meetings, where expert guidance and inputs are required.
The key responsibilities of the CSSC may include:
• Establish an IT/ OT security program and define the IT/ OT security objectives that are
compatible with the strategic direction and objectives of the entity;
• Approve the CSP and subsequent changes to the same;
• Establish roles and responsibilities for IT/ OT security;
• Enforce adoption of the CSP and oversee its effective implementation;
• Provide adequate resources to establish, implement, operate, monitor, review, maintain
and improve the IT/ OT security program;
• Approve the ‘risk appetite’ i.e. acceptable level of risk (refer CSRM-2-3);
• Endorse ‘risk acceptance’ requests (refer CSRM-2-3);
• Endorse exception request for deviation from policy;
• Communicate the importance of meeting cybersecurity objectives and conforming to the
CSP requirements;
• Ensure periodic IT/ OT security performance evaluation are conducted to determine the
effectiveness of the IT/ OT security program;
• Ensure timely corrective actions are taken basis the outcome of internal audits,
management reviews, security incidents and external audits etc. and thus promoting
continual improvement and ensuring that the IT/ OT security program achieves its
intended outcomes;
• Reviewing major cybersecurity incidents with due assistance from the CISO;
• Promote adoption of Department of Energy Cybersecurity Framework in entity; and
• Lead by example to promote a ‘security-aware’ cybersecurity culture within the entity.
The CSSC should meet periodically (e.g., on a quarterly basis) to assess the security
requirements of the entity or as required by any significant change in the business operating
environment. These CSSC reviews help in ensuring that the IT/ OT security program
continues to be effective in helping the entity achieve its intended outcomes from the IT/ OT
security program.

ii. Chief Information Security Officer:
The CISO would be responsible to:
• Lead and provide the overall strategic direction to the IT/ OT security function;
• Develop the entity’s cybersecurity framework (procedures, standards, guidelines etc.) that
is aligned with the licensed entity’s cybersecurity objectives;
• Oversee, coordinate, and direct the implementation of the cybersecurity framework,
including the IT/ OT security controls at all licensed entity’s locations mediated through the
concerned stakeholders from various departments like cybersecurity, IT/ OT, HR, safety,
procurement, physical security etc.;
• Ensure that the IT/ OT security function is adequately staffed to ensure effective
implementation and ongoing maintenance of the cybersecurity framework;
• Periodically review (at-least once annually or in case of major changes) the CSP and
framework to ensure the efficiency and effectiveness of the IT/ OT security control
infrastructure as a whole, recommending improvements wherever necessary;
• Staying abreast with, and identifying global, regional, and sectoral IT/ OT security trends
and developments that may warrant changes to cybersecurity framework environment
and, where appropriate, proposing changes to the CSP and/or framework ;
• Direct major strategic initiatives to enhance IT/ OT security;
• Drive security programs and projects to improve the IT/ OT security maturity;
• Encourage the participation of stakeholders from departments like HR, IT/ OT, legal,
procurement etc. whose contributing and support is required to comply with cybersecurity
framework requirements;
• Develop an cybersecurity framework program calendar to ensure timely execution and
track completion of all the IT/ OT security activities such as risk assessments,
performance evaluation, user access review activities, vulnerability assessments, asset
register updates, backup restoration tests, IT/ OT DR tests, incident response drills etc.;
• Ensure IT/ OT security risk assessments are carried out periodically;
• Coordinate or assist in the investigation of security incidents;
• Review major IT/ OT security incidents and, where appropriate, recommend
improvements to address any underlying root causes;
• Report security incidents and violations of CSP to the CSSC;
• Manage the development and implementation of IT / OT security training and awareness
programs;
• Monitor the effectiveness of the cybersecurity framework through audits, Key
Performance Indicator (KPI) reporting and governance programs;

• Ensure CSSC reviews are conducted as per defined frequency;
• Monitor the status of the corrective action plans resulting out of internal assessments,
internal and external audits, CSSC recommendations etc. and ensure necessary and
timely corrective actions are taken; and
• Periodically report the status of the IT / OT security program, initiatives, projects etc. to
CSSC, management and other interested parties.
iii. Cybersecurity Team (CST):
• The CST would be entrusted with the responsibility of managing security related
operations on a day-to-day basis as per the guidance and direction from the CISO; and
• The detailed responsibilities of the CST will vary from domain to domain and such domain
specific responsibilities should be documented in the relevant procedures, standards etc.
iv. IT/ OT Security Coordinators/ Champions:
• IT/ OT security is multi-disciplinary and cross functional in nature and there are multiple
cybersecurity controls that require involvement of different departments. Examples of such
controls are data classification, conducing user access reviews etc.;
• Having formally appointed IT/ OT Security Coordinators/ Champions, will help in effective
implementation and coordination of such department level cybersecurity initiatives/
controls;
• These champions would typically be nominated by division/ department heads and may
be appointed at division/ department/ function level, depending on the structure of the
entity and size of division/ department/ function etc.; and
• To ensure active participation by Security Coordinators/ Champions, the licensed entity
may consider adding the responsibilities associated with this role in the employee’s annual
performance KPIs/ formal job responsibilities.
v. Internal Auditor:
• The Internal Auditor role would be responsible for conducting the audit of effectiveness of
the entity’s cybersecurity framework and validate whether the cybersecurity policies,
procedures, standards etc. are being consistently complied with.
vi. Individual responsibilities:
• All licensed entity’s personnel (i.e. employees on the payroll and others acting in a similar
capacity, such as contractors, consultants, interns etc.) are responsible for complying with
the principles, axioms, and policies in the CSP where relevant to their roles;
• They are responsible for maintaining the security of all information entrusted to them.
Upon hire, as a condition of employment, each employee should undertake to comply with
licensed entity’s’ cybersecurity policies (refer CSG-1-1); and

• Any worker failing to comply with the security policies could be subject to disciplinary
action, potentially including termination of employment or contract and/or prosecution.
Further, a related aspect related to this control is “Single Person Dependency” risk wherein the
loss of key personnel owing to resignation, emergency leaves, sickness etc. may impact the
effective functioning of the cybersecurity framework. For example, the entity may only have one
trained employee responsible for managing the VM tool and the unavailability of this employee
may lead to delays in execution of periodic/ planned vulnerability scans. Measures like cross
training, job rotation etc. should be implemented to ensure that fallback employees are identified
(and adequately skilled) to address the single person dependency risk.
Additionally, the licensed entity may consider documenting the job descriptions of all key IT/ OT
security roles in detail. These can become the basis for recruitment and help in ensuring faster
hiring cycle when the need arises. Documented job descriptions would also help in developing
employee skill development programs etc.

CSG-2-2 Segregation of Duties
Conflicting duties shall be identified and distributed among different
Sub control employees to reduce opportunities for unauthorized or unintentional
modification or misuse of the entity’s IT/ OT assets or systems.
The duties and areas of responsibilities of employees should be segregated to reduce the
opportunities for unauthorized or unintentional modification or misuse of the IT/ OT assets.
In cases segregation of duties is not possible, appropriate compensating controls should be
implemented and all such cases should require a formal “risk acceptance” (Refer CSRM-2-3).
The examples of such compensatory controls are monitoring of activities, audit trails,
management supervision and independent reviews etc.
The recommendations for implementing this control are:
i. All processes must adopt the principle of segregation of duties to the maximum extent
possible;
ii. The initiation of an event must be separated from its authorization.;
iii. Employees involved in operational functions must not be given additional responsibilities in
system administration processes and vice versa;
iv. Employees involved in testing processes must not be given additional responsibilities in
system development and vice versa;
v. The responsibility for performing a security review of the system or process should be
completely independent from the roles and responsibilities for developing, maintaining, and
using the system or process; and
vi. The “Role Matrix” (refer IAM-2-1) should consider the potential segregation of duties
conflicts.

CSG-2-3 Contact with Authorities
Sub control Contacts with relevant authorities shall be maintained.
Contacts with authorities should be maintained by appropriate stakeholders. The examples of
such authorities include (but not limited to) law enforcement authorities, fire department,
emergency services, and service providers. The contact details of the relevant agencies should
be maintained and displayed at appropriate places that are accessible to users.
The licensed entity should have procedures in place that specify when and by whom authorities
(e.g., law enforcement, regulatory bodies, supervisory authorities) should be contacted and how
identified IT/ OT security incidents should be reported in a timely manner (e.g., if it is suspected
that laws may have been broken).
The licensed entity is essential for the functioning of the community, society, and economy as a
whole. Operators of such systems should therefore maintain contact with all of the relevant
authorities.
In addition to relevant public departments (e.g., fire service, inspectorates, etc.), this can also
include, for instance:
i. Cooperation initiatives for the protection of critical infrastructures;
ii. Civil defense department and disaster-relief teams; and
iii. Emergency response organizations and personnel.
The licensed entity should ensure that the information received through contacts with authorities
is analyzed and evaluated in the context of the entity by subject matter experts and distributed to
responsible parties within the entity in a timely manner.
During system operation, operational planning, and preparatory work for exceptional situations,
weather information may be required. Direct contact should therefore be established with the
UAE National Centre of Meteorology (e.g., for sandstorm warnings etc.).

CSG-2-4 Contact with Special Interest Groups
Appropriate contacts with special interest groups or other specialist
Sub control
security forums and professional associations shall be maintained.
Membership in special interest groups or forums should be considered as a means to:
i. Improve knowledge about best practices and stay up to date with relevant security
information;
ii. Ensure the understanding of the IT/ OT security environment is current and complete;
iii. Receive early warnings of alerts, advisories and patches pertaining to attacks and
vulnerabilities;
iv. Gain access to specialist IT/ OT security advice;
v. Share and exchange information about new technologies, products, threats, or
vulnerabilities; and
vi. Provide suitable liaison points when dealing with IT/ OT security incidents.
For the purpose of exchanging information on process control-specific security issues and to
facilitate cross-entity cooperation, contact should be maintained with national and international
third party and operator associations and their corresponding working groups dealing with
security issues. The process of information exchange should take into account the applicable
legal context.
The licensed entity should ensure that the information received through contacts with special
interest groups are analyzed and evaluated in the context of the entity by subject matter experts
and distributed to responsible parties within the licensed entity in a timely manner.

CSG-2-5 Document and Record Control Procedure
The licensed entity shall have document and record control procedure
Sub control that ensure appropriate documents and records are created and remain
legible, readily identifiable, stored, protected, and easily retrievable.
The purpose of the ‘Document and Record Control’ procedure is to define the requirements
related to establishing and maintaining the control over IT/ OT security documents and records
within the entity. The Document and Record control procedure would help the licensed entity in
ensuring that it has demonstratable evidence to support that the controls implemented are
operating as desired.
The ‘Document and Record Control’ procedure typically should have the guidance related to:
i. Structure of IT/ OT security documents and records: Like header, footer, page number etc.
to ensure that the documents and records have a consistent format. For example:
• The Header on top of each page should consist of Name of the licensed entity, Document
or Record Title with Latest Version Number;
• The Footer at bottom of each page should contain classification of document or record
(“Public/Internal/Confidential etc.), Page Number; and
• The first page should contain the document or record name.
ii. Naming Convention: to develop a uniform naming convention for IT/ OT security documents
and records, to warrant uniformity amongst different set of documents or records and to
easily identify them;
iii. Document or Records Revision History: Version control, approval, and update control, to
manage the version control for IT/ OT security documents or records. The version control
information that can be recorded is version number, Date (Date of document revision by
document author), Change description (Brief description of nature of changes made to the
document), Author (the author who created or made the change to the document), Approved
By, Approval Date etc. This would help ensure that changes made to the document are
easily identifiable and prevent unintended use of obsolete documents;
iv. Document and Record Control: Each IT/ OT security document and record should have the
ownership information, date of release, owner, security classification (Public, Internal, or
Confidential etc.) ;
v. Document and Record Reference List: Listing of all the documents which are related or
required to understand and follow the document and record;
vi. Document and record storage, retrieval, and disposal requirements; and
vii. Document and record distribution control, to ensure that the distribution of documents is
controlled as per the document classification.

CSG-2-5 Document and Record Control Procedure

Cybersecurity Risk
Management
CSRM
Cybersecurity Risk Management (CSRM)
Objective
To proactively identify risks associated with IT/ OT systems and processing facilities and take
appropriate risk management actions.
Description
A systematic approach to cybersecurity risk management is important to identify and implement

appropriate security measures. This should be aligned with overall enterprise risk management
approach and should be an integral part of all cybersecurity management activities.
CSRM is a continual process that analyses what can go wrong, what are the possible
consequences can be, and their likelihood of occurrence. Basis these, the appropriate risk
management decisions are taken to treat, transfer, terminate or tolerate the risk.
Applicability
this domain.
Cybersecurity Risk Cybersecurity Risk

Management Assessment
Procedure
Cybersecurity
Risk
Management
Cybersecurity Risk Risk Management

Treatment Monitoring and Review

(contd.)
CSRM-1 Cybersecurity Risk Management Procedure
To define a structured and repeatable methodology governing the
Objective
cybersecurity risk management process.
CSRM-1-1 Cybersecurity Risk Management Procedure

Cybersecurity risk management procedure shall be documented,
established, and reviewed periodically, to establish a systematic
approach of identifying the risks, estimating the magnitude of risks (risk
Sub control analysis), the process of comparing the estimated risks against risk
acceptance criteria to determine the significance of the risks (risk
evaluation) and taking appropriate actions to manage the risks (risk
treatment).
CSRM procedure should be aligned with the licensed entity’s other relevant risk management
frameworks and directives and should broadly cover the following aspects:
i. Define risk management methodology/ process (Refer Annexure I: Cybersecurity Risk
Management Process);
ii. Define the scope and boundary of the risk assessments for IT systems and ICS/ OT
systems. To ensure that all relevant assets are taken into account in the risk assessment.
When defining the scope and boundaries, the licensed entity should consider the following
information:
• The entity’s strategic business objectives, strategies and policies;
• Business processes;
• The entity’s functions and structure ;
• Legal, regulatory and contractual requirements applicable to the entity;
• The entity’s CSP;
• The entity’s overall approach to risk management;
• Information assets;
• IT/ OT Systems deployed;
• Locations of the organization and their geographical characteristics;
• Constraints affecting the organization;
• Expectation of stakeholders;
• Socio-cultural environment; and
• Interfaces (i.e. information exchange with the environment).

(contd.)
CSRM-1-1 Cybersecurity Risk Management Procedure
iii. Define approach for risk assessment (Refer Annexure I: Cybersecurity Risk Management
Process);
iv. Define acceptable risk level i.e., risk appetite;
v. Define risk acceptance criteria and process;
vi. Develop a periodic plan for conducting the risk assessments;
vii. Define scenarios where IT/ OT security risk assessments should be conducted (e.g., refer
TPRM-1-2 (Third Party Risk Assessment), AM-2-1 (Induction of Information Assets), CCM-1
(Change Management), CSPM-1(Cybersecurity in Project Management);
viii. Roles and responsibilities related to CSRM; and
ix. CSRM procedure should be reviewed periodically and in case of major changes.
To ensure the uniformity of taxonomy, the licensed entity may also refer to the other existing and
relevant policies/ frameworks like ERM policy that might already be in use in the entity, while
determining the risk scales and terminology for impact and likelihood parameters. For example:
i. If the other existing risk management policies are using a four levels of risks, and the risk
levels being used are low; medium; high; severe, then the same might be adopted for the
CSRM procedure;
ii. If the other existing risk management policies are using a five scale for impact determination
(low, medium, high, very high, catastrophic), the licensed entity may choose to adopt the
same scale; and
iii. If existing policies are using terminology like insignificant, minor, medium, major etc., then
the licensed entity may consider choosing the same terminology. This would help in
uniformity and consistency of risk nomenclature across the entity.
and include them in the CSRM procedure, as applicable, based on the risk assessment.

(contd.)
CSRM-2 Cybersecurity Risk Assessment
Objective To identify, analyze, and evaluate IT/ OT security risks.
CSRM-2-1 Cybersecurity Risk Identification

The licensed entity shall identify its cybersecurity risks associated with
Sub control the loss of confidentiality, integrity, availability and safety of its
information, IT/ OT systems and information processing facilities.
Risk identification is the activity of finding, listing, and characterizing the elements of risk. The
licensed entity can choose the risk identification process that suits its needs.
Broadly, the risk identification process will include the following aspects:
i. Information asset identification;
ii. Identification of threats;
iii. Identification of existing controls;
iv. Identification of vulnerabilities; and
v. Identification of consequences.
In addition to the periodic risk assessments, risks might also be identified during incident root
cause analysis, Business Impact Analysis (BIA) exercise, internal/ external audits, technical
assessments like vulnerability assessments/ penetration testing, through regulatory/ global
advisories etc.
For further guidance about the risk identification process, refer the Annexure I: Cybersecurity
Risk Management Process.
In the ICS/ OT systems cybersecurity risk identification should include safety of employees,
equipment, and plant along with availability, integrity, and confidentiality of ICS/ OT systems.

(contd.)
CSRM-2-2 Cybersecurity Risk Analysis
Identified IT/ OT systems security risks shall be analyzed to identify
Sub control magnitude of its consequences (impact) and the probability of
occurrence (likelihood).
Risk analysis uses the information from the risk identification to understand the levels of risk (risk
ratings). To effectively rate a risk, a risk matrix may be used. This matrix examines the
consequence/ impact level and the probability of occurrence/ likelihood of the risk materializing
(taking into account the effectiveness of existing controls).
The final risk rating should be a function of consequences (impact) and probability of occurrence
(likelihood) and also factor the existing controls.
For further guidance about the risk analysis process refer the Annexure I: Cybersecurity Risk
Management Process.

(contd.)
CSRM-2-3 Cybersecurity Risk Evaluation
Cybersecurity risks shall be prioritized by comparing risk level against
Sub control risk evaluation criteria and risk acceptance criteria.
Risk evaluation assists in making decisions, based on the outcomes of the risk analysis, about
which risks need treatment and the priority for treatment implementation. A risk rating determines
the level of risk posed in terms of consequence and likelihood. Once this rating is determined,
the risk evaluation step determines whether this assessed level of risk is acceptable or not.
Acceptability, or accepted level of “tolerance”, directly relates to the risk appetite of licensed
entity. The licensed entity’s risk appetite will determine the appropriate treatment to be applied.
During the risk evaluation stage, contractual, legal, and regulatory requirements are factors that
should be taken into account in addition to the estimated risks.
For further guidance about the risk evaluation process refer the Annexure I: Cybersecurity Risk
Management Process.

(contd.)
CSRM-3 Cybersecurity Risk Treatment
To identify controls and sub controls and plan appropriate risk treatment
Objective
for the risks that have been assessed.
CSRM-3-1 Cybersecurity Risk Treatment

The licensed entity shall develop, document, and implement risk
Sub control
treatment plans, based on the outcomes of the risk evaluation exercise.
Based on the results of risk evaluation, appropriate decisions regarding risk treatment are
undertaken. The following risk treatment options can be considered:
i. Risk Reduction:
Reducing the risk by applying security controls.
ii. Risk Acceptance:
Accepting the risk based on the entity’s risk accepting criteria established on the information
management risk policy.
iii. Risk Avoidance:
Avoiding the activity or condition causing the risk.
iv. Risk Transfer:
Transferring the risk to another party.
These actions should be clearly mentioned against each Risk to provide a clear indication of risk
mitigation plans. Additional risk treatment may be applied to any risks where it is deemed that
more control over the risk/ activity in question is required.
It is important that risk treatments be identified, prioritized, and implemented via a Risk
Treatment Plan. This Risk Treatment Plan will have the controls/ actions to be implemented, the
timeframes, resources and people responsible for implementation of this treatment.
It is important to specify the relation between the risks and the identified treatment options, this
relationship is important for the ongoing risk management and should be documented in the risk
treatment plan.
Following are key aspects that may be considered while developing the risk treatment plans:
i. The reasons for selection of treatment options;
ii. The controls that have been identified to implement the selected risk treatment options;
iii. The identified risk level that is intended to be achieved by the identified controls;

(contd.)
CSRM-3-1 Cybersecurity Risk Treatment
iv. Who would be accountable for approving the plan;
v. Who would be responsible for implementing controls and the overall plan;
vi. Proposed actions to achieve this implementation;
vii. Priorities of implementation;
viii. Resource requirements including contingencies;
ix. Target dates for control implementation;
x. Interdependencies of control implementation;
xi. Performance measures and constraints; and
xii. Periodic review of risk treatment plan.
The licensed entity can consider assigning a Risk Owner for each identified Risk. Risk Owner is
accountable for ensuring implementation of the risk mitigating controls in accordance with the
Risk Treatment Plan and within the target closure date.
Further, a formal risk acceptance process should also be defined and established to tolerate/
accept risks that are above the licensed entity’s risk appetite. This would be applicable in cases
where owing to technical or operational constrains, it is not feasible to reduce the risk to within
the entity’s risk appetite. The risk acceptance process should include the due diligence required
while accepting risks (like considering compensating controls if feasible) as well as the approval
process (e.g., the Risk Owner’s approval is required to accept the risk and the risk acceptance
has to be endorsed by the CSSC).
The licensed entity can tailor the acceptance process as per their needs.
For further guidance about the risk treatment process refer the Annexure I: Cybersecurity Risk
Management Process.
Note: While making an informed decision about risk acceptance, management should ensured
that it does not lead to violation of any legal, regulatory, or contractual requirement.

(contd.)
CSRM-3-2 Statement of Applicability
The licensed entity shall document the Statement of Applicability,
providing the justification for implementation and exclusion of sub
Sub control controls mentioned in the Department of Energy Cybersecurity
Framework. Any exclusion shall be supported by appropriate
justification and approved by senior management.
Statement of Applicability bridges the risk assessment with risk treatment. The licensed entity
should utilize the “Statement of Applicability” template provided in Annexure XIII, and document
the justification for implementing or not implementing any of the sub controls in this framework. If
any of the sub controls are deemed to be not applicable based on risk assessment, the reasons
justifying the exclusion should be documented. This exclusion should also be approved by
licensed entity’s senior management.
Refer to section 3.4. Statement of Applicability for further details.
Note: The sub control “exclusion” is different than “risk acceptance”. In case of risk acceptance,
if there are certain risks which cannot be mitigated as implementation of the required controls is
not feasible owing to technical or operational constrains, in such cases an informed decision
might be made to accept the risk while giving due consideration to other possible counters
measures and safeguards. Whereas, “exclusion” would signify cases, where a particular sub
control is deemed to be not relevant in the entity’s risk management context.

(contd.)
CSRM-4 Risk Management Monitoring and Review
To monitor and review risks to provide assurance that risks have been
Objective adequately identified, analyzed, and evaluated and that the risks are
well managed by implementing adequate controls.
CSRM-4-1 Risk Management Monitoring and Review
Sub control The IT/ OT security risks shall be continually monitored and reviewed.
Ongoing monitoring and review are necessary to ensure that the context, the outcomes of the
risk assessment as well as treatment plans, remain relevant and appropriate.
The licensed entity should regularly verify that the criteria used to measure the risk and its
elements are still valid and consistent with business objectives, strategies and policies, and that
changes to the business context are taken into consideration adequately during the CSRM
process.
The risk monitoring and review process helps in determining whether procedures adopted, and
information gathered for identifying the risks were appropriate and whether all significant risks
have been identified or not. It also helps to validate that mitigation controls put in place for risks
are appropriate.
Risk Assessment should be performed at least once annually, to address any changes to the
risks affecting the IT/ OT security requirements. The following triggers might also warrant risk
assessments:
i. Major changes which may affect the originally assessed risk levels;
ii. Weak performances of the implemented controls;
iii. Any new vulnerabilities identified;
iv. Any new threat due to evolving threat landscape;
v. Any change in the management’s decision on acceptable level of risk;
vi. Any change to the legal or regulatory requirements;
vii. New assets that have been included in the Risk Management scope;
viii. Increased impact or consequences of assessed threats, vulnerabilities and risks in
aggregation resulting in an unacceptable level of risk; and
ix. Cybersecurity incidents.

Cybersecurity Performance
Evaluation
CSPE
Cybersecurity Performance Evaluation
(CSPE)
Objective
To evaluate that the IT/ OT security controls are designed adequately and are operating as
desired.
Description
It is crucial for the licensed entity to regularly evaluate the controls implemented to ensure that
they are adequate, designed properly and operating as expected. The evaluation should be
carried out by an independent party. Evaluation may be performed by conducting interviews with
the concerned stakeholders, reviewing system settings, performing physical walkthroughs, or
requesting documentation/ artefacts for review. Evaluation should be concluded with assessment
reports to document the nonconformities, and corrective and preventive action plans to address
them.
Applicability
this domain.
Cybersecurity Audit
Management Review
Cybersecurity
Performance
Evaluation
Cybersecurity Audit
Corrective Action Plan Report

Cybersecurity Performance Evaluation (CSPE)
(contd.)
CSPE-1 Security Control Effectiveness
To ensure that cybersecurity controls are adequate, designed
appropriately and are operating as desired, in accordance with the
Objective
organizational policies and procedures, and are aligned with the
Department of Energy Cybersecurity Framework requirements.
CSPE-1-1 Cybersecurity Audit

Annual independent audits to assess the adequacy and effectiveness of
the IT/ OT security controls shall be carried out.
Sub control
These audits shall be conducted in accordance with the Cybersecurity
Audit guidelines published by the Department of Energy.
Cybersecurity audit should be initiated by the licensed entities' management and conducted by
competent independent party, to validate continued suitability, adequacy, and effectiveness of
the licensed entity’s approach to managing IT/ OT security. Following are the considerations that
the entity can refer while implementing this control:
i. Formal procedures should be developed for governing the audit process including (but not
limited to) audit planning, reporting audit findings and ensuring timely and accurate remedial
actions. These audit procedures should be aligned with the Department of Energy –
Cybersecurity Audit (CSA) guidelines;
ii. The audits should be carried out in accordance with the agreed procedures;
iii. The audit should assess the adequacy and effectiveness of entity’s IT/ OT security policies,
procedures, standards, and guidelines;
iv. The audit should also assess the alignment of the entity’s cybersecurity framework with the
Department of Energy Cybersecurity Framework;
v. The audit scope should include all applicable against controls and sub controls of the twenty
(20) domains of the Department of Energy Cybersecurity framework;
vi. Audit requirements and activities involving checks on operational systems should be
carefully planned and agreed with IT/ OT systems’ owner to minimize the risk of disruptions ;
vii. Access to IT/ OT systems audit tools should be protected to prevent any possible misuse or
compromise; and
viii. Results of reviews and corrective actions carried out should be recorded and these records
should be maintained. Any detected non-compliances with the IT/ OT security policies
should be investigated and corrective action should be taken and reviewed.
Refer to Abu Dhabi, Department of Energy Cybersecurity Audit guidelines for further details and
guidance.

(contd.)
CSPE-1-1 Cybersecurity Audit

(contd.)
CSPE-1-2 Management Review
Management shall review the cybersecurity framework at planned
Sub control intervals to ensure its adequacy and effectiveness in meeting the
licensed entity’s cybersecurity objectives.
The management reviews should be conducted periodically (e.g. quarterly) to ensure the
continuing suitability, adequacy and effectiveness of the cybersecurity framework and also to
assess opportunities for improvement and the need for changes in the cybersecurity framework,
including the CSP and objectives.
The licensed entity may establish an CSSC to execute this task i.e. carry out the management
reviews. The general considerations while determining the composition of the CSSC along with
the responsibilities of CSSC have been documented in CSG-2-1 (Cybersecurity Roles and
Responsibilities)
In the periodic management review meetings, the following may be presented for consideration
and review:
i. Status of key IT/ OT security initiatives and projects;
ii. Status of actions from previous CSSC meeting;
iii. Outcome of internal audits, management reviews, security incidents and external audits etc.;
iv. Status of corrective actions;
v. Reporting of IT/ OT Security KPIs;
vi. Results from control effectiveness measurements;
vii. Summary of major IT/ OT security incidents;
viii. Results of risk assessment;
ix. Issues where CSSC support is required;
x. Feedback from interested parties;
xi. Key IT/ OT security trends in the sector and region and any global/ regional IT/ OT security
related developments that might warrant specific actions; and
xii. Other matters requiring the CSSC attention.
The results of the management review should be clearly documented, and records should be
maintained. The outputs of the management review may include decisions related to continual
improvement opportunities and any needs for changes to the cybersecurity framework.

(contd.)
CSPE-1-3 Cybersecurity Audit Report
The licensed entity shall share the report of annual Cybersecurity Audit
Sub control
with Abu Dhabi, Department of Energy.
The Department of Energy has published the report template to ensure uniformity in the
reporting format, use of common taxonomies and nomenclature. The findings of the annual
cybersecurity audit should be documented in the Audit Report Template provided in the
Department of Energy – Cybersecurity Audit Guidelines.
Please refer to Abu Dhabi, Department of Energy Cybersecurity risk audit report template and its
guidelines for more detail.


(contd.)
CSPE-1-4 Corrective Action Plan
The licensed entity shall take appropriate and timely corrective actions
Sub control
to address any non-conformities.
Any non-compliance with the cybersecurity framework should be acted upon to eliminate its
cause and to prevent its recurrence. Corrective actions may be identified from internal/ external
audits, technical security assessments, management review meetings and security incidents etc.
The identified Non-conformance should be analyzed for following:
i. Whether it is a first or a repeat occurrence;
ii. Frequency and history of occurrences (repeated occurrences);
iii. Seriousness of the impact; and
iv. Root cause for the non-conformity.
Basis this analysis, the licensed entity should develop a clear action plan that describes how
identified non-conformities will be addressed, including considerations to prevent it from
reoccurring. The action plan should capture findings, management comments, closure timelines,
and responsibility. The corrective actions identified should be tracked till closure.


Asset Management
AM
Asset Management (AM)
Objective
To identify and classify information assets, and define the storage, handling, and secure disposal
measures to protect the unauthorized access, loss, modification or destruction of data.
Description
Energy sector is witnessing an influx of new asset classes in IT/ OT environment that are
network connected. In order to be effective and supportive of the licensed entity’s business and
security objectives, it is important that asset are securely managed throughout the asset
lifecycle, from procurement through disposal.
Applicability
The applicability of controls and sub controls prescribed in this domain shall be based on the risk
assessment.
Appropriate justification and formal approval from senior management (or relevant management
body like CSSC, Enterprise Risk Management Committee etc.) is required if any of the controls
and sub controls prescribed in this domain are deemed to be “Not Applicable”.
• Removable Media Handling
• Asset Management
Procedure • Information Asset
Classification
Asset
Management
• Information Assets Life • Responsibility for Assets

cycle

Asset Management (AM) (contd.)
AM-1 Asset Management Procedure
To outline the guidelines to identify, classify, store, handle and dispose
Objective
information assets.
AM-1-1 Asset Management Procedure

Asset Management procedure shall be documented, established, and
Sub control reviewed periodically, for the identification, classification, storing,
handling and disposal of information assets.
The AM procedure may take account of the following:
i. Instructions for securely managing information asset during entire asset lifecycle from
induction till decommissioning;
ii. Outline the ownership, roles, and responsibilities;
iii. Provide framework for data classification and protection;
iv. AM procedure should be reviewed periodically and in case of major changes.
Further, the licensed entities may consider the controls and sub controls mentioned in this
domain and include them in the AM procedure, as applicable, based on the risk assessment.

No additional information specific to the ICS/ OT system.

AM-2 Information Assets Life Cycle
To ensure security measures are taken during induction and
Objective
decommission of information assets.
AM-2-1 Induction of Information Assets

Asset induction process shall include security checkpoints to ensure
Sub control that the asset is added in the production environment in a secure
manner and does not introduce any risks.
Ensuring that necessary security validations and checks are made at the asset induction stage
helps ensure that the asset does not support any vulnerabilities that might be exploited. Further,
making these validations at the induction phases helps avoid any operational issues that might
have been faced if changes have to be made in the asset configuration to secure it, after it was
already operational.
Following security checkpoints may be performed during induction of information assets:
i. Hardening of assets as per minimum baseline security standard of that assets type;
ii. Conducting vulnerability assessment to identify missing patches;
iii. Installing applicable security tools (antimalware, End Point Protection (EPP), agents
(Vulnerability scanning agent, Data Loss Prevention (DLP) agent, Network Access Control
(NAC) agent));
iv. Asset has been added in Security Information and Event Management (SIEM) monitoring
scope;
v. Ensuring asset tag/ label has been affixed; and
vi. Asset has been added in the asset inventory.

AM-2-2 Decommissioning of Information Assets
Information assets shall be decommissioning securely when no longer
Sub control
required.
The following guidelines may be considered while decommissioning of information asset:
i. Storage media in hardware assets should be physically destroyed, overwritten multiple times
or degaussed, depending on the sensitivity of the information that was stored in the asset;
ii. Classified paper documents should be disposed securely by incineration or shredding;
iii. Disposal of information assets should be logged to maintain an audit trail;
iv. Removing asset tag;
v. Removing asset from asset inventory; and
vi. Notifying appropriate stakeholders regarding asset decommissioning (e.g. SOC team to
remove it from monitoring scope, vulnerability scanning team to remove it from the VA
schedule/ calendar etc.)

AM-3 Responsibility for Assets
To identify the licensed entity’s information assets and maintain
Objective
appropriate protection responsibilities for assets.
AM-3-1 Inventory of Information Assets

Inventory of assets associated with information and information
Sub control
processing facilities shall be drawn and maintained.
Following guideline may be considered for maintaining inventory:
i. The asset inventory should contain both hardware and software assets;
ii. The inventory should include relevant details related to the assets such as asset owner,
custodian, criticality rating, location, classification etc.
iii. Asset induction and decommissioning/ disposal process should be linked with the asset
inventory update process;
iv. The asset inventory should be accurate, up to date and consistent; and
v. Inventory should be reviewed periodically to identify and address any discrepancies.
The inventory of assets may include process control systems relevant to ICS/ OT systems.
Assets in the ICS/ OT system environment would include a wide range of sector-specific asset
categories such as:
i. Information: Operation and network plans, scheduling, and dispatching data, geographical
and geo referenced information, crisis and emergency plans, ICS/ OT systems disaster
recovery plans, switching operation data, measured values and measurement data, meter
and metered data, operating records, application programming and parameterization data,
measurement and message archives, historical and trend data, etc.
Note: This also includes application programming and parametrization data of digital
controllers and automation components.
ii. Software: Process control software, visualization systems, simulation software,
parameterization software, management and monitoring systems, operational resource
planning systems, programming environments, firmware, archiving, reporting and historian
software, etc.
iii. Physical Assets: Control and automation components, telemetric and telecontrol
components, Remote Terminal Unit (RTU), data transmission system components, digital
protection and safety components, digital metering and measuring devices, smart meters,
and digital sensor, parameterization and programming devices, visualization and
operational components, digital monitoring and recording systems, etc.
iv. Services: Telecommunication services, emergency communication services, information
services, meteorological services, media and news services, time services, etc.
AM-3-2 Ownership of Information Assets
The licensed entity shall assign a designated owner for each
Sub control
information asset in the inventory.
Ownership can be assigned when information assets are created or when assets are transferred
within entity. The information asset owner would be responsible for the proper management of
an asset over the whole asset lifecycle. The information asset owner should ensure:
i. Assets are inventoried;
ii. Assets are appropriately classified and protected;
iii. Define and periodically review access restrictions;
iv. Ensure adequate protection is granted to the asset; and
v. Ensure proper handling when the asset is deleted or destroyed.
The complex structure of organizations that employ ICS/ OT systems means that highly diverse
responsibilities with regard to commercial and operational ownership can exist. As a result, the
ownership, and the responsibilities in relation to assets, and the roles of the asset owner and
asset operator in respect of cybersecurity should be defined and documented.

AM-3-3 Acceptable Use of Assets
Rules for the acceptable use of information assets associated with
Sub control information and information processing facilities shall be identified,
documented, and communicated.
Employees and third party users using or having access to the licensed entity’s assets should be
made aware of the rules of acceptable and unacceptable use of information assets. Users
should be responsible for the use/ misuse of any information assets under their responsibility.
Following rules may be considered in the acceptable use of information assets:
i. Only use information assets they are authorized to use and only in the manner and to the
extent authorized;
ii. Only use accounts, passwords, and/or authentication credentials that they have been
authorized to use for their role at the licensed entity;
iii. Only share data with others as allowed by applicable information classification procedure,
and dependent on their assigned role;
iv. Comply with licensing and contractual agreements related to information assets; and
v. Accept responsibility for the content of their personal communications.
Following rules may be considered as unacceptable use of information assets:
i. Circumvent, attempt to circumvent, or assist another in circumventing the security controls in
place to protect information assets and data;
ii. Knowingly download or install software onto the licensed entity information assets, or use
software applications, which do not meet the licensed entity security requirements, or may
interfere or disrupt service, or do not have a clear business use;
iii. Engage in activities that interfere with or disrupt users, equipment or service; intentionally
distribute viruses or other malicious code; or install software, applications, or hardware that
permits unauthorized access to information assets;
iv. Access information assets for which authorization may be erroneous or inadvertent;
v. Conduct unauthorized scanning of the licensed entity information assets; and
vi. Engage in activities that violate regulations or company policy and code of conduct.

AM-3-4 Return of Assets
All employees and external party users shall return all the information
Sub control assets in their possession upon separation i.e. resignation or
termination, upon transfer or end of contract/agreement.
Return of information assets may be considered during following cases:
i. The employee separation process should include the return of all issued assets owned by
the licensed entity;
ii. The employee transfer process should include the requirement to return all issued assets
owned by the licensed entity that are not required in new roles; and
iii. In cases where an employee or external party user purchases the licensed entity’s
equipment or uses their own personal equipment, procedures should be followed to ensure
that all relevant information is transferred to the licensed entity and securely erased from the
personally owned equipment.

AM-3-5 Host Security
The license entity shall protect host systems and the information they
Sub control
store, transmit, and process against security threats.
The license entity should protect their host systems such servers, workstation, laptop etc. from
malware, unauthorized applications, malicious network traffic, and unauthorized access.
Following steps should be considered to protect the hosts :
i. Install and configure a host-based firewall;
ii. Change or disable any default accounts on the machine;
iii. Ensure strong password;
iv. Regularly update OS patches and hardware firmware patches;
v. Regularly upgrade to latest version of OS and software applications;
vi. Monitor logs on the device;
vii. Disable services and accounts which are not being used;
viii. Replace insecure services (such as telnet, rlogin) with more secure alternatives such as
SSH;
ix. Restrict access to services which cannot be disabled where possible;
x. Create, maintain, and review baseline configuration;
xi. Ensure only whitelisted software is installed on the hosts;
xii. Secure communication ports like USB, CD drive etc.; and
xiii. The browsers should be configured to accept applets only from trusted servers. If this is not
possible, then browsers should be configured to reject the applets. This should be enforced
through Active Directory Group Policy Object (GPO) where feasible.
License entity should automate host protection by implementing EPP solutions. EPP solutions
should have following capabilities:
i. Malware protection with following capabilities:
• Define schedule scan;
• Realtime protection;
• Email scan; and
• Suspicious file quarantine

AM-3-5 Host Security
ii. Firewall protection that protects from port scan detection, Denial of Service (DoS), Media
Access Control (MAC) spoofing, block attacker IP (Internet Protocol) etc.;
iii. Permit installation of only whitelisted applications;
iv. Host control facility to block USB, modification/ deletion of system files etc.; and
v. Auto and manual update of malware signature on all client host.

Following points should be considered during implementation EPP solution in ICS/ OT Systems:
i. Formal agreement with ICS/ OT systems vendor should be taken on EPP software and its
policies before considering EPP for ICS/ OT systems;
ii. EPP policy should be thoroughly tested on non-production system before applying to
production systems; and
iii. EPP policies and signatures updates should be done manually, and auto update facility
should be disabled.

AM-3-6 Software Assets Management
The licensed entity shall establish a formal process to systematically
Sub control track, evaluate and manage software licenses and ensure that only
authorized software are installed.
The key cybersecurity aspect that the Software Asset Management (SAM) process should cover
is related to ensuring that only known, trusted, authorized and licensed software are being used
in the environment.
This can be achieved by having an application whitelist and deploying automated capabilities to
enforce the whitelist. Further, the rights to install the software should be limited based on job
responsibilities.
This process should also include a periodic review of the software installed on various systems
such as servers, databases, end points etc. and ensuring that:
i. There are no violations of licensing agreements;
ii. Software permitted to be used without license for personal use only, are not being used for
commercial purposes;
iii. Freeware are not being used (since vendors providing freeware are not obligated to release
patches in case any vulnerabilities are identified. Further, freeware might have hidden
functionalities/ malwares etc.); and
iv. Enable that the software installed are limited to authorized software based on the licensed
entity policies i.e. approved application whitelist.

AM-3-7 System Obsolescence
The licensed entity shall establish a system obsolesce management
process to keep track of the IT/ OT systems implemented in the
Sub control
environment and upgrade to supported versions when the hardware
and software systems reach end-of-life.
Obsolete systems i.e. systems that are unsupported by the Original Equipment Manufacturer
(OEM), pose an IT/ OT systems risk as, when OEMs discontinue support for a product, they no
longer release patches for security vulnerabilities, operational bug fixes etc. identified in the
product. Therefore, running end-of-life devices subjects an organization to risk of having
systems with known and published vulnerabilities in their production environment, which can be
exploited and lead to cybersecurity breaches. Obsolete systems may also lead to other
operational and maintenance problems like unavailability of spare parts, unavailability of support
in case of breakdown, incompatibility with new systems, etc.
The licensed entity should regularly keep a track of vendor plans to discontinue support for
software and/or hardware products.
Upgrades/ Replacement should be planned for IT/ OT systems that are approaching or have
reached end-of-life status. Where this is not feasible owing to technical/ operational constraints,
following measures may be considered:
i. Patch existing end-of-Life software and hardware technology up to the latest version
possible;
ii. Maintain sufficient spares until end-of-life systems are planned to be operational; and
iii. Isolate end-of-life systems (e.g. from public network and from another internal networks) and
implement appropriate compensatory controls like installing firewall or proxy servers
between end-of-life systems and other systems, use of data-diodes.

AM-3-8 Bring Your Own Device (BYOD) Arrangements
The licensed entity shall develop security controls for the acceptable
Sub control
use of information assets associated with BYOD arrangements.
BYOD refers to the practice of performing work-related activities on personally owned devices.
Devices that can be considered for BYOD are Smartphone, Tablets etc.
Solution like Enterprise Mobility Management (EMM), Mobile Threat Defense (MTD), application
vetting, a Trusted Execution Environment (TEE) supporting secure boot/image authentication,
and Virtual Private Network (VPN) may be implemented to support security controls for BYOD.
Following good practices may be considered for implementing solutions to protect information
associate with BYOD:
i. Detect and protect against installing mobile malware, phishing attempts, and network-based
attacks;
ii. Enforce passcode usage;
iii. Protect the licensed entity data by enabling selective device wipe capability of entity data
and applications;
iv. Protect against the licensed entity data loss by restricting an employee’s ability to copy and
paste, perform a screen capture, or store organizational data in unapproved locations;
v. Provide users with access to protected business resources (e.g., SharePoint, knowledge
bases, application data);
vi. Support executed code authenticity, runtime state integrity, and persistent memory data
confidentiality;
vii. Protect data from eavesdropping while traversing a network; and
viii. Vet the security of mobile applications used for work-related activities.
BYOD devices should not be allowed to connect to ICS/ OT systems and only company owned
and approved devices should be allowed to connect to ICS/ OT systems.

AM-4 Information Asset Classification
To ensure that information assets receives an appropriate level of
Objective
protection in accordance with its criticality to the organization.
AM-4-1 Classification of Information Assets

Information asset shall be classified in terms of its criticality, legal
Sub control requirements, value, sensitivity to unauthorized disclosure or
modification.
The classification criteria can include the followings:
i. Classification and associated protective controls for information asset can take account of
business needs for sharing or restricting information, as well as legal requirements;
ii. Owner of information assets should be accountable for their classification i.e. assigning the
appropriate classification label;
iii. Information asset classification criteria may consider:
• Type of asset;
• Criticality of the asset to business;
• Value of assets depending on their sensitivity and criticality to the organization, e.g., in
terms of confidentiality, integrity and availability; and
• Risk and impact of a security breach or loss of the asset.
iv. The scheme should be consistent across the whole organization so that everyone will
classify information and related assets in the same way, have a common understanding of
protection requirements and apply the appropriate protection;
ICS/ OT systems specific classification criteria can be extended as necessary to include the
followings:
i. Assets, systems, and information supporting the operation of critical infrastructure and
critical assets;
ii. Assets, systems, and information needed for restoration of the operation following a major
disruption, e.g., black start capable systems and components; and
iii. Assets, systems, and information necessary to ensure occupational health and safety, as
well as plant and equipment safety.

AM-4-2 Labelling of Information Assets
Information asset shall be labelled in accordance with the information
Sub control
classification scheme adopted by the licensed entity.
Following guidelines may be considered for labelling information assets:
i. Labelling need to cover information and its related assets in physical and electronic formats;
ii. The labelling should reflect the classification scheme established by the licensed entity. The
labels should be easily recognizable;
iii. Label should indicate how assets needs to be handled; and
iv. Employees and contractors should be made aware of labelling scheme.

AM-4-3 Handling of Information Assets
Information assets shall be handled in accordance with the information
Sub control classification scheme and handling guidelines established by the
licensed entity.
Handling, processing, storing, and communicating of information asset should be consistent with
its classification. The following points may be taken into account while handling information
assets:
i. Access restrictions and handling guidelines supporting the protection requirements for each
level of classification, for each format (hardcopy/ electronic) in which the information may
reside;
ii. The handling guidelines should include guidance for storage, processing, transmission and
disposal of information based on its classification level; and
iii. Protection of temporary or permanent copies of information to a level consistent with the
protection of the original information;

AM-5 Removable Media Handling
To prevent unauthorized disclosure, modification, removal, or
Objective
destruction of information stored on removable media.
AM-5-1 Management of Removable Media

Removable media shall be managed during its whole lifecycle in
Sub control accordance with the classification scheme and handling guidelines
established by the licensed entity.
The following guidelines for the management of removable media may be considered:
i. All removable media should be labelled as per the licensed entity’s classification scheme;
ii. All media can be stored in a safe, secure environment, in accordance with the licensed
entity’s classification scheme and handling guidelines;
iii. If data confidentiality or integrity are important considerations, cryptographic techniques
should be used to protect data on removable media;
iv. If no longer required, the contents of any re-usable media should be made unrecoverable;
v. To mitigate the risk of media degrading while stored data are still needed, the data should be
transferred to fresh media before becoming unreadable;
vi. Multiple copies of critical data should be stored on separate media to further reduce the risk
of coincidental data damage or loss; and
vii. Inventory of removable media should me maintained and reviewed periodically;

AM-5-2 Disposal of Media
Sub control Media shall be disposed of securely when no longer required.
Removable media can be disposed securely to minimize the risk of confidential information
leakage to unauthorized persons. Following recommendation may be considered for removable
media disposal:
i. Media containing confidential information should be disposed of securely by incineration or
shredding, or erasure of data for use by another application within the licensed entity;
ii. Disposal of removable media can be outsourced to suitable external party with adequate
controls; and
iii. Disposal of sensitive items should be logged in order to maintain an audit trail.

AM-5-3 Physical Media Transfer
Media containing information shall be protected against unauthorized
Sub control
access, misuse, or corruption during transportation.
The following recommendation may be considered while transferring media containing sensitive
information:
i. Authorized and reliable transport or couriers should be used;
ii. Procedures to verify the identification of couriers should be developed;
iii. Packaging should be sufficient to protect the contents from any physical damage likely to
arise during transit; and
iv. Logs can be kept, identifying the content of the media, the protection applied as well as
recording the times of transfer to the transit custodians and receipt at the destination.

Backup Management
BM
Backup Management (BM)
Objective
To ensure IT/ OT system data backup is maintained securely, in line with business requirements,
and can be recovered in case of loss or corruption of data.
Description
Data loss events can arise owing to hardware or software failures, data corruption, malware
outbreaks, natural disasters, or accidental deletion. This loss of data can have catastrophic
impact on the licensed entity’s operations and may lead to disruptions.
BM practice protects the licensed entity against such data loss and equips the entity with the
capability to restore the lost data. It entails taking the backup of primary copy of data in one or
more locations, stored in a separate system or medium at pre-determined frequencies (online
synchronization, daily, weekly, monthly etc.), and at different capacities (full, incremental,
differential etc.).
Applicability
assessment.
Procedure
Backup
Strategy
Backup Media
Management
Backup
Management
Backup Media
Storage,
Movement and
Backup Restoration
Disposal
and Testing

Backup Management (BM) (contd.)
BM-1 Backup Management
To ensure IT/ OT system data backup are maintained securely to protect
Objective
the licensed entity against loss of data.
BM-1-1 Backup Management Procedure

Backup management procedure shall be documented, established, and
Sub control reviewed periodically, based on business, cybersecurity requirements
and applicable legal and regulatory requirements.
Following are the key aspects that should be included in the BM procedure:
i. Backup strategy (type, frequency, location, media etc.);
ii. Retention periods;
iii. Guidelines related to Backup Media Storage (BMS), movement, and disposal;
iv. Security requirements of backup data;
v. Moving a copy of backup data to an offsite location;
vi. Restoration testing;
vii. Periodic backup media inventory reviews;
viii. Roles and responsibilities related to BM; and
ix. BM procedure should be reviewed periodically and in case of major changes.
and include them in the BM procedure, as applicable, based on the risk assessment.

BM-1-2 Backup Strategy
Backup strategy for IT/ OT system shall be defined considering the
Sub control business needs, cybersecurity objectives and applicable legal and
regulatory requirements.
The licensed entity can consider the following aspects while devising the backup strategies:
i. The backup strategy should be based on the criticality of data, and the criticality of data
should be determined by the data owner. The data owner can determine the criticality of
data based on the impact of loss, unavailability, and corruption of data on the licensed entity;
and
ii. The backup strategy should be derived from the Recovery Point Objective (RPO) and
aligned with applicable legal and regulatory requirements.
Backup strategy should cover the following details:
i. The type of backup (full, differential, incremental);
ii. Frequency of backup (real time, daily, weekly, monthly, yearly);
iii. Backup mechanism, i.e., online replication, removable media etc.;
iv. Backup media to be used for storage (Storage Area Network (SAN), removable media
(tapes);
v. Transportation methods (e.g., file transfer via the network, physical transportation of
removable backup media);
vi. The locations to be used for storage of backup media and rotation schedules;
vii. Testing/ checks to be performed, such as test-reads, test restores checksums etc.;
viii. Data retention period for each type of data, taking into consideration the legal, regulatory
and compliance requirements if applicable and as per business needs; and
ix. Backing up both business data and system configuration.
In addition to the scheduled the backups, backups may be taken in case any of the major
changes like system upgrades, hardware changes which may affect system etc.
Backup strategy for ICS/ OT systems may consider defining the schedule and methodology of
taking periodic configuration backups of following key systems:
i. Process and bay level devices like Programmable Logic Controller (PLC), numerical relays,
Analog/ Digital Input/ Output cards, analyzers, smart meters, RTU, gateways, Intelligent
Electronic Device (IED), managed switches, routers, multiplexers, firewalls, wireless routers,
safety devices etc.; and
ii. ICS/ OT systems applications like Supervisory Control and Data Acquisition (SCADA),
Distributed Control System (DCS), EMS, Advanced Distribution Management System
(ADMS), Automatic Metering Infrastructure (AMI), Safety Instrumented Systems (SIS) etc.
BM-1-3 Backup Media Management
The media used for taking backups shall be labelled and managed
Sub control securely.
The following measures may be implemented to securely manage the backup media:
i. All backup media should have proper labelling, which can help in tracking and retrieval of
backup media whenever required;
ii. The backup administrator (IT/ OT staff responsible for BM) should ensure that the labelling
on the backup tapes is not tampered with;
iii. The backup media may be labelled and numbered automatically by the backup system or
manually by the IT/OT staff taking the backup. Example format of the label that may be used
is: ‘<Sys>-Friday-1/1-‘On/Off’ (where ‘Sys’ means the relevant ‘System’ , tape number of
number of tapes used for the backup and ‘On’ or ‘Off’ denotes the sites of storage of the
backups – onsite/ offsite);
iv. Backup media should be encrypted if the data contained in the media is confidential, based
on the licensed entity’s data classification scheme. Refer AM-4-1 (Classification of
Information Assets) for details;
v. Backup media register should be developed and maintained to record the media details,
determine the write cycles, and track movement of media;
vi. Expiry date for individual backup media should also be tracked using the backup media
register;
vii. OEM’s instructions must be adhered to with regard to the permissible write cycles. The
backup administrator should document the permissible write cycles for each type of tape in
the backup media register (or in the backup procedure); and
viii. The backup media should be replaced immediately after encountering the error or at
predefined time intervals whichever is earlier.

BM-1-4 Backup Media Storage, Movement and Disposal
Appropriate measures shall be defined and implemented to ensure that
Sub control the backup media is managed securely while in storage, begin
transported or disposed.
The security of backup media is vital, and the licensed entity can consider the below measures
to achieve the same:
Guidelines related to media storage:
i. One copy of backup should be stored offsite and the offsite location for storing backups
should be at a sufficiently safe distance from the primary site;
ii. Backup media should be secured against environmental and physical threats. Adequate
PES controls should be implemented for onsite and offsite backup media. These may
include:
• The backup tapes should be stored in locked fireproof safes in safe custody;
• Access to the fireproof safe should be restricted through appropriate access control
mechanisms;
• Environmental conditions like dust, humidity, fire etc. should be considered while selecting
media storage location; and
• Humidity controls should be in place to protect storage media.
Guidelines related to media movement:
i. The details of backup movement should be captured in backup media movement register
and the same should be updated on every receipt and dispatch of the backup media;
ii. It should be ensured that the backup media are transferred securely to the offsite location.;
iii. The turtle box used for transfer of back up media should be physically secured using
appropriate lock and key mechanisms;
iv. The turtle box used for handling and transportation should have required level of interior
cushion to provide protection to backup media; and
v. Offsite fireproof safe custodian should acknowledge the receipt of tapes (for example: by
sending confirmation e-mail or sign off on media movement form) to the backup
administrator (or IT/ OT staff responsible for backups). The backup administrator should
maintain these records of receipt.
Guidelines related to media disposal:
i. Backup media should be securely disposed once the manufacturer’s expiry date is over,
maximum number of read/ write cycles limit is reached or the media is unusable due to any
other reason;

BM-1-4 Backup Media Storage, Movement and Disposal
ii. Adequate security measures should be taken before disposing the media. While disposing
media, it should be ensured that the media is rendered unrecoverable via a secure wipe
program, degaussing etc. in accordance with industry-accepted standards for secure
deletion, or otherwise by physically destroying the media; and
iii. Destruction of the media must be logged in the backup media register.
Periodic audits of the offsite storage location to ensure back up media are treated in a secure
manner and in line with the requirements of the backup procedure should be conducted. Further,
periodic backup media inventory reviews can also be considered to ensure that all the media is
accounted for (both onsite and offsite).

BM-1-5 Backup Restoration and Testing
Periodic restoration testing of data from backup media shall be
Sub control performed to verify that the backed-up data can be successfully
restored when the need arises.
Following guidelines may be considered for implementing the backup restoration testing
process:
i. Restoration process should verify if the backups can be restored as per defined RPO;
ii. A restoration testing calendar should be documented, and the testing schedule should cover
samples from each backup type and frequency (e.g., samples from daily, weekly, monthly
backups and samples from incremental, differential, full backups etc.);
iii. The restoration tests should be documented detailing the test plan;
iv. The respective system owners should verify the test results at end of the restoration
exercise. Exceptions noted during restoration testing should be reported and corrective
actions taken;
v. Restoration testing should also include testing time constraints of moving backup media
from ‘off-site’ location;
vi. After successful restoration, the backup media should be marked as in ‘Proper Condition’
with the date of testing;
vii. It should be ensured that the restored data is securely deleted from any test systems after
successful completion of testing; and
viii. The records of such restoration tests should be formally documented and retained.


Cloud Security
CS
Cloud Security (CS)
Objective
To implement appropriate safeguards for mitigating risks associated with cloud computing and
usage of cloud services.
Description
The adoption of cloud computing introduces changes in how computing resources are designed,
operated, and governed. While adopting cloud solutions, the licensed entity needs to select a
cloud service, considering the possible gaps between the entity's cybersecurity requirements
and the cybersecurity capabilities of the cloud service provider. Once a cloud service is selected,
the licensed entity should manage the use of the cloud service in such a way that it meets
cybersecurity requirements.
Applicability
assessment.
Cloud Security Hosting of Data in

Policy Cloud Security Cloud Computing
Agreement with
Cloud Service
Provider

Cloud Security (CS) (contd.)
CS-1 Cloud Security
To set controls for mitigating risks associated with cloud computing and
Objective
usage of cloud services.
CS-1-1 Cloud Security Policy

Cloud Security policy shall be documented, established, and periodically
reviewed that enforce guidelines to be followed while adopting and
Sub control
integrating cloud solution to ensure its consistency with the licensed
entity’s acceptable levels of cybersecurity risks.
Following are the key aspects that should be included in the CS policy:
i. Regulatory and other requirements potentially limiting the processing, storage, and retention
of information (including meta data based on risk assessment) by external entities, for
example laws or business agreements preventing information from being processed, stored,
and retained outside national borders and privacy legislation;
ii. Kind of data that is allowed and not allowed to be stored in the cloud in the first place, based
on data classification, as well as how that data should be encrypted and stored;
iii. Encryption requirement for data in rest and transit during cloud computing;
iv. Requirement for redundancy, backup, and availability as per entity’s business continuity and
disaster recovery plan;
v. Requirement for incident management and communication;
vi. Requirement of security controls based on risk assessment of cloud solution implemented;
vii. Contractual requirement with cloud services provider that include Non-Disclosure
Agreement, Data Ownership. Data Location, Service-Level Agreement (SLA), etc.;
viii. Roles and responsibility of administrators related to cloud services management; and
ix. CS policy should be reviewed periodically and in case of major changes.
and include them in the CS policy, as applicable, based on the risk assessment.

CS-1-2 Hosting of Data in Cloud Computing
The licensed entity shall ensure that cloud service provider host their
Sub control information (including meta data based on risk assessment) inside the
boundary of United Arab Emirates (UAE).
The licensed entity should have agreement with cloud service provider to store, process, and
transfer their information (including meta data based on risk assessment) inside the boundary of
UAE. The licensed entity should regularly verify and take confirmation from cloud service
provider for hosting cloud computing data within UAE.

CS-1-3 Agreement with Cloud Service Provider
All relevant legal and cybersecurity requirements shall be established
Sub control
and agreed with cloud service provider.
Agreement with cloud service provider should consider the guidelines mentioned in sub control
TPRM-1-4(Third Party Agreements).
Following cloud specific recommendation should be considered for inclusion in the agreement
with cloud service provider:
i. The agreement should clearly mention the locations of the cloud service provider's
organization and the countries where the cloud service provider will store, transfer, and
process the licensed entity’s data;
ii. The agreement should state ownership of assets like data, applications, OSs, etc. as the
ownership of assets will likely vary depending on the category of the cloud service being
used. E.g., Application software will belong to the cloud service customer when using a
Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) service, whereas for a
Software as a Service (SaaS) service, the application software will belong to the cloud
service provider;
iii. The agreement should mention the backup requirement and cover following aspect of
backup:
• Scope and schedule of backups;
• Backup methods and data formats, including encryption, if relevant;
• Retention periods for backup data;
• Restoration time; and
• Storage location of backups.
iv. The agreement should state the requirement for event logging and mention the
responsibilities of event logging. The responsibilities of the licensed entity and the cloud
service provider for event logging vary depending on the type of cloud service being used.
For example, with IaaS, a cloud service provider's logging responsibility will be limited to that
of cloud computing infrastructure components, and the licensed entity will be responsible for
logging the events of its own virtual machines and applications;
v. The agreement should state roles and responsibilities of the licensed entity and cloud
service provider for identification, notification, and handling of technical vulnerabilities;
vi. The agreement should mention CSIM responsibilities between the licensed entity and the
cloud service provider. It should cover following aspects of incident management:
• The scope of cybersecurity incidents that the cloud service provider will report to the
licensed entity;
• The level of disclosure of the detection of cybersecurity incidents and the associated
responses; and

CS-1-3 Agreement with Cloud Service Provider
• The target timeframe within which information on security incidents will be notified to the
licensed entity.
vii. The agreement should mention the cloud service provider responsibilities to provide the
licensed entity with evidence of its current compliance with applicable legislation and
contractual requirements; and
viii. The agreement should mention the licensed entity rights to review cloud service provider
security controls to verify their compliance with agreement. Where individual entity review is
impractical or can increase risks to cybersecurity, the cloud service provider should provide
report of independent auditor that verify cybersecurity is implemented and operated in
accordance with the cloud service provider's policies and procedures. This should be made
available to the licensed entity prior to entering a contract and regularly when independent
audit is performed.

CS-1-4 Cloud Computing Security Controls
The licensed entity shall regularly perform cybersecurity risk
Sub control assessment of cloud solution and implement necessary security
controls for risk treatment.
The licensed entity should identify and implement security controls based on risk assessment of
cloud solution.
The licensed entity should consider the guidelines mentioned in different sub controls mentioned
in this framework. Following are cloud specific recommendation that may be considered while
implementing security controls:
i. Inventory of Information assets:
The licensed entity’s inventory of assets should account for information and associated
assets stored in the cloud computing environment. The records of the inventory should
indicate where the assets are maintained, e.g., identification of the cloud service. Please
refer to AM-3-1 (Inventory of Information Assets) sub control for more details;
ii. Labelling of Information Assets:
The licensed entity should implement the functionality to label information and associated
assets in cloud computing environment. Please refer to AM-4-2 (Labelling of Information
Assets) sub control for more detail;
iii. Management of Access Rights:
The licensed entity should implement the functionality for managing the access rights of
cloud service users and administrators. Please refer to IAM-2-2 (User Access Provisioning)
and IAM-2-3 (User Access Deprovisioning and Modification) sub controls for more detail;
iv. Cryptographic Controls:
The licensed entity should implement cryptographic controls for its use of cloud services if
justified by the risk assessment. The controls should be of sufficient strength to mitigate the
identified risks. Please refer to CC-1-1 (Cryptographic Controls Policy) sub control for more
detail;
v. Key Management:
The licensed entity should identify the cryptographic keys for each cloud service and
implement procedures for key management. Where cloud service provider provides key
management functionality, entity should request for type of keys and specifications of the
key management system during each stage of the key life cycle. Please refer to Key
Management (CC-2-1) sub control for more detail;
vi. Change Management:
The licensed entity’s change management process should take into account the impact of
any changes made by the cloud service provider. The licensed entity should request for
following information from cloud service provider to determine the effect the changes can
have on cybersecurity:

CS-1-4 Cloud Computing Security Controls
• Categories of changes;
• Planned date and time of the changes;
• Technical description of the changes to the cloud service and underlying systems; and
• Notification of the start and the completion of the changes.
vii. Capacity Management:
The licensed entity should ensure that the agreed capacity provided by the cloud service
meets its requirements. The licensed entity should monitor the use of cloud services, and
forecast their capacity needs, to ensure performance of the cloud services over time. Cloud
services involve resources that are under the control of the cloud service provider and made
available to the cloud service customer under the terms of the master service agreement
and a related SLA. These resources include software, processing hardware, data storage,
and network connectivity;
viii. Network Segmentation:
The licensed entity should define its requirements for segregating networks to achieve
tenant isolation in the shared environment of a cloud service and verify that the cloud service
provider meets those requirements. The licensed entity should have different network zone
for cloud computing and integration with other network zone should be control through
firewall, proxy servers, etc. Please refer to NSM-2-1 (Network Segmentation) sub control for
more detail; and
ix. Penetration Testing (PT):
PT should be performed to assess the Cybersecurity defense capabilities of cloud service
provider.
The licensed entity should perform risk assessment before adopting cloud computing for ICS/
OT systems. Latency of cloud services and its associated networks should be considered for the
applications that require real time access to data. Safety factor should be analyzed before
adopting cloud computing into ICS/ OT systems.

Configuration and Change
Management
CCM
Configuration and Change Management (CCM)
Objective
To govern and manage configurations of and changes to IT/ OT systems in a secure manner,
ensuring that only authorized changes and updates occur in a planned and controlled manner
and integrity of IT/ OT systems is maintained.
Description
As the complexity of IT/ OT systems increases, the complexity of the processes used to maintain
these systems also increases, as does the probability of accidental errors in configuration and
changes. The impact of these errors puts data and systems that may be critical to business
operations at significant risk. Having a CCM process to protect against these risks is vital to the
overall security posture of the licensed entity. The licensed entity need to consider cybersecurity
implications with respect to the development, operation and maintenance of systems including
hardware, software, applications, and documentation.
Applicability
assessment.
Change Configuration & Configuration

Management Change Management
Management

(contd.)
CCM-1 Change Management
To ensure that standardized methods and procedures are used for
Objective efficient and planed handling of all changes, in order to minimize impact
of change-related incidents.
CCM-1-1 Change Management Procedure

Change management procedure shall be documented, established, and
Sub control reviewed periodically based on operational needs and IT/ OT systems
security requirements.
Following are the key aspects that should be included in the change management procedure:
i. Guidelines for change request process;
ii. Requirement to record all changes requested, in Request for Change form;
iii. Define parameters/ criteria to categorize and prioritize the changes;
iv. Requirement to perform change impact analysis to determine the impact of change to
business process and security of IT/ OT systems;
v. Requirement for change approval by CAB or by appropriate authority based on different
criteria like required downtime, impact, resource required, etc.;
vi. Requirement of testing changes before deploying to production systems;
vii. Requirement to develop rollback plan, in case of unsuccessful changes;
viii. Requirement to securely deploy changes and involving all relevant stakeholder;
ix. Process to identify and manage the emergency changes should be defined. Following
aspect of emergency changes should be included:
• Emergency changes identified based on impact and urgency of change requested;
• In case of emergency changes, the concerned security manager should approve the
change and route the change to appropriate implementation team; and
• Emergency changes should be implemented immediately; however the other
documentation and approval formalities should be done retrospectively within defined time
interval of implementing changes.
x. Roles and responsibilities related to configuration and change management; and
xi. CCM procedure should be reviewed periodically and in case of major changes.

(contd.)
CCM-1-1 Change Management Procedure
The licensed entity may also consider establishing a Change Advisory Board (CAB) to review
and approve the deployment of requested changes. CAB should consist of Business Manager,
IT/ OT Manager, Cybersecurity Leader, and representatives from another relevant departments.
The CAB should have the following responsibilities (but not limited to):
i. Ensure that the potential impact of change is acceptable, including the cybersecurity impact
across the IT/ OT infrastructure;
ii. Communication with all stakeholders on critical information about how a given change may
impact the current infrastructure or setup and the risk of the change against not carrying out
the change;
iii. Assess the urgency and priority of the proposed changes;
iv. Ensure that adequate testing has been conducted for all the changes;
v. Ensure that proper roll-back plan including procedures and responsibilities for aborting and
recovering from unsuccessful changes are documented before applying the change; and
vi. Conduct post implementation meetings (where applicable).
and include them in the CCM procedure, as applicable, based on the risk assessment.

(contd.)
CCM-1-2 Change Request and Categorization
All changes in IT/ OT systems shall be recorded through ‘Request for
Sub control
Change’ form (manual or workflow tool based) and shall be categorized.
The ‘Request for Change’ (RFC) form should be used to raise the change requests in IT/ OT
systems. This process of raising change requests using RFC can be through the IT workflow
automation tools or manual using paper forms etc.
The RFC should contain following details:
i. Requestor Name;
ii. Change Description;
iii. Change Type (Chane Category);
iv. Change Reason;
v. Affected Services/ Systems;
vi. Change Urgency; and
vii. Change Impact.
The change requestor should rate the change urgency and impact (Refer Annexure II: Change
Prioritization Guide, for details on change urgency and impact).
Change type/ Category in RFC form will categorize the change and indicate the process to be
followed for implementing the change. Following category of changes may be considered:
i. Normal:
Normal changes are those changes that require a full range of assessment, authorization,
and planning to ensure completeness, accuracy, and the least possible disruption across the
services. In addition, these changes must be scheduled to ensure that, blackout periods are
not violated. The normal type is used when a change can have major impacts on business
process. The normal changes should be approved by CAB.
ii. Standard:
Standard changes are those changes that are preauthorized by CAB or relevant authority
(e.g. line manager of the area impacted by change like Head of Network and
Communications, Head of IT Infrastructure, Head of Applications etc.) and have an accepted
and established implementation procedure. Standard changes are those that are relatively
low-risk or frequently processed changes with known implications; and
iii. Emergency:
An emergency changes are those changes that must be done immediately. It is of such a
high priority and planned scheduling is not required. Emergency change is accelerated
outside of normal processing, which sometimes adds a higher risk.

(contd.)
CCM-1-3 Change Analysis and Approval
Changes shall be analyzed for potential impact on business and
Sub control
cybersecurity and shall be approved by appropriate authority.
Change evaluator should review and confirm the Change Urgency, Impact and Type rating
mentioned in Request for Change form.
Depending on the urgency and impact of the change requested, every RFC form should be
allocated a priority rating (Annexure II: Change Prioritization Guide). The prioritization should be
used to establish the order in which changes should be considered.
If the change evaluator decides to reclassify the change type (e.g. from ‘Normal’ or ‘Standard’ to
‘Emergency’), reclassification details should be updated in the RFC, relevant stakeholder should
be notified. Change impact analysis should be performed to evaluate risks involved and potential
impact. Impact assessment should be done from the following perspectives (but not limited to) :
i. What are the impacts and risks if change is not implemented?
ii. What are the impacts and risks if change is implemented?
Impact assessment should be done considering the following aspects, (not limited to):
i. Risks:
• Financial loss;
• Legal Implication;
• Reputation loss; and
• Operational Disruption .
ii. Impacts:
• Impact on dependent services or configuration items;
• Impact on capacity, availability and continuity;
• Impact on the number of users, services affected/ regions during the time of change;
• Impact on SLA;
• Impact on Security;
• Impact on functionality and performance; and
• Impact on regulatory aspects.
After change impact analysis is performed and change is categorized, relevant approval should
be taken. Following aspects in the approval process should be considered:
i. For ‘Standard’ changes, approval should be taken from CAB or relevant authority for the first
time (i.e. CAB should approve what changes would be deemed as standard for the first
time) and then subsequently the approval may be taken by line managers/ technical leads
etc. without CAB meetings;
ii. For ‘Normal’ changes, approval should be taken from CAB or relevant authority; and
(contd.)
CCM-1-4 Change Deployment
Change shall be tested to validate the change. After testing is
Sub control successful, change shall be securely deployed in production
environment and post implementation, change shall be monitored.
Testing changes in a non production environment prior to deployment in the production allows
the relevant stakeholders to validate that the change will not have any adverse impact on the live
systems. Following process should be considered for testing changes:
i. Test plan and test scenario should be documented and approved by relevant authority;
ii. Testing should be performed in test environment and test result should be documented;
iii. Test environment should sufficiently mirror the production environment and production data
should not be used in the test environment without appropriate masking/ sanitization etc.;
iv. In case of major changes, Factory Acceptance Test (FAT) and Site Acceptance Test (SAT)
should be performed; and
v. The outcome of the testing should be assessed against its expected results and approved
by relevant authority.
After successful testing of change in test environment, change should be securely deployed in
production environment. Following process should be followed for change deployment:
i. Schedule system outage for change deployment, where required;
ii. Develop a roll back plan;
iii. Inform and involve all relevant stakeholders;
iv. Securely deploy changes to systems; and
v. Change implementation status should be communicated to relevant stakeholders.
Following process should be followed post implementation review of changes:
i. Once the change is implemented in the production environment, it needs to be checked
whether the implementation has been successful;
ii. Change completion report should be documented and verified by relevant authority;
iii. Associated system and user documentation, work instructions, and configuration repository/
baselines should be updated; and
iv. In case of major change, training should be provided to relevant users.
In case the change implementation fails, changes should be rolled back and system should be
restored to the previous working state. Following process should be followed for roll back:
i. Verify that the roll back was successful, and the system has been restored to the previous
state before the change was attempted;
ii. Any deviation in the system after rollback should be notified to all relevant parties; and
iii. The reason for the change implementation failure should be assessed, as part of incident
management and lessons learnt should be applied during subsequent or future change
implementations.
(contd.)
CCM-2 Configuration Management
To manage and monitor the configurations of IT/ OT systems securely
Objective and achieve adequate security levels and minimize risks while
supporting the desired business functionality and services.
CCM-2-1 Configuration Management Procedure

Configuration management procedure shall be documented,
Sub control established, and reviewed periodically based on business needs, and
IT/ OT systems security requirements.
There is a significant correlation between Change Management and Configuration Management
processes. Configuration management deals with controlling and monitoring the status of the
configuration items, which make up the IT/ OT infrastructure. Initial configuration of configuration
items should be finalized and approved during installation phase by CAB or other relevant
authorities. Any other subsequent changes in configuration should be processed as per change
management procedure.
The licensed entity should have security focused configuration management procedure to
manage and control the configuration baselines of IT/ OT systems.
Following are the key aspects should be included in the configuration management procedure:
i. Identification:
The objective of this activity is to first prepare a criteria for selecting the configuration item
areas and then to break down the entire IT/ OT infrastructure to the point where each
configuration item in the infrastructure could be uniquely identified and added in
Configuration Management Database (CMDB);
ii. Control:
The objective of this activity is to manage the configuration changes and to maintain secure,
approved baselines. Changes in configuration should be implemented following the change
management procedure to ensure that changes are formally raised, reviewed, analyzed for
security impact, tested, and approved prior to implementation;
iii. Monitor:
Monitoring activities are used as the mechanism to validate that the systems are supporting
approved secure baseline configuration. Monitoring identifies undiscovered/undocumented
system components, insecure configurations, deviations from approved baselines, and
unauthorized changes, all of which, if not addressed, can expose entity to increased risk.
Using automated configuration review tools can help entity to efficiently identify systems not
consistent with the approved baseline configurations and when remediation actions are
necessary;

(contd.)
CCM-2-1 Configuration Management Procedure
iv. Verification:
There may many changes happening in IT/ OT system on frequent basis, hence it is
important to verify the current configurations. Verification of configurations should ensure
that only authorized changes are made in configuration of devices and to verify effectiveness
of baselines. Once the verification is complete the inconsistencies should be recorded, and
necessary corrective action plans should be implemented. The licensed entities can consider
deploying In addition, the licensed entity can use automated tools (e.g. file integrity
monitoring tools) to facilitate situational awareness and alert when changes are made to
approved baseline configurations;
vi. Roles and responsibilities related to configuration management should be defined; and
vii. Configuration management procedure should be reviewed periodically and in case of major
changes.

(contd.)
CCM-2-2 Minimum Baseline Security Standards
The licensed entity shall develop and maintain minimum baseline
Sub control security standards for IT/ OT systems.
Following key aspects should be considered for developing and maintaining in the minimum
baseline security standards:
i. Minimum baselines security standards for all key configuration items should be developed
and maintained. These can be for various databases, operating systems, end points,
network devices, network security devices etc.;
ii. Baseline configurations should be defined and approved by cybersecurity department ,CAB
and other relevant authorities as appropriate;
iii. Baseline configuration should ensure that all unnecessary software / services are removed.
Wherever applicable this includes but not limited to (as applicable):
•OS built in leisure games;
•Device drivers for hardware not included;
•Messaging services;
•Servers or clients for unused internet or remote access services;
•Software compilers (except from non-production, development machines);
•Unused protocols and services;
•Unused administrative utilities, diagnostics, network management and system
management functions;
• Test and sample programs or scripts;
• Unused productivity suites like adobe acrobat, open office, etc.;
• Unlicensed tools and sharewares;
• Universal Plug and Play services; and
• Default accounts.
iv. All approved baseline configurations should be stored in configuration management
database;
v. The asset induction process should include a check to validate that the system being
inducted supports approved baselines;
vi. Periodic hardening/ baseline configuration reviews should be conducted to detect and
remediate deviations from approved baselines; and
vii. Baseline configuration should be regularly reviewed and approved by CAB or relevant
authorities when changes/ updates are to be made.

Cryptography Control
CC
Cryptography Control (CC)
Objective
To streamline the implementation of cryptographic controls and management of secret keys, to

effectively use cryptographic services for protecting the confidentiality, authenticity and/or
integrity of information.
Description
The protection of electronic information and access to information that is stored or is being
transmitted is vital. Cryptography technologies, if implemented effectively can provide a
significant level of protection to information while it is being stored, transmitted or processed.
Applicability
assessment.
Cryptographic Cryptography Key management

Controls Policy Control

Cryptography Control (CC) (contd.)
CC-1 Cryptographic Controls Policy
To protect the confidentiality, authenticity, and integrity of information by
Objective
secure cryptographic means.
CC-1-1 Cryptographic Controls Policy

The licensed entity shall document, establish, and periodically review
the cryptographic controls policy, that contains the requirements for
Sub control
secure implementation of cryptography mechanisms and is aligned with
all relevant agreements, legislations, and national regulations.
A policy on the use of cryptographic controls is necessary to maximize the benefits and minimize
the risks of using cryptographic techniques and to avoid inappropriate or incorrect use. Following
may be considered while developing the cryptographic controls policy:
i. The management approach towards the use of cryptographic controls across the licensed
entity, including the general principles under which business information should be
protected;
ii. Based on a risk assessment, the required level of protection should be identified taking into
account the type, strength and quality of the encryption algorithm required;
iii. The use of encryption for protection of information transported by mobile or removable
media devices or across communication lines;
iv. Requirements to protect external-confidential and internal-confidential (where applicable)
information at rest and transit (over public and private networks);
v. The approach to key management, including methods to deal with the protection of
cryptographic keys and the recovery of encrypted information in the case of lost,
compromised, or damaged keys;
vi. Roles and responsibilities, e.g., who is responsible for:
• The implementation of the policy; and
• The key management, including key generation.
vii. The standards to be adopted for effective implementation throughout the licensed entity ;
viii. The impact of using encrypted information on controls that rely upon content inspection
(e.g., malware detection); and
Further considerations that can be included in the Cryptographic Controls Policy (or the licensed
entity can create a separate Cryptographic Controls Standard) are:

CC-1-1 Cryptographic Controls Policy
i. Documenting the list of approved cryptographic algorithms:
• List of approved hashing algorithms;
• List of approved asymmetric encryption algorithms; and
• List of approved symmetric encryption algorithms.
ii. Secure Transmission of information:
• Sensitive information should be encrypted when sent over external networks. External
networks refer to networks that are not directly managed by the licensed entity;
• Other information sent over internal networks can be encrypted based on risk
assessment;
• Transmission of sensitive and confidential data over external networks should be
authenticated by use of digital certificates; and
• Based on risk assessment, sensitive and confidential information that needs to be
transmitted over internal network, should make use of secure authentication methods,
e.g., using public key cryptography and digital signatures to reduce the risks.
iii. Encrypted data received from an external source should be inspected for the presence of
security threats after decrypting and before it is processed any further.
The Cryptographic Controls Policy should also have guidance to address the instances where
certain systems (owing to legacy issues, technical limitations etc.) cannot adhere to the
requirements of the policy. For example, if a legacy system cannot implement strong encryption
algorithms, appropriate compensating controls should be identified and implemented.
While developing the CC policy, the licensed entity should ensure that it is in compliance with all
relevant agreements, legislations and national regulations.
and include them in the CC policy, as applicable, based on the risk assessment.

CC-2 Key Management
To ensure that cryptographic keys are protected during their whole
Objective lifecycle against unauthorized modification, substitution, unintended
destruction, and loss.
CC-2-1 Key Management Procedure

A Key management procedure shall be defined and implemented to
Sub control ensure protection of cryptography keys during their whole lifecycle.
Appropriate key management requires establishing secure processes for generating, storing,
archiving, retrieving, distributing, retiring, and destroying cryptographic keys. Cryptographic
algorithms, key lengths and usage practices should be selected based on risk assessment and
should be aligned with best practices.
The key management procedure should include the guidelines related to:
i. Generation of keys for different cryptographic systems and different applications;
ii. Issuing and obtaining public key certificates;
iii. Distributing keys to intended entities, including how keys should be activated when received;
iv. Storing keys, including how authorized users obtain access to keys;
v. Changing or updating keys, including rules on when keys should be changed and how this
will be done;
vi. Dealing with compromised keys;
vii. Revoking keys including how keys should be withdrawn or deactivated, e.g., when keys
have been compromised or when a user leaves an organization (in which case keys should
also be archived);
viii. Recovering keys that are lost or corrupted;
ix. Backing up or archiving keys;
x. Destroying keys; and
xi. Logging and auditing of key management related activities.
In case an automated key management system is not available, and the licensed entity has
implemented a manual key management process, for each cryptographic protection scheme
implemented, process for management of the keys should be established which should be
based on Industry accepted standards. The manual process should cover, at minimum the
requirements for:

CC-2-1 Key Management Procedure
i. Key Generation: Generating strong keys;
ii. Key Distribution: Secure distribution of keys;
iii. Key Storage: Secure storage of keys;
iv. Key Substitution: Appropriate handling and substitution of compromised keys;
v. Key Destruction: Secure destruction or retiring old keys; and
vi. Ownership: Responsibilities as key custodians should be identified and documented.


Cybersecurity Continuity
Management
CSCM
Cybersecurity Continuity Management (CSCM)
Objective
To protect critical business processes from the effects of major failures of information systems or
disasters and to ensure their timely resumption in a secure manner.
Description
Information systems have become fundamental to business operations. Hence it necessary for
the licensed entity to maintain the information systems availability and establish capability to
effectively respond to and recover from a disruptive event while continuing to maintain business
critical operations.
The Department of Energy has issued the “BCM Policy for the Energy Sector” policy, to direct
entity holding a license issued by the Department of Energy to develop and maintain a Business
Continuity Management (BCM) Program, in accordance to NCEMA Standard 7000 for BCM, in
order to ensure the continued performance of their prioritized activities (at a minimum) during
and following an Emergency, Crisis, or Disaster.
Thus, the CSCM domain of Department of Energy Cybersecurity Framework should be read in
conjunction with the “BCM Policy for the Energy Sector” policy issued by Department of Energy.
Applicability
assessment.
Cybersecurity Cybersecurity
Continuity Continuity Redundancies
Requirements Management

(contd.)
CSCM-1 Cybersecurity Continuity
To ensure cybersecurity requirement are included in business continuity
Objective
management process.
CSCM-1-1 Cybersecurity Continuity Requirements

Cybersecurity continuity management procedure shall be documented,
established, and reviewed periodically and the licensed entity shall
Sub control determine the requirements for cybersecurity and the continuity of
cybersecurity management in adverse situations, e.g., during a crisis or
disaster.
The licensed entity can consider the following recommendations while identifying the continuity
requirements of the IT/ OT security:
i. The business continuity framework and planning process should include cybersecurity
requirements;
ii. The licensed entity can perform a BIA for cybersecurity function to determine the
cybersecurity requirements;
iii. Cybersecurity requirement during adverse condition should be compared to normal
operational conditions;
iv. Cybersecurity continuity requirements should be explicitly formulated in the BCM or Disaster
Recovery Management (DRM) processes;
Please refer to “BCM Policy for the Energy Sector” released by Abu Dhabi, Department of
Energy for further guidance.

(contd.)
CSCM-1-2 Implementing Cybersecurity Continuity
The licensed entity shall establish, document, implement, and maintain
Sub control processes, procedures, and controls to ensure required level of
continuity for cybersecurity during an adverse situation.
The licensed entity should ensure following for cybersecurity continuity:
i. An adequate management structure is in place to prepare for, mitigate and respond to a
disruptive event using personnel with the necessary authority, experience, and competence;
ii. Incident response personnel with the necessary responsibility, authority, and competence to
manage an incident and maintain cybersecurity are nominated; and
iii. Documented plans, response, and recovery procedures are developed and approved,
detailing how the licensed entity will manage a disruptive event and will maintain its
cybersecurity to a predetermined level, based on management-approved cybersecurity
continuity objectives.
According to the cybersecurity continuity requirements, the licensed entity should establish,
document, implement and maintain:
i. Cybersecurity controls within business continuity or disaster recovery processes,
procedures and supporting systems and tools;
ii. Processes, procedures, and implementation changes to maintain existing cybersecurity
controls during an adverse situation; and
iii. Cybersecurity controls that have been implemented should continue to operate during an
adverse situation. If security controls are not able to continue to secure information, other
compensating controls should be established, implemented, and maintained to maintain an
acceptable level of cybersecurity.

(contd.)
CSCM-1-3 Verify, Review and Evaluate Cybersecurity Continuity
The licensed entity shall regularly verify established and implemented
Sub control
cybersecurity continuity controls to ensure its validity and effectiveness.
Organizational, technical, procedural and process changes, whether in an operational or
continuity context, can lead to changes in cybersecurity continuity requirements. In such cases,
the continuity of processes, procedures and controls for cybersecurity should be reviewed
against these changed requirements.
The licensed entity should verify their cybersecurity continuity by:
i. Exercising and testing the functionality of cybersecurity continuity processes, procedures,
and controls to ensure that they are consistent with the cybersecurity continuity objectives;
ii. Exercising and testing the knowledge and routine to operate cybersecurity continuity
processes, procedures, and controls to ensure that their performance is consistent with the
cybersecurity continuity objectives; and
iii. Reviewing the validity and effectiveness of cybersecurity continuity measures when
information systems, cybersecurity processes, procedures and controls or BCM/DRM
processes and solutions change .
If possible, it is preferable to integrate verification of cybersecurity continuity controls with the
licensed entity business continuity or disaster recovery tests.

(contd.)
CSCM-2 Redundancies
Objective To ensure availability of IT/ OT systems and processing facilities.
CSCM-2-1 Availability of IT/ OT Systems and Processing Facilities

The licensed entity shall implement sufficient redundancy in their IT/ OT
Sub control
systems and processing facilities to meet availability requirements.
The licensed entity should identify business requirements for the availability of IT/ OT systems
and processing facilities.
Where applicable, redundant IT/ OT systems and processing facilities should be tested to
ensure the failover from one component to another component works as intended.
The implementation of redundancies can introduce risks to the integrity or confidentiality of IT/
OT systems and processing facilities, which need to be considered when designing IT/ OT
systems.

Cybersecurity in Project
Management
CSPM
Cybersecurity in Project Management (CSPM)
Objective
To integrate cybersecurity into the licensed entity’s project management and systems
acquisition, development and maintenance practices to ensure that cybersecurity risks are
identified and adequately addressed.
Description
To ensure that the projects are successful in delivering their desired outcomes in a secure
manner, it is important to ensure that cybersecurity is given due consideration in the entire
project lifecycle. Cybersecurity risks and implications should be identified addressed and
reviewed regularly in all projects. Further, Systems Acquisition, Development and Maintenance
practices should include the security requirements such as access control, source code control,
protection from unauthorized modifications and misuse of application data, etc..
Applicability
assessment.
Cybersecurity in Project
Lifecycle
Information System Secure

Operations and Development Policy
Maintenance
Cybersecurity in
Project
Management
Information System Information System

Implementation and Development and
Assessment Acquisition

(contd.)
CSPM-1 Cybersecurity in Project Management
Cybersecurity is integrated into the licensed entity’s project
Objective management methods to ensure that cybersecurity risks are identified
and addressed as part of project lifecycle.
CSPM-1-1 Cybersecurity in Project Lifecycle

Cybersecurity requirements shall be addressed in all stages of project
Sub control lifecycle, regardless of the type of the project, from its initiation to
completion.
The licensed entity should integrate cybersecurity into the licensed entity’s project management
practices and ensure that cybersecurity is part of all phases of the project lifecycle. The project
management methods adopted should require that:
i. Project Objectives:
Cybersecurity objectives are included in project objectives;
ii. Risk Assessment:
The cybersecurity risk assessment is conducted at an early stage of the project to identify
necessary controls;
iii. Involving Cybersecurity:
Involving CST in the project and soliciting their input on potential risks and security
requirements during the planning phase;
iv. Assign Roles and Responsibilities:
Roles and responsibilities of stakeholders for maintaining cybersecurity should be defined,
assigned, and communicated;
v. Secure information sharing and communication with concerned stakeholders; and
vi. Access Management:
Members of the project team should have the access based on their job responsibilities and
their role in the project. Periodic review of access rights can also be considered.

(contd.)
CSPM-1-2 Secure Development Policy
A secure development policy, outlining the rules for the secure
Sub control acquisition, development and maintenance of software and systems
shall be established.
A formal secure development policy helps in ensuring that the systems acquisition, development
and maintenance activities, consider security as their integral part. All software development and
software maintenance activities performed, in-house by the licensed entity, should adhere to the
requirements of the Secure development policy and other applicable and relevant policies,
standards, procedures, and systems development conventions.
The licensed entity can consider the following key aspects while developing the Secure
Development Policy:
i. Cybersecurity Requirements Analysis and Specification:
Security requirements should be identified and documented during the requirements
gathering and analysis phase of acquisition, development or change of systems;
ii. Protecting Application Services Transaction:
Information involved in application services transactions should be protected to prevent
incomplete transmission, misrouting, unauthorized message alteration, unauthorized is
closure, unauthorized message duplication or replay;
iii. System Change Control Procedures:
All changes should follow the licensed entity’s formal change control procedure. Changes
should be appropriately authorized, tested and approved before being implemented in the
production environment;
iv. System Coding Standards:
Secure coding practices should be considered and where relevant mandated for use;
v. Version Control:
Proper versioning should be maintained. Previous versions of software should be retained
as a contingency measure in case a rollback is required;
vi. Secure System Engineering Principles:
Secure system engineering principles should be identified when obtaining security
requirements for new systems or making enhancements to existing systems. These
principles should entail use of secret authentication, data validation, encryption etc. to
ensure appropriate security levels are maintained. Secure information system engineering
principles should be designed into all architecture layers( Business, Data, Applications, and
Technology);

(contd.)
CSPM-1-2 Secure Development Policy
vii. Secure Environments:
Access to test, development, staging etc. environments should be restricted and controlled.
There should be a separation between the production, development, and test environments;
viii. System Security Testing:
Security testing to identify and remediate vulnerabilities should be carried out before rolling
out the systems in production. Tests should also be conducted against the security
requirements identified. Appropriate documentation should be maintained of the test results
and approval;
ix. System Acceptance Testing:
Acceptance criteria for new systems, upgrades and new versions should be defined and
suitable tests of the systems should be carried out prior to actual production deployment.
Acceptance criteria should be defined, and tests should be conducted to validate the criteria;
and
x. Test Environment and Data:
Access to test environment should be given to only those personnel who are involved in
testing and developers should not be given access to the test environment. Production data
should not be used in the test environment. If production data is to be used for testing, it
should be sanitized, and the sensitive information should be replaced with dummy data.


(contd.)
CSPM-1-3 Information System Development and Acquisition
Cybersecurity requirements shall be considered during information
Sub control system design, purchase, programming, development, or enhancement.
Giving due consideration to cybersecurity requirements at the early stages of system
development, while developing, acquiring new systems or making enhancements, ensures that
the appropriate controls are factored at the outset, and thus avoid the complexity and challenge
of having to incorporate the said security requirements in an already procured or developed
product/ service.
Following activities may be considered during information system development:
i. The development actives should adhere to the requirements of the Secure Development
Policy;
ii. Security requirements should be identified and agreed prior to the development and/ or
implementation of information systems;
iii. At the system level, security should be architected and then engineered into the design of
the system; and
iv. Systems should be tested and evaluated prior to being implemented. Tests should be
conducted against the security requirements identified, to ensure that the development
efforts have adequately covered the security control requirements
Considerations for system acquisition:
i. Security specifications should be included in request for proposal/ quotation document for
acquisition of systems or services, that are shared with third party;
ii. The security requirements should be included in the formal agreements/ contracts (Refer
TPRM-1-4 (Third Party Agreements)); and
iii. In case of system acquisition, FAT should be performed to validate that the offered system
complies with the functional and security requirements.
Additional considerations where information system development is outsourced:
i. Licensing arrangements, code ownership and intellectual property rights related to the
outsourced content;
ii. Contractual requirements for secure design, coding, and testing practices;
iii. Acceptance testing for the quality and accuracy of the deliverables;
iv. Provision of evidence that sufficient testing has been applied to guard against the absence
of both intentional and unintentional malicious content upon delivery;

(contd.)
CSPM-1-3 Information System Development and Acquisition
v. Provision of evidence that sufficient testing has been applied to guard against the presence
of known vulnerabilities;
vi. Escrow arrangements;
vii. Contractual right to audit development processes and controls; and
viii. Effective documentation of the build environment used to create deliverables.

(contd.)
CSPM-1-4 Information System Implementation and Assessment
Information systems shall be securely commissioned and shall be
Sub control
tested at site.
Following activities may be considered during information system implementation and
assessment phase:
i. Hardening of information system by removing/ disabling unwanted software, user accounts,
communication ports, unwanted services, changing defaults etc. before rolling to production
environment;
ii. Installing latest patches on the systems and underlying infrastructure (where applicable);
iii. Performing SAT and User Acceptance Test (UAT) to validate information systems
functionality and security controls; and
iv. Securely integrating and rolling out information system to production environment.

(contd.)
CSPM-1-5 Information System Operations and Maintenance
Information system shall be securely put into operation and monitored
Sub control
for continued performance in accordance with security requirements.
Following activities may be considered during information system operations and maintenance
phase:
i. Conduct an operational readiness review;
ii. Defining baseline configuration of system;
iii. Institute processes and procedures for assured operations and continuous monitoring of the
information system’s security controls;
iv. Training of end users, administrators, and maintenance team; and
v. Smooth handover from the project team to maintenance team.

Cybersecurity Incident
Management CSIM
Cybersecurity Incident Management
(CSIM)
Objective
To establish a formal process for timely, effective and orderly response to cybersecurity
incidents.
Description
Incident management process helps in ensuring a timely, orderly, and effective response to
cybersecurity incidents and thus helps to minimize the potential financial, operational, legal or
reputational impacts. Further, applying the lessons learnt in the aftermath of an incident can
enable the licensed entities being better prepared for any future incidents.
Applicability
assessment.
Cybersecurity
Cybersecurity Incident Detection
Incident
Incident and Analysis
Management Plan
Management
Containment,
Eradication, and
Recovery

(CSIM) (contd.)
CSIM-1 Cybersecurity Incident Management Plan
Cybersecurity Incident Management plan will guide the licensed entity’s
Objective
response to cybersecurity incidents.
CSIM-1-1 Cybersecurity Incident Response Plan

Cybersecurity Incident Management plan shall be documented,
Sub control established, and reviewed periodically, to detect and respond to
cybersecurity incidents.
The Incident response plan should provide a structured and coordinated approach for
responding to cybersecurity incidents. The incident response plan should:
i. Define process to handle incidents (refer to Annexure XIV: Cybersecurity Incident Handling
Process)
ii. Contain guidance related to:
• Incident Preparation;
• Incident Detection;
• Incident Analysis;
• Incident Containment;
• Incident Eradication;
• Incident Recovery; and
• Learning from incidents.
ii. Communication with all stakeholders on critical information about how a given change may
impact the current infrastructure or setup and the risk of the change against not carrying out
the change;
iii. Be read and acknowledged by involved internal and external stakeholders;
iv. Contain roles and responsibilities related to CSIM, including the incident response team
composition and responsibilities; and
v. CSIM plan should be reviewed periodically and in case of major changes.
In addition to the Incident Response Plan, the licensed entity may also consider developing
Incident Response Playbooks to support the Incident Response plan. These playbooks may be
developed for potential and probable incidents that might occur in the licensed entity’s
environment and are relevant for its context.

(CSIM) (contd.)
CSIM-1-1 Cybersecurity Incident Response Plan
The Incident Response playbooks provide step wise guidance for detection, analysis,
containment, eradication, recovery, and post-incident activities (aligned with the Incident
Response Plan), for specific type of cybersecurity incidents. They help in ensuring that the
required steps are systematically followed by the incident response team. Examples of incidents
for which the licensed entity can consider developing the Incident Response Playbooks are (but
not limited to):
i. Phishing attack;
ii. Malware outbreak;
iii. Ransomware attack;
iv. Compromised credentials;
v. Password Spray;
vi. DDoS; and
vii. Website defacement.
The playbooks can also aid in conducting the incident response plan testing exercises and
trainings.
Further, all employees and relevant third parties should be made aware of their responsibility as
well as the procedures for reporting different types of incidents that might have an impact on the
cybersecurity. This may be included in the licensed entity’s awareness training program (refer
HRS-3-2 (Cybersecurity Awareness and Training)).
In addition to the general awareness, the incident management plan should also include
requirements to ensure that the sufficient training is imparted to staff assigned with incident
response roles and responsibilities.
and include them in the CSIM plan, as applicable, based on the risk assessment.

(CSIM) (contd.)
CSIM-1-2 Cybersecurity Incident Management Plan Testing
The licensed entity shall periodically test the incident response
Sub control capabilities to determine the overall effectiveness of the incident
response plan.
Testing the incident response plans periodically by conducting testing exercises/ drills and
testing exercises provides the licensed entities the opportunity to identify areas of improvement
as well as deficiencies in the incident response capabilities. These exercises also help in
validating that the incident response plan is aligned with the needs of the licensed entity.
i. Following are key considerations while developing the incident response plans:
• The ideal frequency to conduct these incident response tests is at least once annually;
• The scenarios chosen for testing exercises should be realistic and relevant to the licensed
entity’s context and enact the most appropriate containment strategies;
• The appropriate method of testing like walk-throughs or tabletop exercises, simulations
etc. should be selected;
• The licensed entity may also consider engaging relevant third parties in the exercise; and
• If deemed necessary, the licensed entity may consider notifying relevant stakeholders and
regulators.
ii. The key objectives of the incident response testing exercise are:
• Adequacy of the information response plan to effectively manage cybersecurity incidents;
• To gauge the preparedness to manage cybersecurity incidents;
• Clarity of roles and responsibilities and imparting the knowledge and confidence to
incident response team to successfully manage an incident;
• Impart awareness of different cybersecurity attacks, incidents and appropriate response;
• Enhance coordination between internal and external stakeholders and promote
awareness of which external/internal stakeholders to engage with and when; and
• Validate the adequacy and effectiveness of incident response playbooks.
iii. The post testing exercise discussions may include the following (but not limited to):
• Were the concerned stakeholders aware about their responsibilities ?
• Was the incident response procedure/ playbooks appropriately followed?
• Are there any modifications in the incident response plans/ playbooks required ?

(CSIM) (contd.)
CSIM-1-2 Cybersecurity Incident Management Plan Testing
• Were the required templates and supporting tools (like draft communication messages,
checklists etc.) adequate?
iv. At the conclusion of every test, a detailed test report should be documented covering:
• Exercise objectives;
• Scenario description;
• Anticipated response synopsis;
• Actual response brief;
• Exercise performance evaluation;
• Issues identified, lessons learnt; and
• Incident response plan testing recommendations.

(CSIM) (contd.)
CSIM-1-3 Incident Response Team
The licensed entity shall establish a cybersecurity incident response
Sub control team that directs and manages the incident response process.
Cybersecurity Incident Response Team (CIRT) is responsible for assessing, containing, and
responding to incidents, as well as those responsible for assessing the business and legal
impacts, reporting incidents as appropriate, communicating to internal and external
stakeholders, and engaging with industry and government response partners to coordinate
information and resource sharing when needed.Since incidents can be of varied nature,
following tiered approach for CIRT formation may be considered:
Cybersecurity Incident First Response Team:
This team is the first point of contact and first recipient of reported events.
i. Members:
• IT Technical Response Team or Lead; and
• OT Technical Response Team or Lead.
ii. Responsibilities:
• Conduct initial investigation of reported events;
• Validate whether the reported event is a Cyber Security incident or not and declare the
incident; and
• Notify core CIRT.
Core Cybersecurity Incident Response Team:
This team is the core part of CIRT, and depending on the nature of incidents, it will invite
additional members (internal and/ or external) to assist in the incident response process.
i. Members:
• Manager of IT Technical Response Team;
• Manager of OT Technical Response Team; and
• Chief Information Security Officer;
• Cyber Security Incident Response Manager
• Assess and confirm the First Response Team's declaration of a cyber incident;
• Classify cyber incident;
• Finalized composition of full CIRT and notify full CIRT members;
• Oversee incident investigation, response, and reporting; and
• Elevate the incident and notify the senior management in case of significant incidents.
(CSIM) (contd.)
CSIM-1-3 Incident Response Team
Full Cybersecurity Incident Response Team:
Since the cyber security incidents can be of varied nature and have different characteristics, in
addition of the Core CIRT, additional members might have to be invited to be a part of the CIRT
and assist in the incident response process. The below members are only indicative, and one or
more of these might be included in the CIRT based on the incident type:
i. Members:
• IT Technical Resources;
• OT Technical Resources;
• Vendors;
• Human Resource;
• Legal;
• Finance;
• Internal Communications
• Public Affairs/Communications; and
• Physical Security.
• CIRT members are assigned roles based on department they belong to;
• Arrange additional resources based on the needs of the incident response; and
• Interact with government agencies and other external organizations based on the needs
of the incident response.
Refer to Annexure XV: Cybersecurity Incident Response Team Roles, of the indicative role of
above members who would be invited based on the nature of the incident.

(CSIM) (contd.)
CSIM-2 Incident Detection and Analysis
To ensure that the licensed entity is vigilant to detects the incidents early
Objective and analyses the events to ascertain the severity and devises
appropriate response plan in a timely manner.
CSIM-2-1 Incident Detection

The licensed entity shall monitor different sources of cybersecurity
Sub control alerts in their IT/ OT environments to ensure timely detection of
incidents.
The licensed entity should establish monitoring capabilities that would enable early detection of
cybersecurity incidents and thereby enabling timely response. This can help contain the potential
damage that the incident might have caused.
The incidents may be detected through:
i. Automated detection tools like NAC, firewalls, network-based and host-based Intrusion
Detection System (IDS), IPS, EDR software etc.; and
ii. Manual means, such as theft reported by users, suspicious visitor, signs of unauthorized
access etc.
For incidents that are detected through automated means, there is related guidance provided in
the LM-1-5 (Monitoring Logs). It prescribes employing a facility for proactive monitoring Security
Operation Centre (SOC) technology systems for intrusion attempts, anomalous behavior and
security events using a centralized and automated solution SIEM on a 24*7 basis. To further
enhance the monitoring process, the licensed entity should subscribe to threat intelligence from
credible sources and integrate it with the monitoring process.
In addition, there should be a contact number/ email that is manned 24*7 where the incidents
detected through manual means may be reported. This can be the number of the SOC team, IT/
OT Helpdesk etc.
Only passive scanning and detection solutions should be considered for monitoring ICS/ OT
networks. Risk assessment should be done prior to implementing any active scanning tools or
intrusion prevention solutions in ICS/ OT network as they can impact operations.

(CSIM) (contd.)
CSIM-2-2 Incident Analysis
The reported events shall be analyzed to ascertain whether they qualify
Sub control
as incidents and determine the associated severity and impact.
All reported incidents should be analyzed to validate them. The incident analysis can be a two
stage process, wherein the initial diagnosis stage entails reviewing the existing available
information to validate whether the reported event qualifies as an incident and determine its’
scope, such as:
i. Which networks, systems, or applications are affected;
ii. Who or what originated the incident; and
iii. How the incident is occurring (e.g., what tools or attack methods are being used, what
vulnerabilities are being exploited).
This can then be followed by a more in-depth analysis in collaboration with other concerned
stakeholders. This is to ensure all details relevant to the incident are captured and to decide on
the criticality and impact of the incident and to list the steps to be taken for the recovery.
The incident should be classified, and the licensed entity should consider developing an Incident
Classification Matrix to aid the this activity (Refer to Annexure XVI: Cybersecurity Incident
Classification Matrix). This classification may be based on factors like extent of damage, urgency
for resolution, number of systems effected, type of systems affected (e.g. safety), financial,
reputational, operational, regulatory impacts etc.
The analysis should result into an incident report / first information report. Following aspects may
be captured in the report:
i. Description of the Incident:
• Details regarding the logical and physical events, date and time of incidents, reporting
person and his/her contact details; and
• Determining the impact, scope, and nature of the incident.
ii. Incident Classification;
iii. Damages observed;
iv. Description of symptoms;
v. Affected users/business areas/departments;
vi. Affected service or hardware; and

(CSIM) (contd.)
CSIM-2-2 Incident Analysis
vii. Remedial steps taken:
Any preventing measures like disconnecting system from network, changing administrative
password, applying a new patch that has already been taken.


(CSIM) (contd.)
CSIM-2-3 Collection of Evidence
The process of evidence collection, acquisition, and preservation shall
Sub control
follow documented guidelines.
The evidence collection, acquisition and preservation guidelines may be documented within the
incident response plan or as a separate document depending on the licensed entity’s
requirements.
When the cybersecurity event is first detected, it may not be obvious whether or not the event
will result in legal action. Therefore, the danger exists that necessary evidence might be
destroyed intentionally or accidentally before the seriousness of the incident is realized. To avoid
this, at the analysis phase, the incident response team should start collecting the evidence in a
manner that does not impact its authenticity value.
The collection of evidence for cybersecurity incidents should take into consideration the
following:
i. Admissibility of evidence:
This implies that whether or not the evidence can be used in court. If deemed necessary, the
licensed entity can seek legal advice regarding the admissibility of evidence, depending on
the nature of incident;
ii. Weight of evidence:
This refers to the quality and completeness of the evidence. To achieve weight of evidence,
the quality and completeness of the controls used to correctly and consistently protect the
evidence throughout the period that the evidence to be recovered was stored and processed
should be demonstrated by a strong evidence trail;
General guidelines for collection of evidence are as follows:
i. Paper Documents:
The original is kept securely with a record of the individual who found the document, where
the document was found, when the document was found and who witnessed the discovery;
any investigation should ensure that originals are not tampered with;
ii. Electronic Media:
Mirror images or copies (depending on applicable requirements) of any removable media,
information on hard disks or in memory should be taken to ensure availability; the log of all
actions during the copying process should be kept and the process should be witnessed; the
original media and the log (if this is not possible, at least one mirror image or copy) should
be kept securely and maintaining chain of custody.

(CSIM) (contd.)
CSIM-2-3 Collection of Evidence
Any forensics work should only be performed on copies of the evidential material. The integrity
of all evidential material should be protected. Copying of evidential material should be
supervised by appropriate stakeholders and information on when and where the copying process
was executed, who performed the copying activities and which tools and programs had been
utilized should be logged.

In ICS/ OT systems, collecting evidence can be in conflict with the need of timely system
restoration to meet high availability requirements and ensure safe operation. The licensed entity
should define in which cases and for which systems evidence collection is possible.

(CSIM) (contd.)
CSIM-2-4 Incident Communication
Critical incidents shall be communicated to appropriate internal
Sub control
stakeholders and relevant external parties.
The timely communication of incidents (depending on the severity of the incident) can ensure
that the relevant internal stakeholders are aware regarding incident and are on standby to
provide support if/ when required. Further, timely communication of critical incidents to Abu
Dhabi, Department of Energy can provide an opportunity to relay early warning to other entities
with similar environments.
The incident communication strategy can be included in the licensed entity’s incident response
plan. These can include what must be reported to whom and at what times (e.g., initial
notification, regular status updates). Appropriate stakeholders like authorities such as
government entities (Abu Dhabi, Department of Energy), partners, internal stakeholders,
consumers, and media must be communicated based on the incident severity and direction from
the licensed entity’s senior management.

(CSIM) (contd.)
CSIM-3 Containment, Eradication, and Recovery
To ensure that the licensed entity has established processes to rapidly
Objective contain a reported incident and takes timely actions to recover from the
incident with minimal damage.
CSIM-3-1 Containment, Eradication, and Recovery

The licensed entity incident response team shall take timely actions
Sub control containment, eradication, and recovery strategy for major attack vector
to business-critical IT/ OT systems.
Taking appropriate and timely actions to contain, eradicate and recover from cybersecurity
incidents helps in ensuring that the potential damage that the incident might have caused is
minimized.
Although, the exact containment, eradication and recover steps would vary from incident to
incident, the general guidelines are as follows:
i. Containment:
• Containment is important before an incident overwhelms resources, spreads to multiple
systems or increases damage. It involves containing the incident by isolating
compromised systems to prevent future damage.
• Effective containment provides time for developing a tailored eradication and recovery
strategy.
• An essential part of containment is decision-making (e.g., shut down a system, disconnect
it from a network, disable certain functions). Such decisions are much easier to make if
there are predetermined strategies and procedures for containing the incident.
• These predetermined strategies and procedures can be documented in the Incident
Response Playbooks (refer CSIM-1-1 (Cybersecurity Incident Response Plan))
ii. Eradication and Recovery:
• After an incident has been contained, eradication is necessary to eliminate components of
the incident.
• In recovery, the concerned teams will restore systems to normal operations and confirm
that the systems are functioning normally, and (if applicable) remediate issues caused by
incident following the licensed entity’s change management process

(CSIM) (contd.)
CSIM-3-1 Containment, Eradication, and Recovery Strategy
• Recovery may involve such actions as restoring systems from clean backups, rebuilding
systems from scratch, replacing compromised files with clean versions, installing patches,
changing passwords, and tightening network perimeter security (e.g., firewall rulesets,
boundary router Access Control List (ACL)).
Criteria for determining the appropriate strategy for containment, eradication and recovery may
include:
i. Potential damage to and theft of resources;
ii. Need for evidence preservation;
iii. Service availability (e.g., network connectivity, services provided to external parties);
iv. Time and resources needed to implement the strategy;
v. Effectiveness of the strategy (e.g., partial containment, full containment); and
vi. Duration of the solution (e.g., emergency workaround to be removed in four hours,
temporary workaround to be removed in two weeks, permanent solution).
To further strengthen the process, the licensed entity may consider defining an Escalation Matrix
for incident follow-up and closure. This would require the concerned stakeholders to respond to
incidents notified by SOC Analyst, Incident Response team etc. within agreed timelines. The
response times should be defined based on the criticality of the incident raised. If the incident
reporter (e.g. SOC Team) does not receive the response from the concerned stakeholders within
specified time, the escalations should be executed based on the Escalation Matrix.

(CSIM) (contd.)
CSIM-3-2 Post Incident Review
A post incident review shall be performed after recovery from incidents
Sub control
to identify areas of improvement.
The post incident review/ root cause analysis exercise entails reviewing the actions taken during
the course of the incident resolution and identifying areas of improvement. It involves taking
stock of the incident, analyzing what, how and why it happened, evaluating how well the incident
response plan worked to resolve the issue, and identifying improvements that need to be made
in the Incident Response Plan.
The licensed entity can decide whether to conduct these reviews for incidents of all severity
levels or only for incidents with particular severity levels (e.g. critical/ high only). Ideally way to
conduct this exercise is to convene the meeting of the cybersecurity incident response team
(and other relevant stakeholders) and reviewing the incident’s life-cycle in detail.
The agenda of this meeting can be:
i. Reviewing the timeline of incident lifecycle, from detection to recovery
ii. Identifying root cause of incident;
iii. Evaluate steps performed by staff to handle incident;
iv. Potential damage to resources;
v. Need for evidence preservation;
vi. Appropriateness and effectiveness of the containment plans;
vii. Resources used for containment and whether it was prompt;
viii. Could the containment time improve ;
ix. What resources were available and had they been identified and used adequately;
x. Feedback of relevant stakeholders involved in incident response;
xi. Identifying and initiating preventive actions required to improve cybersecurity program and to
avoid similar cybersecurity incidents in future; and
xii. Making necessary changes in the Incident Response Plan and Playbooks (if deemed
necessary).
The post incident review report should be documented and circulated among relevant
stakeholders (sensitive details can be removed depending on the recipient based on principle of
need to know). All supporting evidence regarding the incident including system or application
logs files, alerts and logs of security devices etc. should be included in the report.

(CSIM) (contd.)
CSIM-3-3 Incident Register
An incident register shall be formally maintained to consolidate the
Sub control information gained from the evaluation of all cybersecurity incidents
during the post incident reviews.
Maintaining a database of security incidents helps in providing a faster response, if the same or
similar security incident gets repeated. This Incident Register/ knowledge base can be a
reference source for incident handling. making decisions regarding need for additional controls,
developing awareness and training programs etc.
An incident number should be allocated to each incident that can be used for incident tracking
and future reference. The Incident Register should include the following details (but not limited
to):
i. Incident ID (Unique ID of the incident)
ii. Date and time of reporting
iii. Method of reporting (Phone/Face to Face/ Email/SOC etc.)
iv. Description of Symptoms
v. Affected systems/ services
vi. Impact
vii. Incident Classification
viii. Activity log : Description of containment, eradication and recovery activities
ix. Teams involved
x. Third parties involved in resolution and recovery
xi. Person in charge

Data Protection and Privacy
DPP
Data Protection and Privacy (DPP)
Objective
To ensure personal data is given due protection, in accordance with the applicable laws and
regulations.
Description
The licensed entity collect and processes personal data to perform essential business functions.
This personal data may be of the entity’s employees or of customers. Breach of personal data
can lead to loss of customers trust and affect entity’s reputation. Hence, the licensed entity must
undertake required due diligence to protect the personal data and to conform to applicable data
privacy related laws and regulations.
Applicability
assessment.
and sub controls prescribed in this domain are deemed to be “Not Applicable”
Data Protection
and Privacy

Data Protection and Privacy (DPP) (contd.)
DPP-1 Personal Data Protection Policy
To protect personal data from unauthorized disclosures and to comply
Objective
with applicable laws and regulations related to data privacy.
DPP-1-1 Personal Data Protection Policy

Personal data protection policy shall be documented, established, and
Sub control reviewed periodically, in accordance with applicable laws and
regulations.
The licensed entity’s personal data protection policy should include following key aspects of
personal data protection:
i. Use, retention, and disposal of personal information;
ii. Processing purpose definition;
iii. Information to be provided to the public and to data subjects and related disclosures/
disclaimers;
iv. Choice and consent of data subjects;
v. Pseudonymization of personal data;
vi. Exercise of the rights by data subjects;
vii. Measures to be taken to ensure personal data security, including access to personal data;
viii. Privacy by design;
ix. Notification of personal data breaches to supervisory authorities and the communication of
such breaches to the data subjects;
x. Process for handling complaints/ grievances related to personal data;
xi. Process to manage personal data breaches;
xii. Roles and responsibilities related to personal data protection policy; and
xiii. Personal data protection policy should be reviewed periodically and in case of major
changes.
Please refer to Annexure III: Personal Data Protection Goals, Annexure IV: Fair Information
Practices, Annexure V: Privacy by Design Principles, and Annexure VI: Personal Data Security
Measures for further guidance on personal data protection requirements. The guidance provided
in the annexures may also be referred to while preparing the personal data protection policy.

Human Resource Security
HRS
Human Resource Security (HRS)
Objective
To ensure that personnel security is implemented to address the risks of human error, theft,
fraud or misuse of information and information processing systems and assist all personnel in
creating a secure working environment
Description
The HRS domain specifies the cybersecurity requirements that need to be integrated in the HR
processes including pre-employment, during employment and after the end of employment of
employees. It also deals with ensuring that all employees and contract staff are aware of their
obligations towards cybersecurity and that their roles and responsibilities are defined in relation
to securing the licensed entity's information and IT/ OT systems.
Applicability
assessment.
and sub controls prescribed in this domain are deemed to be “Not Applicable”
Human Resource Prior to

Security Employment
Procedure
Human
Resources
Security
Employee During
Separation Employment

Human Resources Security (HRS) (contd.)
HRS-1 Human Resource Security Procedure
To lay down documented and approved, procedural guidance to ensure
cybersecurity requirement are considered while managing human
Objective
resource prior to employment, during employment, and during
separation.
HRS-1-1 Human Resource Security Procedure

Human resource security procedure shall be documented, established,
Sub control and reviewed periodically, based on business and cybersecurity
requirements.
The licensed entity may include following key aspects while developing the human resource
security procedure:
i. Roles and responsibility related to human resource management;
ii. Background verification requirement prior to employment;
iii. Including cybersecurity requirement in terms of employment;
iv. Requirement to provide cybersecurity awareness training periodically;
v. Defining disciplinary process;
vi. Defining level of breaches and subsequent level of penalty;
vii. Defining employment separation process;
viii. Including cybersecurity requirement in terms of employee separation; and
ix. Human resource security procedure should be reviewed periodically and in case of major
changes.
and include them in the human resource security procedure, as applicable, based on the risk
assessment.

HRS-2 Prior to Employment
To ensure that personnel security requirements, to be addressed during
Objective the initial stages of employment of new employees and third-party
employees are identified and implemented.
HRS-2-1 Personnel Screening

Background verification checks on all candidates for recruitment
Sub control (employees, contract staff etc.) shall be carried out in accordance with
relevant laws, and regulations.
HR department should perform (by themselves or outsource) background verification checks for
all employees and third parties like third party employees joining the licensed entity to assess
the correctness of the information provided by the candidate.
HR department should check the existing privacy laws and other relevant and applicable
regulations to ensure the permissibility of background checks that can be performed.
The level of checks performed should be proportional to the business requirements, the
classification of the information to be accessed, job role and the perceived risks.
The background checks that may be performed include:
i. Availability of satisfactory character references, e.g., one business and one personal;
ii. A verification (for completeness and accuracy) of the applicant’s curriculum vitae;
iii. Confirmation of claimed academic and professional qualifications;
iv. Independent identity verification (passport or similar document); and
v. More detailed verification, such as credit review or review of criminal records.
Depending on applicable legislation, the candidates should be informed beforehand about the
screening activities.
When an individual is hired for a specific cybersecurity role, the licensed entity should make sure
the candidate:
i. Has the necessary competence to perform the security role; and
ii. Can be trusted to take on the role, especially if the role is critical for the licensed entity.
Where a job, either on initial appointment or on promotion, involves the person having access to
critical IT/ OT systems and/or access to sensitive information, the licensed entity should also
consider further, more detailed checks.
The HR Procedures should define criteria and limitations for verification checks, e.g., who is
eligible to screen people, and how, when, and why verification checks are carried out.

HRS-2-1 Personnel Screening
A screening process should also be carried out for third-party users. Where third party
employees are provided through an agency, the contract with the agency should clearly specify
the agency’s responsibilities for screening and the notification procedures they need to follow if
screening has not been completed or if the results give cause for doubt or concern.
In the same way, the agreement with the third party should clearly specify all responsibilities and
notification procedures for screening.
Results of background checks and associated information collected should be kept confidential
to personnel directly involved in the recruitment process and be handled with due consideration
to applicable laws regulation.

A stricter screening process may be considered for key personnel that would have access to
critical assets or would be responsible for the operations and maintenance processes of critical
ICS/ OT systems. Before prospective personnel are permitted to work on components that form
part of the critical ICS/ OT systems, a specific security clearance provided by governmental
agencies may be conducted, as permitted by the appropriate local laws and legislations.

HRS-2-2 Terms and Conditions of Employment
The employees and contract employee must understand, agree and
Sub control sign the terms and conditions of their employment contract, which shall
state their and the licensed entity’s responsibilities for cybersecurity.
HR Department should ensure that licensed entity’s terms and conditions of employment are
mentioned in the Appointment Letter/ Employment Contract.
Terms and conditions of employment may include the following cybersecurity considerations:
i. Cybersecurity responsibilities of an individual while working for the licensed entity;
ii. Code of conduct and ethics whilst being employed;
iii. Responsibilities to be followed after separation (e.g., till a defined period employee should
not disclose the licensed entity’s information during and after the employment);
iv. Disciplinary actions that will be taken if the employee disregards the terms and conditions ;
and
v. Requirement that the individual will adhere to the licensed entity’s Cybersecurity Policies,
and failure to do so will result in a disciplinary action.
Further, the Cybersecurity awareness initiatives (induction training, ongoing awareness
campaigns etc.) can also include mandatory briefing sessions (or awareness through emailers,
posters, screensavers etc.) for employees and third parties, regarding their cybersecurity
responsibilities that are part of the terms and condition, and any violation (willful or through
negligence) can lead to disciplinary actions.
For third party contractual staff, to be granted access to sensitive information or critical systems,
the third party, with which the third party is associated, may be mandated to enter into
contractual arrangements on behalf of the contracted staff.
The licensed entity may consider inclusion of appropriate terms or conditions in the employment
contracts of roles tasked with management of critical ICS/ OT systems, that they would be
required to work beyond normal working hours in emergency situations, taking into consideration
the applicable legal requirements.
Agreements on the monitoring and recording of specific actions, such as control operations or
programming and parameterization access, should also be taken into consideration when
formulating the contract of employment for staff that would be involved in operations and
maintenance of critical infrastructure.

HRS-3 During Employment
To ensure that employees and contract staff are aware of and fulfil their
Objective
cybersecurity responsibilities.
HRS-3-1 Management Responsibilities

Management shall require all employees and third party to apply
Sub control cybersecurity in accordance with the established policies and
procedures of the licensed entity.
Management can consider implementing the following measures to ensure that employees and
contract staff:
i. Are properly briefed on their cybersecurity roles and responsibilities prior to being granted
access to confidential information or IT/ OT systems;
ii. Are guided about cybersecurity expectations of their role within the licensed entity;
iii. Achieve a level of awareness on cybersecurity relevant to their roles and responsibilities
within the licensed entity;
iv. Conform to the terms and conditions of employment, which includes the licensed entity’s
CSP and appropriate methods of working;
v. Continue to have the appropriate skills and qualifications; and
vi. Are provided with an anonymous reporting channel to report violations of cybersecurity
policies or procedures.
Further, the management should also establish, and “Acceptable Usage Policy” and all
employees and contract staff should be required to read, accept, and sign on the policy prior to
provisioning any access. Refer AM-3-3 (Acceptable and Unacceptable Use of Assets) for further
implementation guidance regarding ideal constituents of this policy.

HRS-3-2 Cybersecurity Awareness and Training
Cybersecurity related awareness and training shall be imparted to
Sub control sensitize personnel about cybersecurity, as relevant for their job
function.
The cybersecurity awareness program should be established in line with the licensed entity’s
cybersecurity policies and relevant procedures.
The general guidelines that may be considered while developing the awareness and training
program are as follows:
i. Awareness training should be conducted taking into consideration the employees’ roles in
the licensed entity;
ii. Awareness training should be made mandatory, and staff should be required to complete the
training as per schedule;
iii. The awareness training should also be updated regularly so it stays in line with the licensed
entity policies;
iv. The awareness program should include a number of awareness-raising activities such as
campaigns (e.g., an “cybersecurity day”) and issuing booklets or newsletters;
v. Awareness training can use different delivery media including classroom-based, web-based,
self-paced and others. Further the awareness can also be imparted through screensavers,
posters, emailers etc. ;
vi. Cybersecurity awareness should be an ongoing exercise and cover all users having access
to the licensed entity’s information (staff and relevant third parties);
vii. Awareness training should be provided as part of a formal induction program for new joiners.
It should be designed to introduce the licensed entity’s Cybersecurity Policies and
Procedures and expectations before access to information is granted;
viii. Awareness training should cover making staff aware regarding their responsibility to become
familiar with and comply with the licensed entity’s cybersecurity rules, as defined in policies,
standards, contracts, and agreements;
ix. Educating staff about personal accountability for one’s own actions and inactions, and
general responsibilities towards securing or protecting information belonging to the licensed
entity and external parties; and
x. Educating staff about contact points and resources for additional information and advice on
cybersecurity matters, including additional cybersecurity education and training materials.
Further, for the staff assigned with cybersecurity roles, role-based trainings should be provided
to identified personnel, to ensure that they have the desired skill set to impart their
responsibilities effectively.
No additional information specific to ICS/ OT Systems.

HRS-3-3 Disciplinary Process
There shall be a formal disciplinary process in place to take action
Sub control against employees and contract staff who have violated any of the
requirements of the entity’s CSP.
The entity can consider the following aspects with developing the disciplinary process:
i. Level of severity of breaches and level of penalty associated with it should be specified;
ii. A complete investigation should be conducted before disciplinary process is invoked:
• The formal disciplinary process should ensure correct and fair treatment for employees
who are suspected of committing breaches of cybersecurity;
• The formal disciplinary process should take into consideration factors such as the nature
and gravity of the breach and its impact on business, whether or not this is a first or
repeat offence, whether or not the violator was properly trained, relevant legislation,
business contracts and other factors as required;
• The disciplinary process should also be used as a deterrent to prevent employees from
violating the organization’s cybersecurity policies and procedures and any other
cybersecurity breaches; and
• Deliberate breaches may require immediate actions.
iii. The disciplinary process may include:
• Reprimand / Verbal warning: The supervisor and authorized manager should have a
formal communication with the employee / contractor / sub-contractor/ partners regarding
any violations done by them;
• Written warning: It should include the performance or conduct deficiencies, omissions or
issues that are basis of the warning, specific performance or conduct to be made within a
specified time frame and the consequences of failing to make the required improved
performance or conduct;
• Demotion: It should include demotion on job role or pay for the employee/ sub-contractor/
partners for unsatisfactory job performance or unacceptable personal conduct, following
an incident for which the employee/ sub-contractor/ partner has received at least one prior
warning or disciplinary action; and
• Dismissal: It should include dismissal for the employee / sub-contractor / partners for
unsatisfactory job performance or unacceptable personal conduct, following an incident
for which the employee/ sub-contractor/ partner has received at least two prior warnings
or other disciplinary action.
No additional information specific to ICS/ OT Systems.

HRS-4 Employee Separation
To ensure that Cybersecurity roles and responsibilities which shall be
Objective valid after separation of employee are integrated with the employment
separation process.
HRS-4-1 Post-Employment Responsibilities

Cybersecurity responsibilities that remain valid after separation of
Sub control employee shall be defined and enforced through formal contracts.
Employee separation can occur on account of employee’s resignation or termination.
The licensed entity can consider inclusion of the below aspects in the employee separation
process, to implement this control:
i. All departing personnel should be explained explicitly that all confidentiality agreements
remain in force and that no information obtained in the course of his/ her work may be
disclosed;
ii. Responsibilities and duties that still valid after employee separation should be contained in
the employee’s or third-party’s terms and conditions of employment. As part of the exit
interview, the departing employees should be made aware that they have signed an
agreement (Refer HRS-2-2 (Terms and Conditions of Employment))that remains valid even
after employee separation; and
iii. Obtaining written undertaking from the departing employee, stating that he/she should not
disclose any confidential information.

HRS-4-2 Employee Separation Process
The licensed entity shall define and implement to ensure that the
access rights are revoked, and assets are returned as part of the
Sub control
employee or contract staff, upon employee separation, or termination of
contract or agreement.
Employee separation process may include following:
i. Formal communication between HR, IT/ OT, and other relevant departments of the licensed
entity about separation of employees and contract staff. This would enable all concerned
stakeholders to take appropriate actions in a timely manner;
ii. Notification from the HR/ line manager to IT/ OT sections about the last working day;
iii. Ensuring all IT/ OT system user accounts related to separating employee are disabled at the
end of last working day;
iv. The account password must be changed promptly whenever individuals accessing the
account are terminated for any reason or are transferred to a role that does not require
access (IAM-5-2); and
v. Ensuring all entity’s IT/ OT assets are returned by separating employee as per entity asset
management procedure before clearing employee dues and providing reliving certificate.

Identity Access Management IAM
Identity Access Management (IAM)
Objective
The objective of the IAM practice is to prevent unauthorized access to information assets by
implementing appropriate authentication, authorization, and accountability controls, covering
both user and system accounts.
Description
IAM is a crucial component for the licensed entity's cybersecurity and entails controls related to
controlling access to the enterprise assets that users and systems have rights to in the given
context. IAM includes provisioning of access to new users and systems, strong authentication
controls, granting access based on principles of ‘need to know’ and ‘least privileges’,
deprovisioning of access in a timely manner, logging the actions taken on systems to ensure
accountability and non-repudiation etc.
Applicability
assessment.
Identification and User Access

Access Control Management
Procedure
Identity Access
Management
User Responsibilities System and Application

Access Control

Identity Access Management (IAM) (contd.)
IAM-1 Identification and Access Management Procedure
To lay down documented and approved, procedural guidance to manage
Objective
access to information and IT/ OT systems critical to business.
IAM-1-1 Identification and Access Management Procedure

Identity and Access Management procedure shall be documented,
Sub control established, and reviewed periodically, based on business and
cybersecurity requirements.
The licensed entity may include following key aspects while developing the IAM procedure:
i. Procedural steps related to provisioning, deprovisioning and modification of access rights;
ii. Mandate the requirement-of-granting access based on job responsibilities and considering
segregation of duties while assigning roles;
iii. Requirements of formal approval for granting access rights;
iv. Requirements to revoke or modify access in case of employee separation (resignation or
termination) or transfers/ role changes in a timely manner;
v. Requirements for periodic review of access rights;
vi. Requirements related to security of generic and system accounts;
vii. Requirements related to remote access;
viii. Requirements related to having robust authentication parameters (passwords);
ix. Requirements related to controlling privileged accounts and periodic review of activities
performed by users having privileged access;
x. Requirements related to logging of user activities to establish accountability; and
xi. Roles and responsibilities related to IAM process.
and include them in the IAM procedure, as applicable, based on the risk assessment.
The IAM procedure for ICS/ OT systems may take into consideration the following key aspects:
i. Requirements of having separate accounts and access rights for IT systems and ICS/ OT
systems for all users having access to both IT systems and ICS/ OT systems;
ii. Supplementary measures/ compensatory controls pertaining to usage of generics accounts,
where the use of personal user accounts is not possible in ICS/ OT systems;
iii. Supplementary measures/ compensatory controls to address the risk for systems that do not
support the capability of enforcing strong passwords; and

IAM-1-1 Identification and Access Management Procedure
iv. Establishing the process for employees and third-party to override security controls for
selected ICS/ OT systems in declared emergency situations.

IAM-2 User Access Management
To ensure that access is provisioned, deprovisioned and modified in a
Objective
secure manner.
IAM-2-1 Role Matrix

Role matrix shall be developed to map systems roles that are required
Sub control for performing a job function based on the principle of least privilege
and segregation of duties.
Following guidelines may be considered while developing and maintaining role matrix:
i. Access rights should be provided to the user based on the principles of least privilege to
achieve the desired job function;
ii. The concerned stakeholders (e.g., cybersecurity department along with the help of
department head/ section heads) should identify the system access rights associated with
operating systems, applications, historian databases, network elements etc. used within
various department/ sections and map these system access rights with the job roles of the
personnel involved in operations to develop and document the Role Matrix;
iii. While developing the Role Matrix, it should be ensured that conflicting access rights that can
lead to violation of segregation of duties are not assigned to the same role;
iv. Appropriate stakeholders (e.g., department head/ section head) should review and approve
the Role Matrix; and
v. Role matrix should be updated by system administrators/ application administrators/ network
administrators in the following scenarios:
• When an IT/ OT system undergoes a major change or new module, or functionality is
added;
• A new role is created; and
• Role is changed.

IAM-2-2 User Access Provisioning
A formal user access provisioning process shall be implemented to
Sub control
grant access to all systems and services.
The access provisioning process for granting access rights may include:
i. Obtaining formal approval from the owner of the IT/ OT system or service before granting
the access to IT/ OT system or service;
ii. Verifying that the level of access granted is in line with the person’s job responsibilities and
based on principles of need to know and least privileges. The ‘Role Matrix’ described in
control IAM-2-1 may be referred to ensure that the access being granted is commensurate
with job responsibilities;
iii. Using unique user IDs to enable users to be linked and held accountable for their actions;
iv. Maintaining a central record of access rights granted to a user ID, across all systems and
services;
v. Privileged access rights should be assigned to a user ID different from those used for
regular business activities. Regular business activities should not be performed from
privileged ID; and
vi. Ensuring that redundant user IDs are not issued to other users.

IAM-2-3 User Access Deprovisioning and Modification
The licensed entity shall implement a formal access deprovisioning and
Sub control
modification process.
The access deprovisioning and modification process to revoke or modify access may include:
i. Adapting access rights of users who have changed roles, to ensure that the access granted
is commensurate with the job responsibilities of the new role; and
ii. Disabling the system accounts of user who has resigned or has been terminated in a timely
manner.


IAM-2-4 Periodic User Access Review
The licensed entity shall establish a process to review user access
Sub control rights periodically and the records of the review performed shall be
formally retained.
The periodic user access review process may include the activities:
i. Extracting the list of active user accounts from systems and validating that accounts of
separated employees (transferred, resigned, or terminated) have been disabled;
ii. Reviewing the dormant/ inactive accounts and requesting the appropriate stakeholders (e.g.,
department heads or section heads) to validate that the accounts are still required;
iii. Reviewing the active generic and system accounts and ensuring that appropriate approvals
and justification is available for each;
iv. Reviewing the users having remote access;
v. Requesting the appropriate stakeholders to validate that the system roles assigned to
employees in their departments/ sections are appropriate and in line with the employee’s job
responsibilities;
vi. Authorizations for privileged access rights (verifying the appropriateness of the employees
assigned privileged roles in the systems) should be reviewed at more frequent intervals to
ensure that unauthorized privileges have not been obtained; and
vii. The periodic access review process may also include periodically reviewing the actions
performed by users having privileged access.

IAM-2-5 Generic and Shared Account Management
Generic and shared user accounts shall be strictly controlled to protect
Sub control against unauthorized access and manage the accountability risk
associated with their use.
Following guidelines may be considered for management of generic and shared user accounts:
i. Where feasible, the default generic accounts should be disabled;
ii. The generic and shared user accounts should be strictly limited and used only if the
individual account is not usable;
iii. Where feasible, a designated owner must be assigned to the generic accounts, who would
be accountable for actions taken by the generic account. This would address the
accountability risk associated with the use of generic IDs;
iv. Where a generic account needs to be created for business or operational reasons, a short
description of the justification for creation of the account should be documented. The
requests for creation of generic accounts should be reviewed and approved by appropriate
stakeholders (e.g., system owner, section head, head of cybersecurity/ OT Security section
etc.);
v. Where a generic account needs to be created for business or operational reasons, the
privileges assigned to the generic account should be restricted only to those required to
perform the required task, any unnecessary authorizations assigned to such accounts
should be removed (where feasible);
vi. Each system owner must maintain a documentation of all active generic accounts in his/ her
system and the list of individuals who have current access to the generic accounts;
vii. The account password must be changed promptly whenever individuals accessing the
account are terminated for any reason or are transferred to a role that does not require
access;
viii. As an additional counter measure, depending on the risk assessment and threat profile of
the system, the licensed entity can consider changing the password of the generic accounts
at a higher frequency; and
ix. The periodic user access review should include reviewing the active generic accounts for
appropriateness of access and ongoing need.

IAM-2-6 Teleworking
The licensed entity shall implement adequate security measures to
Sub control protect information accessed, processed, and stored at teleworking
sites.
Telework refers to an arrangement where an employee works from home or from another
location away from the usual workplace. It can encompass a variety of working arrangements,
including working from home, telecentres and satellite offices etc.
The licensed entities that permit teleworking, should document and establish a policy that
defines the security measures, conditions and restrictions for teleworking. The objective of this
policy should be to ensure that cybersecurity risks, related to specific teleworking scenarios, are
identified, assessed and managed. The safeguards to protect information accessed, processed,
or stored in a teleworking environment should consider factors such as:
i. Who would be permitted to telework:
Identify the roles which may be authorized for teleworking.
ii. Which services would be available for teleworkers:
The types of network and application services which may be provided to teleworkers.
iii. Access:
• An approval process for providing access for teleworking should be developed and
implemented; and
• Teleworking request should be allowed only for a fixed duration and access should be
disabled automatically post the expiry period.
iv. Equipment and software specifications:
• Employ thin clients/ virtual desktops which prevent information processing and storing on
private equipment for teleworkers where feasible;
• Specific equipment or software products which must be deployed on the teleworker's
computer (e.g., firewall, antimalware, encryption software etc.); and
• Secure configuration of devices and systems.
v. Information restrictions:
Classified information which should not be made available to teleworkers
vi. Identification/authentication/authorization:
Identification, authentication and authorization of teleworkers before granting access to
entity resources.
Connection to the remote system should be secure (i.e. through VPN).
vii. Maintenance guidelines:
Process for protecting, updating and monitoring Teleworker's computer configuration.

IAM-2-6 Teleworking
viii. User guidelines:
Clarifying the user's role in protecting entity resources e.g., acceptable use of resources;
user should not modify security configurations; use of antivirus software; storage of entity
data on local drives; use of encryption tools etc. Teleworkers who are approved to work from
remote locations must sign an agreement (acceptable usage policy) to abide by remote work
policies. The agreement should be reviewed annually.
ix. User awareness:
Ensuring that telework users understand the potential risks associated with teleworking, how
those risks can be addressed, and the user's role in minimizing the risks.
x. Teleworker working environments:
Structuring of teleworker environment to be in compliance with all licensed entity’s policies
and standards.
xi. Intellectual Property Rights:
Ownership of the software and all files and databases should remain the property of the
licensed entity. All software copyright laws will be strictly adhered to; in no instances will
unauthorized copies be made of the licensed entity owned software. Further, information/
documents prepared as part of the teleworking arrangements shall remain the property of
the licensed entity, unless stated otherwise in relevant agreements signed with the telework
staff.

IAM-2-7 System Account Management
Access to system accounts (also known as service accounts) shall be
Sub control
strictly controlled to protect against unauthorized access.
Following guidelines may be considered for management of system accounts (also known as
service accounts):
i. The default system accounts that are not required should be disabled;
ii. The default password of the service account should be changed before installation;
iii. Each system owner must maintain a documentation of all active system accounts in his/ her
system along with justification of the need of such accounts;
iv. The passwords of service accounts should not be known to any user, this can be enforced
manually by setting the password using split knowledge principle or using automated
solutions such as Privileged Access Management (PAM);
v. System administrators should not use their personal accounts as service accounts;
vi. Each service account should only be granted privileges/ permissions that are required to
perform the task (least privilege);
vii. Where technically feasible, interactive logins for service accounts should be disabled;
viii. The use of system accounts should be monitored; and
ix. The periodic user access review should include reviewing the active system accounts for
appropriateness of access and ongoing need.

IAM-3 System and Application Access Control
Objective To prevent unauthorized access to IT/ OT systems and applications.
IAM-3-1 Access Restriction

Access to information and application system functions shall be
Sub control
restricted.
The following may be considered to support access restriction requirements. These control
features should typically be included in the design of the applications:
i. Controlling which function can be accessed by a particular user;
ii. Providing menus to control access to application system functions;
iii. Controlling the access rights of users, e.g., read, write, delete, and execute based on job
responsibilities;
iv. Controlling the access rights of other applications;
v. Limiting the information contained in outputs;
vi. Providing logical and physical access controls for the isolation of sensitive applications,
application data, or systems; and
vii. Limiting the information contained in outputs.


IAM-3-2 Secure Log-on Procedures
Access to systems and applications shall be controlled by a secure log-
Sub control
on procedures to verify the claimed identity of a user.
Log on procedures use a suitable authentication technique to verify and substantiate the claimed
identity of a user. The type of authentication technique should be based on risk assessment and
multi factor authentication methods may be used to verify the identify depending on systems risk
profile and criticality. These may be cryptographic means, smart cards, tokens, or biometric
means.
The log-on procedure should disclose the minimum information about the system or application,
to avoid providing an unauthorized user with any unnecessary assistance. The log-on procedure
may take following into account:
i. Not display system or application identifiers until the log-on process has been successfully
completed;
ii. Display a general notice warning (warning banner) that the system should only be accessed
by authorized users;
iii. Not provide help messages during the log-on procedure that would aid an unauthorized
user;
iv. Validate the log-on information only on completion of all input data. If an error condition
arises, the system should not indicate which part of the data is correct or incorrect;
v. Log unsuccessful and successful attempts;
vi. Limit number of consecutive invalid access attempts to five or lower and reset to zero, the
number of access attempts after a predetermined time period;
vii. Raise a security event if a potential attempted or successful breach of log-on controls is
detected;
viii. Display the following information on completion of a successful log-on:
• Date and time of the previous successful log-on; and
• Details of any unsuccessful log-on attempts since the last successful log-on.
ix. Not display the password being entered;
x. Not transmit passwords in clear text over the network;
xi. Terminate inactive sessions after a defined period of inactivity, especially in high-risk system
and application such as public or external areas outside the licensed entity’s security
management or on mobile devices; and
xii. Restrict connection times to provide additional security for high-risk applications and reduce
the window of opportunity for unauthorized access.

IAM-3-2 Secure Log-on Procedures
Secure log-on procedure for ICS/ OT systems should take account of the following:
i. Where the implementation of session time-outs and screensavers is not feasible in certain
process control applications (for example in Human Machine Interface (HMI) and
visualization applications used for continuous process monitoring by operating personnel
(for example in control centers), the resulting risks of unattended sessions should be taken
into consideration and appropriate supplementary countermeasures like physical access
control, logical or physical network segmentation, etc. can be implemented.

IAM-3-3 Password Management
Strong passwords shall be enforced to prevent against unauthorized
Sub control
access.
A password management may take following to account:
i. Enforce the use of individual user IDs and passwords to maintain accountability;
ii. Allow users to select and change their own passwords;
iii. Enforce minimum password length of eight (08) characters;
iv. Enforce passwords complexity requirements like uppercase, lowercase, numbers, and
special characters;
v. Enforce password maximum life of ninety (90) days, or lower based on systems criticality;
vi. Enforce password life to be minimum one (01) day;
vii. Force users to change the password at the first log-on;
viii. Maintain a record of previously used passwords and prevent re-use of at least past five (05)
passwords;
ix. Not display passwords on the screen when being entered;
x. Store password files separately from application system data; and
xi. Store and transmit passwords using secure encryption algorithms.
Risk assessment to be performed for ICS/ OT systems devices and applications that do not
support strong password requirements and supplementary countermeasure measures like
physical access control, physical or logical network segmentation may be applied in such cases,
as deemed necessary by the risk assessment.
For additional guidance, specific to ICS/ OT environments, refer to Annexure X: ICS/ OT
Systems Password Management.

IAM-3-4 Use of Privileged Utility Programs
The use of utility programs that might be capable of overriding system
Sub control
and application controls shall be restricted and tightly controlled.
The following guidelines for the use of utility may be considered:
i. Use of identification, authentication, and authorization procedures for utility programs;
ii. Segregation of utility programs from applications software;
iii. Limitation of the use of utility programs to the minimum practical number of trusted,
authorized users;
iv. Authorization for ad hoc use of utility programs;
v. Limitation of the availability of utility programs, e.g., for the duration of an authorized
change;
vi. Logging of all use of utility programs;
vii. Defining and documenting of authorization levels for utility programs;
viii. Removal or disabling of all unnecessary utility programs; and
ix. Not making utility programs available to users who have access to applications on systems
where segregation of duties is required.
No additional information specific to the ICS/ OT systems.

IAM-4 User Responsibilities
To make users accountable for safeguarding their authentication
Objective
information.
IAM-4-1 Use of Secret Authentication Information

Users shall follow the licensed entity’s practices in the use of secret
Sub control
authentication information.
All users may be advised to:
i. Keep secret authentication information confidential, ensuring that it is not divulged to any
other parties, including people of authority;
ii. Avoid keeping a record (e.g., on paper, software file or hand-held device) of secret
authentication information, unless this can be stored securely, and the method of storing has
been approved (e.g., password vault);
iii. Change secret authentication information whenever there is any indication of its possible
compromise;
iv. When passwords are used as secret authentication information, select quality passwords
with sufficient minimum length which are:
• Easy to remember;
• Not based on anything somebody else could easily guess or obtain using person related
information, e.g., names, telephone numbers and dates of birth etc.;
• Not vulnerable to dictionary attacks (i.e., do not consist of words included in dictionaries);
• Free of consecutive identical, all-numeric or all-alphabetic characters; and
• If temporary, changed at the first log-on.
v. Not share individual user’s secret authentication information;
vi. Ensure proper protection of passwords when passwords are used as secret authentication
information in automated log-on procedures and are stored; and
vii. Not use the same secret authentication information for business and non-business
purposes.
The licensed entity can consider adding the above points in the ongoing end user cybersecurity
awareness training program.
In ICS/ OT systems it may not be possible to ensure the use of secure secret authentication
information. It should be clearly indicated to the user when the general secret authentication
information policy applies and when exceptions are allowed e.g., in case of declared emergency,
plant maintenance outage, etc.

Legal, Contractual and
Regulatory Compliance
LCRC
Legal, Contractual and Regulatory Compliance
(LCRC)
Objective
To ensure compliance with applicable statutory, regulatory, legal, and contractual compliance
obligations to related to IT/ OT security.
Description
The licensed entity has to comply with different statutory, regulatory, and contractual obligations
related to IT/ OT systems. Non-compliance with these obligations can result in imposition of
fines, breach of contractual terms and may also impact the reputation of the licensed entity.
Thus, it is important for the licensed entity to proactively identify, document and ensure
adherence to all relevant and applicable statutory, regulatory, legal, and contractual compliance
obligations. The licensed entity should create, maintain, and protect the records to demonstrate
the due care and due diligence undertaken by the licensed entity to comply with the applicable
compliance and regulatory requirements.
Applicability
this domain.
Legal, Contractual Identification of Legal,

and Regulatory Contractual and
Compliance Regulatory Compliance
Procedure Requirements
Legal,
Contractual &
Regulatory
Compliance
Intellectual Property Protection of Records

Rights

(LCRC) (contd.)
LCRC-1 Legal, Contractual and Regulatory Compliance
To ensure compliance with applicable statutory, regulatory, legal, and
Objective
contractual compliance obligations related to IT/ OT security.
LCRC-1-1 Legal, Contractual and Regulatory Compliance Procedure

Legal, contractual, and regulatory compliance procedure shall be
documented, established, and reviewed periodically, that facilitates the
Sub control
identification and implementation of applicable statutory, regulatory,
legal, and contractual compliance obligations related to IT/ OT security.
Following are the key aspects of that can be considered by the licensed entity while developing
the legal, contractual, and regulatory compliance procedure:
i. Roles and responsibilities related to identification and maintenance of applicable statutory,
regulatory, legal, and contractual compliance obligations related to IT/ OT security;
ii. Requirement to prepare and maintain an up to date, consolidated list of all relevant and
applicable statutory, regulatory, legal, and contractual compliance requirements;
iii. Requirement to update the compliance requirements on timely basis in case of changes (as
applicable) to the relevant and applicable statutory, legal, regulatory, and contractual
requirements;
iv. Process to be followed to periodically review adherence to the identified compliance
requirement and identify gaps that may lead to non-compliance;
v. Define the requirement to be maintain and protect, adequate and necessary artefacts that
can be used to demonstrate the compliance. The licensed entity may additionally consider
developing a ‘Document and Record Control’ procedure to achieve this objective; and
vi. Legal, contractual, and regulatory compliance procedure should be reviewed periodically
and in case of major changes.
and include them in the LCC Procedure, as applicable, based on the risk assessment.

(LCRC) (contd.)
LCRC-1-2 Identification of Legal, Contractual and Regulatory Compliance
Requirements
The licensed entity shall identify and document all the applicable
Sub control statutory, regulatory, legal, and contractual requirements related to IT/
OT security.
Following guidelines may be considered to identify applicable statutory, regulatory, legal, and
contractual compliance requirements related to cybersecurity:
i. Assign the responsibility to develop and maintain the consolidated list of all relevant and
applicable requirements applicable, on an ongoing basis to a specific role;
ii. Include the legal and compliance departments to support in this activity;
iii. Identify all applicable statutory, regulatory, legal, and contractual requirements; and
iv. Establish a periodic review process, to validate that the licensed entity is adhering to all
applicable compliance requirements.

Following additional guidance related to ICS/ OT systems may be referred by the licensed entity
while implementing this control:
i. Health and Safety Requirements relating to the secure, safe, and reliable operation of ICS/
OT facility components, systems, and networks; and
ii. Requirements of sharing operational data with interconnected utility companies and with the
regulatory body.

(LCRC) (contd.)
LCRC-1-3 Protection of Records
The licensed entity shall identify, create, maintain, and store records in
a secure manner to prevent any loss, destruction, falsification,
Sub control unauthorized access, and unauthorized release of IT/ OT security
documents and records as per statutory, regulatory, and contractual
compliance requirements.
The licensed entity can refer to the following guidelines while implementing this control:
i. Establishing a ‘Document and Record Control’ procedure. (refer CSG-2-5 for further
guidance);
ii. The licensed entity should identify documents and records with specific compliance
requirements regarding their protection and retention requirements;
iii. A retention schedule should be defined for the identified records and the retention period
should be defined for each;
iv. Record should be stored in such a way that required records can be retrieved in an
acceptable timeframe and format, depending on the requirements to be fulfilled; and
v. Classification, storage, and handling should be based on entity’s information classification
scheme (handling guidelines based on classification level).

(LCRC) (contd.)
LCRC-1-4 Intellectual Property Rights
Measures shall be put in place to ensure that terms and conditions and
license requirements of the copyrighted software or any other
Sub control
proprietary information and intellectual property used within the licensed
entity are complied with.
Intellectual property rights may include copyrights, trademarks, patents, and trade secrets.
Legislative, regulatory, legal, and contractual requirements may place restrictions on the copying
and use of proprietary material. In particular, they may require that only material that is
developed by the licensed entity or that is licensed or provided by the developer to the licensed
entity, can be used. Copyright infringements can lead to legal action, which may involve fines
and criminal proceedings.
The licensed entity can consider the following guidelines to protect intellectual property:
i. Acquiring software only through known and reputable sources, to ensure that copyright is
not violated;
ii. Maintaining awareness of policies to protect intellectual property rights and giving notice of
the intent to take disciplinary action against personnel breaching them;
iii. Maintaining proof and evidence of ownership of licenses;
iv. Implementing controls to ensure that the maximum number of users permitted within the
license is not exceeded (Refer AM-3-6 (Software Assets Management) for further guidance
on software license compliance);
v. Carrying out periodic reviews to validate that only authorized software and licensed products
are installed;
vi. Complying with terms and conditions for software and information obtained from third party;
vii. Not duplicating, converting to another format, or extracting from commercial recordings (film,
audio) other than permitted by copyright law;
viii. Not copying in full or in part, books, articles, reports, or other documents, other than
permitted by copyright law;
ix. For the customized (not off-the-shelf/ standard offerings) software developed by third
parties, arrangements pertaining to licensing, code ownership and intellectual property rights
should be documented in the contract between the licensed entity and the third party; and
x. If a work is copyrighted, explicit written permission to reproduce the work should be taken
from the copyright holder.

Logging and Monitoring
LM
Logging and Monitoring (LM)
Objective
To maintain situational awareness of IT/ OT security events through collection and monitoring of
event logs from IT/ OT systems such as applications, databases, servers, network devices,
security solutions etc.
Description
Effective LM entails having a comprehensive visibility into the events that are being generated in
the IT/ OT infrastructure components such as servers, databases, applications, network devices
and other log sources. The proactive monitoring of such events reduces the likelihood that a
malicious activity would go unnoticed. It equips the licensed entity with situational awareness
and facilitates taking timely corrective actions to prevent or minimize damage that might have
been caused by the malicious actors.
Applicability
assessment.
Procedure Log Retention
Event Logging Monitoring Logs
Logging and
Monitoring
Protection of Clock
Log Information Synchronization

Logging and Monitoring (LM) (contd.)
LM-1 Logging and Monitoring
To maintain situational awareness of security events through the
Objective
collection and monitoring of event logs from IT/ OT systems.
LM-1-1 Logging and Monitoring Procedure

Logging and monitoring procedure shall be documented, established,
requirements.
Following are the key aspects that should be included in the logging and monitoring procedure:
i. Roles and responsibilities related to logging and monitoring;
ii. Identify IT/ OT systems that need to be logged and monitored;
iii. Define activities/ events that need to be logged;
iv. Define minimum requirements, that each log entry should contain;
v. Log protection and retention requirements;
vi. Monitoring process and its integration with incident response procedure;
vii. SLAs and escalation process for event monitoring (these might be documented separately
in the SOC SOP etc.;
viii. Requirement of time synchronization of IT/ OT systems; and
ix. Logging and monitoring procedure should be reviewed periodically and in case of major
changes.
and include them in the logging and management procedure, as applicable, based on the risk
assessment.

LM-1-2 Event Logging
Event logs recording user activities, system activities, network activities,
Sub control exceptions, faults, and security events shall be enabled and stored
securely.
Following are the reference activities that the licensed entity may consider for logging:
i. User authentication and authorization (only success or both success and failure based on
system criticality);
ii. Grant, modify, or revoke access rights, including adding a new user or group;
iii. Unauthorized information system access attempts;
iv. Unauthorized data/ resource access attempts;
v. Changing user privilege levels;
vi. Changing file permissions, changing database object permissions etc.;
vii. Creation and deletion of system level objects;
viii. Attempts to access super user/ privileged accounts;
ix. All privileged operations (administrator, root, etc.);
x. Changing of Router/ firewall rules, opening of ports etc.;
xi. Changes to Router/ Firewall/ IPS/IDS configuration tables;
xii. Changes to Router/ Firewall/ IPS/ IDS configuration and access such as changes in
password;
xiii. System configuration changes;
xiv. Installation of software ;
xv. User password changes;
xvi. Application process start up, shutdown, or restart;
xvii. IT/ OT system start up, shutdown, or restart;
xviii.Application process abort, failure, or abnormal end, especially due to resource exhaustion or
reaching a resource limit or threshold (such as for Central Processing Unit (CPU), memory,
network connections, network bandwidth, disk space, or other resources);
xix. Failure of network services such as Firewall, IPS, Dynamic Host Configuration Protocol
(DHCP) or Domain Name Server (DNS), or hardware fault;
xx. System and application alerts and error messages;
xxi. Initialization, stopping or pausing of the logs; and
xxii. Access to critical files (system configuration files, application configuration files, database
files, logs/ audit trails, etc.).

LM-1-2 Event Logging
While determining the logging requirements, the licensed entity may use the below questions as
a guideline to ensure that information systems are recording sufficient level of details in logs:
i. What activity was performed ?
ii. Who or what performed the activity, including where or on what system the activity was
performed from (subject) ?
iii. On which system the activity was performed on (object) ?
iv. When was the activity performed ?
v. What was the status (such as success vs. failure), outcome, or result of the activity?
Logs should contain at least the following elements, to aid in monitoring and incident analysis:
i. Type of action:
Examples include authorize, create, read, update, delete etc.;
ii. User/ System performing the action:
Examples include process, application, user etc.;
iii. Identifiers for the subject requesting the action:
Examples include username, computer name, IP address, and MAC address;
iv. Identifiers for the object, on which the action was performed on:
Examples include file names accessed, unique identifiers of records accessed in a
database, query parameters used to determine records accessed in a database, computer
name, IP address, and MAC address;
v. Before and after values when action involves updating a data element, if feasible;
vi. Date and time the action was performed;
vii. Whether the action was allowed or denied by access-control mechanisms; and
viii. Description and/or reason-codes of why the action was denied by the access-control
mechanism, if applicable.
In the energy sector, additional activities that may be considered for logging in the OT
environment are actions carried out by operating personnel, e.g., control operations, switching
operations, parameter or setpoint changes, changes to control programs.

LM-1-3 Protection of Log Information
Logs information shall be protected against unauthorized changes
Sub control including alterations, deletions, and renaming of log file contents, dates,
and time stamps.
Measures that can be considered to protect the log information against unauthorized changes
and loss include:
i. The logs should be “Read Only”, and no alterations should be allowed;
ii. Limiting access to logs to those with a job-related need;
iii. Where possible and supported by the system, the system administrators should not have
permission to erase or de-activate logs of their own. Any such attempts should raise security
alerts;
iv. Requiring log configuration changes to be approved by authorized security personnel and
enabling alerts to detect any unauthorized changes to log configuration settings; and
v. Provisioning adequate storage capacity of the log files to prevent loss of logs owing to
storage media being exceeded, resulting in either the failure to record events or over-writing
of past recorded events.
Further, some event logs may contain sensitive data (e.g., personally identifiable information of
customers, in case of licensed entity involved in distribution) and appropriate protection
measures should be taken to ensure confidentiality.

LM-1-4 Log Retention
Logs shall be retained as per the data retention policies and applicable
Sub control
legal, regulatory, and contractual requirements.
Retaining logs is vital for conducting any forensics analysis/ investigations in case of an
cybersecurity incident/ breach. Taking backups of logs helps ensure that logs would be available
if required, even if the primary system storing the logs malfunctions.
Following guiding principles may be adopted by the entity while determining the log retention
requirements:
i. The backup of the logs should be taken as per the licensed entity’s backup procedure;
ii. The backup of logs should be protected from unauthorized access; and
iii. The retention period of the logs should be aligned with the licensed entity’s data retention
requirements and other relevant regulatory or contractual requirements.

LM-1-5 Monitoring Logs
Event logs shall be proactively monitored to detect threats,
Sub control
vulnerabilities, malicious activities, and indicators of potential attacks.
The logs of the IT/ OT system should be monitored periodically. The periodicity should be
decided based upon the criticality of the system. The alerts should be raised in case of events
such as:
i. Unauthorized access;
ii. Configuration changes;
iii. Abnormalities in routing events;
iv. Failed logins;
v. DoS attempts;
vi. Violation of systems performance limit like:
• CPU usage;
• Memory utilization;
• Disk space utilization;
• Communication bandwidth utilization;
• Device temperature; and
• Power supply.
vii. Alerts by security tools;
viii. Failures of critical security systems such as:
• Firewalls;
• IDS/IPS;
• File Integrity Monitoring (FIM);
• Anti-virus;
• Physical access controls;
• Logical access controls; and
• Logging mechanisms.

LM-1-5 Monitoring Logs
Given the vast number and diverse type of IT/ OT systems that exist in a typical IT/ OT
ecosystem, it would be difficult to perform the monitoring activities manually. Further, manual
periodic reviews might lead to delay in detection of security anomalies. Thus, it is advisable to
implement a centralized log monitoring solution like SIEM that can integrate logs from different
IT/ OT systems, correlate logs across different repositories to gain enterprise-wide situational
awareness and provide real time log monitoring capabilities. Further to enable effective and 24*7
monitoring a dedicated SOC team (internal or external) for monitoring events on a continuous
basis should be established.

The licensed entity that do not have a SIEM deployed for the ICS/ OT environment at present
can consider employing a manual process to carry out the monitoring of ICS/ OT systems logs
(as an interim measure). This manual process may include:
i. Assigning the responsibility of log monitoring;
ii. Identifying systems whose logs would be monitored;
iii. Identifying the events should be reviewed;
iv. Periodicity of performing the reviews; and
v. Results of the log review activity should be formally documented and retained.

LM-1-6 Clock Synchronization
Clocks for all IT/ OT systems shall be synchronized with an industry
Sub control
accepted time source.
The correct setting of system clocks is important to ensure the accuracy of logs, which may be
required for investigations or as evidence in legal or disciplinary cases.
While implementing this control, the licensed entity may consider the following aspects to ensure
that appropriate measures are implemented for acquiring, distributing, and storing time securely:
i. Critical systems have the correct and consistent time. Network Time Protocol (NTP) can be
used to keep all systems in synchronization with the master clock;
ii. Time data is protected;
iii. Time settings are received from industry-accepted time sources;
iv. The licensed entity should standardize date/time format;
v. Only the designated central time server receives time signals from external sources, and
time signals from external sources are based on International Atomic Time or Universal Time
Coordinated (UTC);
vi. Where there is more than one designated time server, the designated central time servers
peer with one another to keep accurate time; and
vii. Systems receive time only from designated central time server and any changes to time
settings on critical systems should be logged, monitored, and reviewed.
Depending on the criticality of the ICS/ OT systems, time synchronization approach may use
IEEE 1588 Precision Time Protocol that provides an accuracy of sub microsecond.
For ICS/ OT systems like Phasor Measurement Unit (PMU), Digital Substation (especially
Optical Current Transformer), etc., Precision Time Protocol may be considered as the accuracy
of time between devices is critical for operations. To protect clock synchronization availability
and integrity, the communication for these systems should:
i. Be on a separate secure network zone (segregated logically or physically from other ICS/
OT systems); and
ii. Have a dedicated communication conduit.
For ICS/ OT systems like Automatic Meter Infrastructure, Advance Distribution Management
System, etc. that are typically spread across the city and communicate on wireless networks, the
NTP time packets should be cryptographically protected.

Network Security Management
NSM
Network Security Management (NSM)
Objective
To ensure the protection of information in networks and its supporting information processing
facilities.
Description
Communication networks are the backbone on which the information is shared. Absence of
proper controls around network and communications infrastructure can lead to risks like
unplanned network outages, traffic being sniffed while in transit on the network etc. Thus, it
becomes critical for the licensed entity to effectively and securely design, manage, and control
its network infrastructure as well as to have situational awareness of network activities. The
licensed entity should ensure sufficient controls are implemented to protect the confidentiality,
integrity, availability, and safety of the licensed entity’s network infrastructure.
Applicability
assessment.
Network Security Standard
Electronic Network Segmentation

Messaging and Protection
Network Security
Management
Remote Access Network Access and

Management Monitoring

Network Security Management (NSM) (contd.)
NSM-1 Network Security Standard
To ensure security controls are identified and implemented to protect the
Objective
licensed entity’s network and communications.
NSM-1-1 Network Security Standard

Network Security Management standard shall be documented,
Sub control established, and reviewed periodically, that lays down the requirements
and controls to protect communication network.
The NSM standard should include requirements related to securely managing the network
infrastructure. Following are the key areas that can be considered:
i. Network segregation;
ii. Protecting availability of network services;
iii. Network traffic encryption;
iv. Controlling access to the devices;
v. Logging and monitoring;
vi. Hardening the network and network security devices;
vii. Strong ACLs and rule bases to enforce control over network traffic ;
viii. Wireless security;
ix. Implementing changes as per change management and configuration management
procedure;
x. Taking backups of configurations;
xi. Roles and responsibilities related to NSM; and
xii. NSM standard should be reviewed periodically and in case of major changes.
Further, the licensed entity may also consider documenting device specific SOP to securely
carrying out key administrative tasks such as:
i. Installation and configuration devices;
ii. Hardening of devices;
iii. Documenting key information like routing tables, network diagrams etc.;
iv. Adding / Deleting / Modifying Rule base;
v. Adding / Deleting / Modifying Routing table;
vi. Adding / Deleting / Modifying device administrators; and
vii. Backup / Recovery of device configuration.

NSM-1-1 Network Security Standard
and include them in the NSM standard, as applicable, based on the risk assessment.

NSM-2 Network Segmentation and Protection
To ensure that the communication network is segmented into different
Objective
security zones to restrict information flow.
NSM-2-1 Network Segmentation

The communication network shall be segmented into different security
Sub control zones as per business and cybersecurity requirements.
Network must be segmented logically and/or physically in different security zones based on
sensitivity, security requirements, internet exposure and business requirements. This
segmentation should restrict the ingress and egress network flow between different zones and
improves overall security.
Following recommendations may be considered for segmenting the network into security zones:
i. Systems sharing common security requirement should be grouped into common security
zones;
ii. There should be logical or physical segmentation between IT and ICS/ OT networks. If the
network is logically separated, appropriate perimeter security devices should be put in place.
If the network is physically separated, controls should be in place to protect physical access
to the network points at all ends;
iii. There should be logical segmentation within IT/ OT network, based on criticality of different
IT systems, their application/ function, and exposure (e.g. De-Militarized Zone (DMZ) where
publicly accessible systems are hosted, an internal Local Area Network (LAN) zone, a
secure zone where critical servers/ databases/ network devices are located, etc.);
iv. DMZ should be maintained where all external facing servers including but not limited to web
servers, email gateways, proxy servers should be placed. The DMZ should be segregated
from the internal server segment by a firewall;
v. Servers which have been identified as critical or contain sensitive and critical information
should be placed inside the internal network zone protected by firewall;
vi. Separate server and user segments should be created and access between them must be
controlled with adequate rule bases;
vii. Separate segment should be created for Production and Development/ Test systems. Users
from Development/ Test environment should not have access to systems in Production;
viii. There should be a separate network segment for wireless networks; and
ix. There should be separate out-of-band network management zone, dedicated for
management access to, network devices, security devices etc. for securely monitoring,
troubleshooting and administering network infrastructure (Out-of-band management
provides a way to log into your network devices without going through the same network
through which the data travels).

NSM-2-1 Network Segmentation
Other general considerations:
i. Disclosure of private IP addresses and routing information from internal networks to internet
should be prevented by implementing Network Address Translation (NAT) etc.;
ii. Routing controls should be implemented to ensure that network connections and information
flows do not breach the access control requirements;
iii. Firewalls should be subject to a ruleset reviews periodically, to ensure that only the
necessary traffic is permitted. The firewall ruleset review should not be carried out by the
person responsible for maintaining the firewall ruleset;
iv. Change Management procedure should be initiated for making any changes (e.g. firmware
upgrade, rule base change etc.);
v. Device firmware upgrades should be done periodically;
vi. Administration of critical devices should be restricted from the trusted network segment; and
vii. Administration of critical devices should be performed through secure and encrypted
channels.
i. ICS/ OT systems should not be directly connected to public network;
ii. ICS/ OT network should only be connected with IT systems if necessary for business or
operational reasons, ensuring that any such connections are secured through appropriate
mechanisms like firewall, data diodes etc. The firewall placed to segregate OT environment
should be forward diode mode (One way communication);
iii. There should be logical segmentation within ICS/ OT environment;
iv. Where applicable and technically feasible, the ICS/ OT network infrastructure should be
divided into multiple zones, based on criticality of different OT systems, their application/
function (e.g., safety systems) and protection requirements;
v. The legacy ICS/ OT systems that can’t be patched or upgraded due to technical reasons
should also be segregated from the remaining network and compensatory controls like
firewall, proxy server, or protocol converter should be implemented for such zones before
connecting to other ICS/ OT systems;
vi. All ICS/ OT systems, which require being accessible from the corporate network must be
deployed in a DMZ (L3.5 - Demilitarized Zone); and
vii. For OT environment, the licensed entity can further consider deploying a separate domain
controller (separate from IT network domain controller).
Please refer to Annexure XI: Network Segmentation for a generic ICS/ OT system architecture.

NSM-2-2 Boundary Protection
Appropriate boundary protection devices shall be implemented at the
Sub control zone boundaries to monitor and control communications at zone
boundaries and to enforce the compartmentalization.
Any connections between different networks security zones should occur through managed
interfaces consisting of appropriate boundary protection devices (for example, proxies,
gateways, routers, firewalls, unidirectional gateways etc.) to allow only authorized
communication and required information flows. The following guidelines may be considered
while implementing this control:
i. All connections to or from any external network to the licensed entity’s networks must be
filtered through a firewall;
ii. A managed interface for each external network, DMZ and internal network should be
implemented;
iii. A traffic flow policy for each managed interface should be established to define permissible
ports, protocols, IPs, etc. for communication with other interfaces;
iv. Any new inbound and outbound services to be allowed on the firewall must be analyzed and
monitored. All such permitted inbound and outbound services must be documented;
v. Each exception to the traffic flow policy with a supporting business need and duration of that
need should be documented and approved by the concerned stakeholders. The approved
exceptions to the traffic flow policy should be reviewed and exceptions that are no longer
supported by an explicit business need should be reviewed;
vi. The confidentiality and integrity of the information being transmitted across each interface
should be protected;
vii. Adequate controls should be implemented to ensure security of control plane traffic. These
may include preventing unauthorized exchange of control plane traffic with external
networks;
viii. Security devices like Network Intrusion Detection/ Prevention System (IPS) should be
installed to monitor/prevent all the traffic, between different network boundaries/ zones (e.g.
at external network border, DMZ etc.);
ix. ACL should be implemented on all perimeter devices that connect to the external networks;
x. ACLs on the perimeter devices should block access to vulnerable ports. Ports that are
known to be vulnerable to virus/ worms or any attacks should be blocked;
xi. All data that is sent over the public networks should be in encrypted format; and
xii. Anti-spoofing should be configured on Firewall Interface.

NSM-2-3 Wireless Network Security
Wireless networks shall be adequately protected and segregated from
Sub control the licensed entity’s other communication networks.
Wireless technologies may include, microwave, packet radio (Ultra High Frequency (UHF)/ Very
High Frequency (VHF)), 802.11x, Cellular and Bluetooth etc. Following are the key
considerations that can be referred to while implementing this control:
i. Segregation:
• Treat the wireless network as an untrusted, external network and ensure that all relevant
protection measures recommended for external networks in NM-2-2 are considered while
considering the right level of security for wireless networks connecting with other
segments of the licensed entity’s communication network; and
• The wireless network should be considered as a separate security zone, and the wireless
network traffic should pass through a firewall before entering the IT/ OT network.
ii. Hardening:
• All wireless infrastructure devices, including but not limited to access points should be
hardened as per the licensed entity’s minimum-security baseline standards (CCM-2-2);
• Default administrator passwords should be changed, conforming with the licensed entity’s
Password Policy;
• Service Set Identifier (SSID) of the access point should be changed from the factory
default;
• SSID for the corporate wireless network should be hidden (not broadcasted) to reduce the
likelihood for unauthorized access; and
• Simple Network Management Protocol (SNMP) Community strings should be changed
from manufacturer default to unique, unpublished strings.
iii. Access:
• Unauthorized devices connected to the wireless network should be blocked. The wireless
access point should utilize MAC address filtering so that only known systems are able to
connect to the wireless network; and
• Split tunnelling mode should be disabled while connecting through VPN.
iv. Physical security:
• The wireless access points should be protected and mounted in a way that they cannot be
stolen, moved, vandalized, blocked, or damaged. This may be achieved by mounting the
access points in locked enclosures, installing them in hard to reach/ concealed areas etc.;
and
• Cabling to and from access points should be secured so that it cannot be accessed
without difficulty.

NSM-2-3 Wireless Network Security
v. Encryption:
• Wireless networks should use secure cryptographic algorithms for encryption and use
secure authentication protocols; and
• Encryption keys should be changed periodically.
vi. Guest WIFI:
• The guest WIFI network i.e. the wireless network for giving internet access to the guests/
visitors should not allow access to the corporate network; and
• The Guest WIFI traffic should be configured in a manner to route guests to the internet
without connecting to the licensed entity’s corporate network.
vii. Assessments:
• Periodic wireless security testing/ penetration tests should be performed.
viii. Other Security Measures:
• Software/ firmware of the wireless infrastructure, including but not limited to wireless
access points should be updated periodically;
• Wireless networks used should be clearly indicated in the network diagram;
• Security tools like wireless LAN management software, wireless intrusion detection/
prevention may be used to protect the network against wireless threats, to enforce
wireless security policies, detect rogue access points etc.; and
• Wireless usable signal area should not extend beyond the areas intended for service.
Detailed guidance covering security requirements, security constrains, and countermeasures
related to wireless devices used in the ICS/ OT environment has been documented in Annexure
XII: Wireless Communication Cybersecurity Considerations for ICS/ OT Environment.

NSM-2-4 Network Diagram
An up to date network diagram, depicting the critical elements of the
Sub control
network architecture shall be documented and maintained.
While developing the network diagrams, the licensed entity can consider covering the following
details:
i. Network Diagrams should be updated as and when there are changes made to the network
architecture;
ii. Adequate version control mechanisms should be in place for managing and updating the
network diagram. Name of author, date created, date reviewed and version number etc.
should be recorded;
iii. Periodic reviews should be conducted to ensure that the diagram is updated to reflect the
existing network architecture;
iv. The network diagrams should be classified based on the nature of information recorded in
the network diagram, as per the licensed entity data classification scheme (e.g. Classified,
Confidential, Restricted, Internal and Public);
v. Network diagrams should be kept confidential and should be made available on “Need to
know” basis; and
vi. Sensitive information like IP addresses, hostname should be removed or masked before
sharing the network diagram with third party (auditor, etc.).

NSM-2-5 Network Redundancy
Adequate redundancy shall be provided for critical network links and
Sub control
network devices to prevent unplanned outages.
Network outages owing to issues at communications layer (network cable damages, connectivity
losses, issues at ISP, device failures etc.) can disrupt critical operations as they might lead to
unavailability of the critical applications, communication means like emails, loss of access to
data etc.
To address such risks, the licensed entity can consider implementing adequate redundancy, as
deemed necessary based on the risk assessment.
The licensed entity can consider the following guidelines while determining the redundancy
requirements and implementing this control:
i. All network device configurations should be backed up periodically as per the guidelines
mentioned in the Backup Management domain;
ii. Adequate redundancy should be provided for critical network links and network devices. The
level of redundancy should depend on the criticality of systems utilizing the link and the
network device. For critical links including Internet connections, there should be a redundant
link (this may be configured with automatic failover based on criticality) to ensure that there
is minimum disruption of operations;
iii. Redundant links should have the same level of security as the primary links; and
iv. Adequate redundancy should be built into all critical devices, e.g.:
• Network Devices like Core switches, Edge switches, etc.;
• Security Devices like Firewall, IDS, etc.;
• Critical Application servers like Mail, Database etc.; and
• Infrastructure Applications like Active Directory Domain, Proxy etc.
Alternate telecommunication service providers should employed i.e. network connectivity should
be supported by more than one ISPs (Internet Service Providers) to ensure that the connectivity
is not lost owing to issues with one ISP. Periodic failover tests are conducted to ensure the
reliability of the secondary link.
Note: It is acceptable to have the backup service provider at a lower speed. During outages at
primary service provider the licensed entity will failover to the backup provider allowing the
business to stay connected. In this scenario the backup provider is a temporary solution until the
primary provider is operational again.

NSM-3 Network Access and Monitoring
Communication network and networking devices shall be protected from
Objective unauthorized access and network activity should be monitored to detect
and malicious traffic.
NSM-3-1 Network Access

Network access controls for protection of the communication network
Sub control and networking devices from unauthorized users and devices shall be
implemented.
Following recommendation may be considered for implementing NAC:
i. Network access management solution (e.g., TACACS, RADIUS, etc.) should be
implemented for centralized access management (authentication, authorization, and
accounting) of network devices;
ii. Network access should be granted as per the user access provisioning guidelines IAM-2-2
(User Access Provisioning).
iii. Unused ports of network devices (e.g., switches and routers) should be blocked;
iv. Network ports in the public areas like meeting rooms etc. should be disabled by default;
v. Inactive terminals to access network console for remote troubleshooting should timeout after
a defined period of inactivity to prevent unauthorized access. Inactive terminals should be
set to a timeout of fifteen (15) minutes or less. The timeout facility should clear the terminal
screen and close both application and network sessions after the defined period of inactivity;
vi. Access to and use of network diagnostic tools should be strictly controlled to prevent
unauthorized users; and
vii. Insecure services (such as telnet, rlogin) should not be used and secure alternatives such
as SSH should be adopted.
To further strengthen the control, the licensed entity can consider implementing a NAC solution
to restrict unauthorized users and devices from gaining access to the network. The NAC solution
will ensure that only authenticated users and devices that are authorized and compliant with
licensed entity’s security policies can connect to the network.
Centralized network access management solution may not be usable in some components of
the ICS/ OT environment (e.g. PLC, RTUs, Gateway etc.) due to technical or operational
constraints. For PLC, RTUs, Gateway the licensed entity can consider implementing
compensatory controls like binding the port of the network switch/router with the MAC of that
specific device. In such cases physical security controls such as locking of panels housing PLC,
RTUs, Gateway, switch, etc. and controlling access to panels room via access control cards.
Further, maintenance devices (like laptop, workstation, etc.) should be authenticated using
network access management solutions.

NSM-3-2 Network Monitoring
The licensed entity shall monitor their network devices and network
Sub control
traffic to detect any abnormal traffic pattern or malicious activities.
Appropriate LM of network and network security devices should be applied to enable monitoring
and detection of actions that may affect, or are relevant to, cybersecurity. Detailed guidelines
related to LM have been prescribed in the LM Domain. The licensed entity may refer to the said
domain for further guidance while implementing this control. Following are key considerations for
network monitoring:
i. All the traffic on major network segments should be scanned for attack signatures and
anomalous behavior;
ii. IDS or IPS should implement to automate detection and/or prevention of malicious activities
is network;
iii. IDS, IPS, firewall, networking servers, switches, routers, etc. should be monitored using
SIEM solution to get situational awareness of network. 24X7 monitoring of security alerts
should be performed;
iv. Monitoring of activity on the network environment should include performance and device
availability aspects;
v. All activities performed using privileged accounts (administrative or special privileges) on the
firewall, must be logged; and
vi. The log files should be protected from being accessed, modified or deleted by unauthorized
users and should be stored in centralized log repository with restricted access.
Passive scanning and detection solutions should be considered for monitoring ICS/ OT network.
Risk assessment should be done prior to using any active scanning tools or intrusion prevention
solution within ICS/ OT network as it may impact operations.

NSM-4 Remote Access Management
To prevent unauthorized remote access to the licensed entity’s
Objective
information assets.
NSM-4-1 Remote Access Management

Remote access to the IT/ OT systems shall be secure, strictly controlled
Sub control
and access granted only to authorized users.
Following recommendations can be referred by the licensed entity while implementing this
control:
i. VPN to connect remote users (employees and third party) securely with the internal systems
like applications, servers etc. on the corporate intranet should be implemented;
ii. The provisioning and deprovisioning of remote access should be in line with the
recommendations prescribed in the IAM domain;
iii. Secure encryption mechanisms should be used;
iv. Two factor authentication should be mandated for remote access login;
v. Remote access must be logged, and an adequate amount of information must be captured
to assist with reviews and investigations;
vi. Remote sessions (especially by third party) should be recorded and monitored and if any
misuse is detected, the session should be terminated immediately;
vii. Dual (split) tunnelling should not be permitted and only one network connection should be
allowed i.e. when remote access is provided, remote access solution should prevent VPN
clients from potentially routing communications between two networks, such as the client’s
network (the network the remote user is connected to e.g. home internet or public internet)
and the licensed entity’s network;
viii. Remote sessions should be automatically disconnected after a defined period of inactivity
(idle timeout). The licensed entity can also consider terminating the session after a defined
period of continuous use (session timeout). Both time-outs should require the user to
reconnect and re-authenticate; and
ix. The remote access granted should be reviewed periodically, in with the guidelines
mentioned in the IAM-2-4 (Periodic User Access Review).
To further enhance the security, the licensed entity can deploy systems that can check
endpoint's compliance status before establishing the connection. These compliance checks may
be checking the antivirus definition update status, checking whether the latest security patches
have been deployed on the end point etc.
Remote access to ICS/ OT systems should be avoided and if it is absolutely required, thorough
risk assessment should be carried out prior to granting any such access. Strict implementations
of recommendation mentioned in “Implementation Guidance” above should be ensured.
NSM-5 Electronic Messaging
To protect the information involved in electronic messaging service like
Objective
Electronic mail (email) and Instant Messaging.
NSM-5-1 Electronic Mail Protection

The licensed entity shall protect their electronic mail services and
information involved by securing email servers, email clients,
Sub control
networking infrastructure involved in email services, and by sensitizing
users about secure email practices.
The licensed entity should implement security measure to address following email security
issues:
i. Attackers use email as social engineering vehicle to exploit the licensed entity’s users to
gather information or get the users to perform actions that further an attack;
ii. Flaws in the mail server application may be used as the means of compromising the
underlying server and the attached network;
iii. DoS attacks may be directed to the mail server or its support network infrastructure, denying
or hindering valid users from using the mail server;
iv. Sensitive information on the mail server may be read by unauthorized individuals or
changed in an unauthorized manner;
v. Unencrypted sensitive information transmitted between mail server and client may be
intercepted. All popular email communication standards default to sending usernames,
passwords, and email messages unencrypted;
vi. Information within email messages may be altered at some point between the sender and
recipient;
vii. Attackers may gain unauthorized access to resources elsewhere in the licensed entity
network via a successful attack on the mail server;
viii. Misconfiguration may allow attackers to use the licensed entity’s mail server to send email-
based advertisements (i.e., spam); and
ix. Users may send inappropriate, proprietary, or other sensitive information via email. This
could expose the licensed entity to legal action.
Following security measures should be implemented to protect email infrastructure:
i. Email accounts:
• Email accounts should create an email id for the user after formal approval from
appropriate departments;
• Only authenticated users should have access to their email accounts;

• Auto-forward of official mails to personal e-mail accounts should not be allowed;
• Locally stored mailbox files should be protected by password;
• Email signature should contain official contact details only;
• Appropriate restrictions should be configured for attachment for external emails and
internal mails;
• Appropriate restrictions should be configured for the size of individual mailbox on server;
and
• Access to email accounts should be revoked immediately upon termination of an
employee/ third party after authorization from appropriate departments.
ii. Email server security:
• Email servers accessible from the Internet should be protected by a perimeter security
device like firewalls, IPS, Web Application Firewall, etc.;
• The perimeter devices should be configured to ensure that only required ports are opened
to/ from Internet. The ports that need to be allowed should include SMTP/ Post Office
Protocol 3 (POP3) over Secure Sockets Layer (SSL)/ Transport Sockets Layer (TLS)
ports for email transfer and Hypertext Transfer Protocol Secure (HTTPS) for web-mail
access;
• Sensitive information if sent on email, should be encrypted or password protected to
maintain confidentiality;
• Email server should have protection against SPAM and malicious code;
• Security patches should be regularly updated for email server and the email application;
• The performance of the email servers should be continuously monitored. The parameters
that should be monitored include:
o CPU Utilization;
o Memory Utilization;
o Storage free space; and
o Mail Flow.
• The email server OSs and application logs should be analyzed for the following:
o Proper functioning of the OSs and email application;
o Unauthorized access to mailboxes;
o Unauthorized access to system files and e-mail application configuration files; and
o Abnormalities in e-mail routing events
• Webmail access should be through HTTPS.;

iii. Shared Mailbox:
• The shared mailbox should be created for a user group where the user groups provide a
centralized service to all employees and required communication with all employees such
as the help desk, HR, cybersecurity, etc.;
• Request for shared mailbox must be approved by appropriate departments;
• A shared mailbox should have one owner who should set well-defined rules for others
who has access on shared mailbox;
• The owner should be responsible for password management of the shared account. The
owner should ensure the following:
o Change default/ initial password communicated by email administrator as per
applicable password policy;
o Messages that do not serve the purpose of the shared mailbox should not be stored
there. Mailbox owner should designate a single group user to be responsible for the
security of the mailbox. And the designated user should only move or delete mails
from shared mailbox;
o The sender of the message using shared mailbox should always be identified in the
mail; and
o Shared mailbox should never be used for sending personal mails.
• The email server OSs and application logs should be analyzed for the following:
o Proper functioning of the OSs and email application;
o Unauthorized access to mailboxes;
o Unauthorized access to system files and e-mail application configuration files; and
o Abnormalities in e-mail routing events
• Email Administrator must maintain a list of the shared mailbox including the membership
and owner.
iv. Backup and Redundancy:
• Backup should be taken for following data:
o Email logs;
o Operating system;
o Configuration settings;
o Archived Emails; and
o Mailbox Files.

• For employees who have resigned or have been terminated, the mails should be retained
for a defined minimum period.;
v. Information Protection:
• All emails containing confidential information should be classified and should be encrypted
and digitally signed; and
• Implementing DLP solution to prevent sharing of confidential information via email.

NSM-5-2 Instant Message Protection
The licensed entity shall implement security measure to protect the
Sub control
information involved in instant messaging.
There are numerous risks associated with the use of Instant Messaging as with any form of
electronic communication. Hence, the licensed entity should implement security measure to
address following instant messaging security risk:
i. Revealing of confidential information over an unsecured delivery channel;
ii. Spreading viruses and worms using Instant Message. The lack of built-in security, and the
ability to download files create an environment in which viruses and worms can spread
quickly. The threat is growing so fast that IM is quickly catching up to e-mail as a primary
point of attack;
iii. Exposing the network to backdoor Trojans that can allow unauthorized access to network
and hosts;
iv. DoS Attacks that make the instant messaging client crash, and in some cases consume a
large amount of CPU power, causing the entire computer to become unstable;
v. Chat sessions can be hijacked, and users can be impersonated; and
vi. Legal liability resulting from downloading copyrighted materials.
Following security measures should be implemented to protect email infrastructure:
i. The licensed entity should deploy a secure instant messaging server on their network and
configure all instant messaging clients to connect to this server;
ii. Given the risks involved in using public instant messaging systems, corporations should
consider prohibiting the use of public instant messaging systems entirely or ask employees
to refrain from using public instant messaging systems for business communications;
iii. Perimeter firewalls should block all traffic from non-approved instant messaging systems;
iv. EPP solution must be installed in all hosts to scan all files transferred using instant
messaging. Virus definition should be regularly updated for all hosts;
v. Instant messaging application should be regularly patched for all hosts; and
vi. All information should be encrypted using strong and secure cryptography algorithm.

Physical and Environmental
Security PES
Physical and Environmental Security (PES)
Objective
To prevent unauthorized physical access to the licensed entity’s facilities, ensure security of
information and equipment and protect the systems from environmental factors.
Description
Physical and environmental security aspects are critical elements to secure data processing,
data storage, data communication/sharing, data hosting and data disposal. PES defines the
various measures or controls that protect licensed entity from loss of connectivity, availability of
information processing facilities, storage (backup and archival) equipment/facilities and
operational equipment’s/devices caused by theft, fire, natural disasters, intentional destruction,
unintentional damage, mechanical failure, power failure, etc.
Applicability
assessment.
Physical and Security of Equipment

Environmental hosted outside Entity
Security Procedure Premises
Physical &
Environment
Security
Secure Areas Equipment Security

(contd.)
PES-1 Physical and Environmental Security Procedure
To develop and implement a physical and environmental security
Objective procedure that outlines the physical and environmental security
requirements.
PES-1-1 Physical and Environmental Security Procedure

Physical and Environmental Security procedure shall be documented,
Sub control established, and reviewed periodically, to ensure adequate physical and
environmental protection of entity’s information assets.
Following are recommendation for developing and maintaining PES procedure:
i. Appropriate to the purpose of the licensed entity;
ii. Outline the roles and responsibilities for the PES;
iii. Describe the physical protection measures;
iv. Describe the environmental security measures;
v. PES procedure should be reviewed periodically and in case of major changes.
and include them in the PES procedure, as applicable, based on the risk assessment.


(contd.)
PES-2 Secure Areas
To prevent unauthorized physical access, damage, and interference to
Objective the licensed entity’s information, systems and information processing
facilities.
PES-2-1 Physical Security Perimeter

Physical security perimeter security measures shall be implemented to
Sub control protect sites that have information, systems, and information processing
facilities.
The following guidelines may be considered and implemented as appropriate and applicable for
physical security perimeters:
i. Security perimeters should be defined, and the siting and strength of each of the perimeters
should be aligned with the security requirements of the assets within the perimeter and the
results of a risk assessment;
ii. There should not be any gaps in the perimeters of buildings or site containing information or
information processing facilities from where a break-in could occur;
iii. A manned reception area or other means to control physical access to the site or building
should be in place;
iv. Access to sites and buildings should be restricted to authorized personnel only;
v. Physical barriers should, where applicable, be built to prevent unauthorized physical access;
vi. All fire doors on a security perimeter should be alarmed, monitored, and tested in
conjunction with the walls to establish the required level of resistance in accordance with
suitable regional, national, and international standards. They should operate in accordance
with the local fire code in a failsafe manner;
vii. Suitable intruder detection systems should be installed and regularly tested to cover all
external doors and accessible windows; and
viii. Information processing facilities managed by the licensed entity should be physically
separated from those managed by external parties.
Equipment should be situated in control and technical rooms within the licensed entity’s building
and in peripheral, potentially unoccupied, sites. Sometimes equipment is situated on external
party premises or in public environments. It may not be possible to achieve a comprehensive
level of physical protection for the peripheral sites; therefore, the risk should be evaluated and
mitigated where necessary by means of supplementary measures and compensating controls.

(contd.)
PES-2-2 Physical Entry Controls
Secure areas shall be protected by appropriate entry controls to ensure
Sub control
that only authorized personnel are allowed access.
The following guidelines may be considered:
i. The date and time of entry and departure of visitors should be recorded, and all visitors
should be escorted by employee. Visitors should only be granted access for specific,
authorized purposes and should be issued with instructions on the security requirements of
the area and on emergency procedures. The identity of visitors should be authenticated by
an appropriate means;
ii. Access to areas where confidential information is processed or stored should be restricted
to authorized individuals only by implementing appropriate access controls, e.g., by
implementing a two-factor authentication mechanisms such as an access card (something
you have) and secret PIN (something you know);
iii. A physical logbook or electronic audit trail of all access should be securely maintained and
monitored;
iv. All employees, contractors and external parties should be required to wear some form of
visible identification. The visitor badges should be visibly distinct and staff should be trained
to immediately notify security personnel if they encounter unescorted visitors and anyone
not wearing visible identification;
v. External party support service personnel should be granted restricted access to secure
areas or confidential information processing facilities only when required;
vi. Access rights to secure areas should be regularly reviewed, updated, and revoked when
necessary;
vii. Physical entry controls should ensure protection against tail gating and piggybacking;
viii. Monitoring of physical access to the facility should be carried out where the system resides
using physical intrusion alarms and surveillance equipment (CCTV etc.); and
ix. Periodic review physical access logs should be carried out.
The use of physical access control systems should also be considered for peripheral or public/
external sites where critical assets are located.

(contd.)
PES-2-3 Securing Offices, Rooms, and Facilities
Physical security controls shall be designed and implemented for
Sub control
security of offices, rooms, and operational facilities.
The following guidelines may be considered to secure offices, rooms, and operational facilities:
i. Key facilities should be sited to avoid access by public;
ii. Appropriate should be implemented to manage master keys and track/ logs key issuance.
iii. Where applicable, buildings should be unobtrusive and give minimum indication of their
purpose, with no obvious signs, outside or inside the building, identifying the presence of
information processing activities;
iv. Facilities should be configured to prevent confidential information or activities from being
visible and audible from the outside. Electromagnetic shielding should also be considered as
appropriate; and
v. Directories and internal telephone books identifying locations of confidential information
processing facilities should not be readily accessible to anyone unauthorized.

(contd.)
PES-2-4 Protecting Against External and Environmental Threats
Sites or buildings containing information, systems and information
facilities shall protected against damage from fire, natural disasters,
Sub control
earthquake, explosion, civil unrest, and other forms of natural or man-
made disasters.
The following guidelines should be considered to avoid damage from fire, natural disasters,
earthquake, explosion, civil unrest, and other forms of natural or man-made disaster:
i. Hazardous or combustible materials should be stored at a safe distance from a secure area;
ii. Fallback system and backup media should be sited at a safe distance to avoid damage from
a disaster affecting the main site;
iii. Appropriate firefighting equipment should be provided and suitably placed; and
iv. Adequate physical security to protect from explosion and attacks.
PES-2-5 Working in Secure Areas

Physical security protection shall be designed and implemented for
Sub control
working in secure areas.
The following guidelines may be considered for protection for working in secure areas:
i. Personnel can only be aware of the existence of, or activities within, a secure area on a
need-to-know basis;
ii. Unsupervised working in secure areas should be avoided both for safety reasons and to
prevent opportunities for malicious activities;
iii. Vacant secure areas should be physically locked and periodically reviewed; and
iv. Photographic, video, audio, or other recording equipment, such as cameras in mobile
devices, should not be allowed, unless authorized.

(contd.)
PES-2-6 Delivery and Loading Areas
Access points such as delivery and loading areas shall be protected
Sub control
from entry of unauthorized materials and persons.
The following guidelines may be considered to protect delivery and loading areas:
i. Access to a delivery and loading area from outside of the building should be restricted to
identified and authorized personnel;
ii. The delivery and loading area should be designed so that supplies should be loaded and
unloaded without delivery personnel gaining access to other parts of the building;
iii. The external doors of a delivery and loading area should be secured when the internal doors
are opened;
iv. Incoming material should be inspected and examined for explosives, chemicals or other
hazardous materials, before it is moved from a delivery and loading area;
v. Incoming and outgoing shipments should be physically segregated, where possible; and
vi. Incoming material should be inspected for evidence of tampering in route. If such tampering
is discovered, it should be immediately reported to security personnel.

(contd.)
PES-2-7 Securing Control Centers
Physical security measure shall be designed, developed, and applied to
Sub control protect sites or buildings having control centers, e.g., where control
system servers, HMI and supporting systems are housed.
This sub control is specific to ICS/ OT systems.
Following recommendation may be considered for protection control centers:
i. A site located on solid ground should be selected for constructing the control center; where
such solid ground is not available, appropriate measures should be taken in order to ensure
the sufficient load bearing capacity of the foundation soil;
ii. A site should be selected for control centers where the likelihood of environmental damage
from wind and water, etc. is minimal. If an existing site is vulnerable to such environmental
threats, appropriate measures should be taken in order to minimize damage;
iii. The site for control centers should be selected in such a manner that the potential for
damage due to strong electromagnetic fields is negligible. If an existing site is exposed to
strong electromagnetic fields, appropriate measures should be taken to protect control
system equipment rooms using electromagnetic shielding;
iv. Control centers should not be located at sites directly adjacent to facilities used for storing
dangerous materials that pose the threat of explosion or combustion;
v. If the control center is located in an area susceptible to natural disasters such as earthquake
etc., control center buildings should be of disaster-proof construction;
vi. Control center buildings should have of fire-proof or fire-resistant construction;
vii. Control center buildings should be designed with adequate structural stability to meet all
necessary floor loading requirements; for existing sites, appropriate measures should be
taken to ensure adequate structural stability to meet all necessary floor loading
requirements; and
viii. Automatic fire alarm systems including appropriate early detection and fire extinguishing
systems should be installed in control centers.

(contd.)
PES-2-8 Securing Equipment Rooms
Physical security measures shall be designed, developed, and applied
Sub control to protect equipment rooms where control system facilities are located,
should be designed, developed and implemented.

Following recommendation may be considered for protection of control system equipment
rooms:
i. The control system equipment rooms should be located where it is least endangered by
external influences such as extreme environmental conditions or natural disasters;
ii. The control system equipment room should be located where access by unauthorized
personnel is restricted;
iii. The control system equipment room should be located where it is least susceptible to
ingress of water. If the room does not fulfil this requirement, then the necessary measures
should be taken to prevent this, such as raising the floor level, watertight design of the
building or installing special water drainage facilities etc.;
iv. The control system equipment room should be located where it is best protected from strong
electromagnetic fields. Protection measures against electromagnetic interference should be
also applied if the control system equipment room is used as data storage room and/or for
data backup storage;
v. Components with increased security requirements should be placed in a dedicated control
system equipment room with heightened physical protection;
vi. In areas with a risk of earthquake, measures should be taken to prevent items and materials
used for the floor, walls, ceiling from collapsing and falling;
vii. Fire-proofing measures should be implemented for control system equipment and data
storage rooms;
viii. Measures should be taken to deal with malfunctions caused by static charges;
ix. Ducts connecting control system equipment rooms should be designed to slow down or
prevent the spread of fire;
x. Automatic fire alarms should be installed in control system equipment rooms and air-
conditioning facility rooms;
xi. Fire extinguishers should be installed in control system equipment rooms and air-
conditioning facility rooms;
xii. Control system equipment rooms should be air-conditioned when required. Availability of air
conditioning should be ensured, e.g., by protecting it against loss of electric power; and
xiii. Separate electronic earthing provisioning should be design for electronics equipment like
RTU, PLC, GPS, numerical relays, switches, routers, multiplexers, etc.
(contd.)
PES-2-9 Securing Peripheral Sites
Physical security controls shall be designed, developed, and
Sub control
implemented for control system equipment located in peripheral sites.

Components of the ICS/ OT systems infrastructure may be distributed across peripheral sites
that are frequently unoccupied. In order to protect such decentralized sites where control system
facilities are located, the following controls should be considered:
i. Where critical assets are operated at peripheral sites, automatic fire control equipment
should be installed;
ii. Peripheral sites should be monitored for the purpose of detecting component malfunctions,
power failures, fire, etc. Where necessary, air humidity and temperature should also be
monitored; and
iii. Where critical assets are operated at peripheral sites, adequate physically secure
perimeters should be installed (e.g., secure fencing). Additionally, an automatic alarm
system should be installed and monitored from a central location.
Where a sufficient level of physical protection for peripheral sites is not attainable, the risk
should be taken into consideration and mitigated by the application of appropriate
countermeasures. When selecting such countermeasures, the criticality of the assets operated
at these peripheral sites as well as redundancy and fallback concepts implemented for their
corresponding system functionality should be given primary consideration.

(contd.)
PES-3 Equipment Security
To prevent loss, damage, theft or compromise of IT/OT system
Objective
equipment.
PES-3-1 Equipment Siting and Protection

Equipment shall be sited in a secure manner and protected from loss,
Sub control
damage, theft, or unauthorized access.
The following guidelines may be considered to for siting and protecting equipment:
i. Equipment should be sited to minimize unnecessary access into work areas;
ii. Equipment handling sensitive data should be positioned carefully to reduce the risk of
information being viewed by unauthorized persons during their use;
iii. Equipment should be secured to avoid unauthorized access;
iv. Items requiring special protection should be safeguarded to reduce the general level of
protection required;
v. Controls should be adopted to minimize the risk of potential physical and environmental
threats, e.g., theft, fire, explosives, smoke, water (or water supply failure), dust, vibration,
chemical effects, electrical supply interference, communications interference,
electromagnetic radiation, and vandalism;
vi. Establish guidelines for eating, drinking, and smoking in proximity to information processing
facilities;
vii. Environmental conditions, such as temperature and humidity, should be monitored for
conditions which could adversely affect the operation of information processing facilities;
viii. Lightning protection should be applied to all buildings and lightning protection filters should
be fitted to all incoming power and communications lines;
ix. The use of special protection methods, such as keyboard membranes, should be
considered for equipment in industrial environments; and
x. Equipment processing confidential information should be protected to minimize the risk of
information leakage due to electromagnetic emanation.
Under certain circumstances, it is possible that system components of process control systems
and supporting infrastructure need to be installed in areas with extensive exposure to dust, heat,
cold, electromagnetic radiation, humidity, etc. The equipment should be suitably designed and
constructed to operate in such environmental conditions. Otherwise, additional protective
countermeasures, e.g., suitable external housing cabinets, should be implemented to ensure
reliable operation.

(contd.)
PES-3-2 Supporting Utilities
Equipment shall be protected from power failures and other disruptions
Sub control
caused by failures in supporting utilities.
Following recommendations may considered for protecting supporting utilities (e.g., electricity,
telecommunications, water supply, gas, sewage, ventilation, and air conditioning):
i. Conform to equipment manufacturer’s specifications and local legal requirements;
ii. Regularly appraise utilities for their capacity to meet business growth and interactions with
other supporting utilities;
iii. Inspect and regularly test utilities to ensure their proper functioning;
iv. If necessary, set alarms/ alerts to detect malfunctions;
v. If necessary, have multiple feeds with diverse physical routing; and
vi. Emergency lighting and communications should be provided. Emergency switches and
valves to cut off power, water, gas or other utilities should be located near emergency exits
or equipment rooms.
To avoid cyclic dependencies, all critical assets, communication services and other equipment
required for system restoration after a major power outage should be designed and operated so
that they are independent of external services for an appropriate period of time. This applies in
particular to external energy supplies.
Depending upon plans for system restoration, critical assets essential for system restoration
should be capable of being operated independently of an external power supply for an
appropriate time defined by system restoration plans. In remote areas, it should be necessary to
provide an independent power supply that can operate for several days. This includes for
example an automatic emergency power generator as well as the corresponding stockpile of
fuel. The organization should determine the necessary backup time for uninterruptible power
supplies for critical assets.

(contd.)
PES-3-3 Cabling Security
Power and telecommunication cabling used for IT/ OT systems shall be
Sub control
protected from interception, interference, or damage.
The following guidelines for cabling security may be considered:
i. Power and telecommunications lines into information processing facilities should be
underground, where possible, or subjected to adequate alternative protection;
ii. Power cables should be segregated from communications cables to prevent interference;
iii. For sensitive or critical systems further controls to consider include:
• Installation of armored conduit and locked rooms or boxes at inspection and termination
points;
• Use of electromagnetic shielding to protect the cables;
• Initiation of technical sweeps and physical inspections for unauthorized devices being
attached to the cables; and
• Controlled access to patch panels and cable rooms.
In energy sector, communication networks are installed over wide areas to allow communication
with peripheral sites and provide remote maintenance access. It is frequently not possible to
provide an equivalent level of protection for off-site cabling as for in-house cables. The
associated risks should be evaluated correspondingly and mitigated as far as possible by
implementing supplemental redundancy and physical measures. Depending on the security
requirements of transmitted data, additional non-physical measures such as cryptographic
protection should also be considered.

(contd.)
PES-3-4 Security of Equipment and Assets Off-premises
Security shall be applied to off-site assets taking into account the
Sub control
different risks of working outside the licensed entity’s premises.
The use of any information storing and processing equipment outside the entity’s premises
should be authorized by management. This applies to equipment owned by the licensed entity’s
and that equipment owned privately and used on behalf of the licensed entity.
The following guidelines may be considered for the protection of off-site equipment:
i. Equipment and media taken off premises should not be left unattended in public places;
ii. Manufacturers’ instructions for protecting equipment should be observed at all times, e.g.,
protection against exposure to strong electromagnetic fields;
iii. Controls for off-premises locations, such as home-working, teleworking and temporary sites
should be determined by a risk assessment and suitable controls applied as appropriate,
e.g., lockable filing cabinets, clear desk policy, access controls for computers and secure
communication with the office; and
iv. When off-premises equipment is transferred among different individuals or external parties,
a log should be maintained that defines the chain of custody for the equipment including at
least names and organizations of those who are responsible for the equipment.
PES-3-5 Unattended User Equipment

Adequate security measures shall be implemented to protect
Sub control
unattended equipment.
All users should be made aware of the security controls for protecting unattended equipment.
Users may be advised to:
i. Terminate active sessions when finished, unless they should be secured by an appropriate
locking mechanism, e.g., a password protected screen saver;
ii. Log-off from applications or network services when no longer needed; and
iii. Secure computers or mobile devices from unauthorized use by a key lock or an equivalent
control, e.g., password access, when not in use.

(contd.)
PES-3-6 Clear Desk and Clear Screen Policy
A clear desk policy for papers and removable storage media and a clear
Sub control
screen policy for systems shall be implemented.
The clear desk and clear screen policy may take into account the information classifications,
legal and contractual requirements and the corresponding risks and cultural aspects of the
organization. The following guidelines should be considered:
i. Sensitive or critical business information, e.g., on paper or on electronic storage media,
should be locked away (ideally in a safe or cabinet or other forms of security furniture) when
not required, especially when the office is vacated;
ii. Computers and terminals should be left logged off or protected with a screen and keyboard
locking mechanism controlled by a password, token or similar user authentication
mechanism when unattended and should be protected by key locks, passwords or other
controls when not in use;
iii. Unauthorized use of photocopiers and other reproduction technology (e.g. scanners, digital
cameras) should be prevented; and
iv. Media containing sensitive or classified information should be removed from printers
immediately.
In the ICS/ OT systems, HMIs often cannot be left logged off or protected by screen savers, e.g.,
HMIs of SCADA systems or data logger displays. It should be ensured that such HMIs are either
installed in a physically protected location with permanent human supervision (e.g., a control
center) or that they are in a display mode only (i.e. only non-critical actions can be executed).

(contd.)
PES-4 Security of Equipment hosted outside Entity Premises
To protect equipment located outside of the licensed entity’s premises
Objective
against physical and environmental threats.
PES-4-1 Equipment Sited Outside Premises

Equipment sited outside the premises of the licensed entity shall be
Sub control
protected from environmental threats and unauthorized access.
This sub control is specific to ICS/ OT systems
Examples of equipment specific to OT environments that might be sited outside of entity
premises may include line distance protection relays, line differential protection relays,
multiplexers etc.
Following recommendation may be considered for siting equipment outside the licensed entity:
i. Responsibility of protecting equipment outside licensed entity premises should be specified;
ii. There should be agreements with the other parties for the supply of supporting infrastructure
services such as energy supply, cooling etc.; and
iii. It should be ensured that the operational sites where equipment is to be installed, fulfil all
the necessary security requirements. A site risk assessment might be carried out to identify
potential risks and appropriate countermeasures.
PES-4-2 Equipment Sited on Customer’s Site

Equipment sited on the customer’s site shall be protected from
Sub control
environmental threats and unauthorized access.

Examples of equipment specific to OT environments that might be sited at customer premises
are smart meters, home automation devices, wireless routers, etc.
Following recommendation may be considered for siting equipment at customer’s site:
i. The responsibility of protecting the equipment at customer site should be specified;
ii. The equipment cabinets installed at the customer’s site should be sturdy and should be
tamper resistant i.e. difficult to open by unauthorized persons;
iii. Any form of manipulation should be easily detectable; and
iv. It should be possible to securely monitor the status of and/or operate equipment remotely.
(contd.)
PES-4-3 Interconnected Control and Communication Systems
Where control systems and related communication lines are
interconnected with those of external parties, the range of responsibility
and interfaces with the external party should be clearly defined such
Sub control
that it is possible to disconnect and isolate each organization from the
others within an appropriate period of time in order to avoid identified
risks.

Examples of equipment specific to OT environments that might be used for interconnection with
external parties are data servers, report servers, Inter-Control Centre Communications Protocol
servers, etc.
Licensed entity may consider following security measures for control and communication
systems:
i. Energy utility organizations should monitor the status of their interconnections.
ii. In order to diagnose problem areas and take corrective actions, organizations should have a
means for isolating the connections between themselves and external parties and for
reconnecting isolated connections, where necessary.
iii. Energy utility organizations should specify in contracts or agreements that the system
interconnections can be suspended in cases where severe interference occurs with the
organization’s own services.
iv. The criteria and conditions necessary for the suspension of system interconnections should
be clearly defined. Moreover the possible impacts of suspending system interconnections
should be evaluated and if necessary fallback measures should be defined and prepared,
where necessary.

Third Party Risk Management
TPRM
Third Party Risk Management (TPRM) (contd.)
Objective
To ensure that security controls are in place to identify, evaluate, monitor, and manage the risks
associated with third parties (e.g., third party, suppliers, service providers etc.).
Description
In energy sector entities are relying on third parties more than ever before to achieve their
business objectives. This growing dependency exposes the companies to new risks that need to
be managed. While services and functions can be outsourced, it is important to note that the
risks associated with these processes are still the responsibility of the company. Adequate due
diligence needs to be undertaken to ensure that external stakeholders are compliant with the
licensed entity’s security requirements.
Applicability
assessment.
Cybersecurity in Third Party Relationships
Third Party Risk

Management
Third Party Service Delivery

Management

TPRM-1 Cybersecurity in Third-party Relationships
To ensure protection of the licensed entity’s assets that are accessible
Objective
by suppliers.
TPRM-1-1 Third Party Risk Management Standard

A third-party risk management standard shall be documented,
Sub control established, and reviewed periodically, for managing the cybersecurity
risks associated with third parties.
The licensed entity should identify and enforce cybersecurity controls to address third party risks
to the licensed entity’s information assets. The Third-Party Risk Management standard should
lay down cybersecurity requirements, covering the entire supplier lifecycle.
The objective of this standard is to establish a standardized process for managing risks
associated with supplier relationships. The licensed entity can consider including the following
sections in the Third-Party Security Standard:
i. Third-Party Universe/ List:
• This section will detail process for identifying various third parties and creating a formal
record of all third parties;
• The third-party universe would be a listing of third parties, the services they provide, their
category (e.g., supplier, service provider, IT /OT product support, logistics provider etc.);
• Criteria for assessing the third-party criticality (e.g., impact on Confidentiality /Integrity/
Availability /Safety (C, I, A, S) of the process/ product where third party services are
required);
• Integration with the procurement process, to ensure that the third-party universe gets
updated upon onboarding of a new third party or removal of a third part; and
• Periodically reviewing the third-party risk universe as a corrective control measure, to
verify completeness and accuracy of the third-party universe.
ii. Risk Assessment:
This section will mandate the requirement to conduct a risk assessment when external
support is required to determine the security implications and identify control requirements;
iii. Third-Party Agreements:
This section will mandate the cybersecurity related clauses that need to be added in the
third-party agreements;
iv. Third-Party Access:
This section will specify the due diligence that needs to be undertaken while provisioning
access for the third parties;

TPRM-1-1 Third Party Risk Management Standard
v. Performance Measurement:
This section will include requirements related to defining performance standards / SLA and
remedies for failure to meet the agreed standards;
vi. Third-Party Audits/Assurance:
This section will contain requirements to conduct periodic assessments/ audits to assess the
compliance of third parties with the agreed cybersecurity related clauses and also to validate
adherence of the third party to the agreed set of cybersecurity controls.
This review may also include validating that the controls identified in step ii above are
operating as desired; and
vii. Third-Party Risk Management standard should be reviewed periodically and in case of major
changes.
and include them in the Third-Party Risk Management standard, as applicable, based on the risk
assessment.

TPRM-1-2 Third Party Risk Assessment
Risk assessment shall be carried out to determine the security
Sub control
implications and control requirements while engaging third parties.
Since the third-party risks (and thereby the risk mitigation requirements) will vary from case-to-
case basis, depending on the product or service offered by the third party, an effective way to
address such risks is to conduct a formal risk assessment. This third-party risk assessment will
entail looking at specific cases, identifying various possible risks and recommending appropriate
controls. Further, the security requirements identified from risk assessment should be included
as security requirements in third party agreement.
The risk assessment should consider the type of access, the criticality of information, controls
employed by the third party, type of service or product being provided by the third party and the
possible security implications. Further, the risk assessment should also consider resilience and,
if necessary, recovery and contingency arrangements to ensure the availability of the information
or information processing services provided by the third party.


TPRM-1-3 Third Party Access Control
Access to third parties shall be provided on need basis, post the due
Sub control
approvals, and monitored.
Third parties access provisioning, deprovisioning and modifications should be done in line with
the requirements of the Access Control Procedure
Additional considerations for third party access control are as follows:
i. Access Provisioning:
• All third party physical and logical access should be provided after due approvals, based
on principles of ‘need to know’ and ‘least privileges’ and only for the period which it is
required;
• Wherever technically feasible, third party user accounts should be created with specific
end dates, so that they are automatically disabled at the pre-defined time; and
• While naming the account for third party users, the licensed entity can consider adding the
prefix ‘External’ (or Ext), ‘Consultant’ (or ‘Con’) etc. to distinguish them from normal
employee accounts.
ii. Access De-Provisioning:
• The concerned stakeholders like project manager, team leads etc. that have solicited the
services of a third party are responsible for informing the system administrators (or other
appropriate employees) for revoking the access upon exit of the third party or termination
of agreement; and
• The access of third parties should be disabled and assets should be collected upon their
exit in a timely manner. The third-party access to the IT/ OT systems should be reviewed
periodically.
iii. Onsite third-party access:
• If the third-party users who would connect to the licensed entity’s network, their machine
should meet the licensed entity’s security standards;
• The licensed entity’s employees should always accompany the third-party personnel
working at critical areas such as data center, control rooms etc.;
• All Third party working onsite should be provided ID badges, which are different than the
one used by employees; and
• Third party should be provided access to the respective work areas only.
iv. Remote Access Support:
• Refer NSM-4-1 (Remote Access Management) for guidelines pertaining to remote access;
• Connection time restrictions should be defined in the IT/ OT systems. The defined
restriction would depend on the activity for which remote access is to be given to the third
party;

TPRM-1-3 Third Party Access Control
• All access to IT/ OT systems should be restricted, logged, and monitored; and
• For third party that needs occasional access to IT/ OT systems for remote
troubleshooting, the access should be provided only for the required duration and then
should be promptly disabled.

TPRM-1-4 Third Party Agreements
All relevant cybersecurity requirements shall be established and agreed
Sub control with each third party that may access, process, store, communicate, or
provide technology components to the licensed entity.
Third party agreements should be established and documented to ensure that there is no
misunderstanding between the licensed entity and the third-party regarding obligations to fulfil
relevant cybersecurity requirements.
Agreements should be clearly written and sufficiently detailed to provide assurance for scope,
duration, performance, reliability, security, protection of Intellectual Property Rights and
reporting, privacy, right to audit, data ownership, sub-contracting, cybersecurity requirements,
pre termination of agreement etc.
The following contractual terms should be considered for inclusion in the agreements in order to
satisfy the cybersecurity requirements:
i. The agreement between the licensed entity and third party should consider all risk factors
identified during the third-party risk assessment;
ii. The agreement should address the third party’s responsibility and obligation for adherence
to all relevant clauses of the licensed entity’s Cybersecurity Policies;
iii. The agreement should have clear definition of the cybersecurity roles and responsibilities of
the third party;
iv. The agreement should address legal and regulatory requirements, including data protection,
intellectual property rights and copyright etc.;
v. The agreement should address the service continuity and availability requirements, add
require the third party to maintain sufficient service capability together with workable plans
designed to ensure that agreed service continuity levels are maintained following major
service failures or disaster;
vi. The agreement should address arrangements for reporting, notifying, and investigating
cybersecurity incidents as well as sharing of information regarding the supply chain and any
potential issues and compromises among the suppliers;
vii. The agreement should address the agreed service levels and the contract should be bound
by a strong SLA to ensure that the service provider provides a defined level of service
continuously and efficiently without impacting the security and operations:
• The performance monitoring and reporting criteria should be included in the contractual
requirements. Remedies for failure to meet agreed standards should also be documented,
these should include mutually acceptable punitive clauses to handle breach of SLA.
viii. The agreement should require providing confirmation to the licensed entity that background
verification has been performed for all third-party personnel having access to licensed
entity’s information and IT/ OT systems;

ix. The agreement should address conditions for termination, re-negotiation of agreements and
procedures for defect and conflict resolution. Further, the agreement should state
termination and notification requirements with time frames to allow the orderly conversion to
another third party;
x. The agreement should address the respective liabilities of the parties to the agreement;
xi. The agreement will include provision for monitoring and reviewing supplier/ third party
activities involving access to the licensed entity’s sensitive information and IT/ OT systems;
xii. The agreements should include a right to audit clause, giving the licensed entity the right to
audit the third-party facilities where the licensed entity’s information is hosted or from where
the licensed entity’s IT/ OT systems are accessed; and
xiii. Terms for information to be returned or destroyed at agreement cessation;
xiv. The agreement should also include provisions related to subcontracting:
• Approval should be obtained from the licensed entity before getting into any sub-
agreement. The clause should specify that licensed entity’s prior approval is required for
sub – contracting and the licensed entity has the right to approve or disapprove the sub-
contracting of complete or part of service that the third party is responsible for;
• The primary third party should provide the assurance of capability of sub-agreement party
to meet the cybersecurity requirements of the licensed entity and is also responsible for
ensuring that the sub-agreement party complies with all security requirements; and
• The third party would be responsible for the service provided to the licensed entity
regardless of whether the fourth party is actually conducting the operations (sub-
contracting).
The above security requirements should be addressed in agreements and signed-off by
authorized personnel from the licensed entity and third party. Backup copies of the agreements
should be maintained.
Further, the third party should sign a non-disclosure agreement before commencement of their
work to prohibit the third party and its employee from using or disclosing any information related
to the licensed entity which they might get access to during the engagement with the licensed
entity.
Under the terms of contractual agreements, it should be ensured that the protection
requirements of information related to critical assets are given sufficient consideration.
Specifically, for ICS/ OT environment there should be an agreement with third-party to provide
spares as when required within decided timeframe and notify an entity about end-of-life of their
products at least 1 year prior to it.

Asset owners should review all contracts that involve third party access to their process control
systems. Asset owners should also assess the need for third party access to their process
control systems.
Where telecommunication services for the process control systems used by the licensed entity
are supplied by external parties, special requirements relating to crisis and emergency
communication, in the case of major blackouts, natural disasters, incidents or other possible
emergency situations, should be defined, contractually specified, and monitored. This applies to
any necessary pre-emptive measures that can be necessary to take to avoid service overload
and to ensure an acceptable degree of independence of the telecommunication services from
external energy supply (blackout resistance).

TPRM-1-5 Information and Communication Technology Supply Chain
Agreements with suppliers shall include requirements to address the
Sub control cybersecurity risks associated with information and communications
technology services and product supply chain.
The following topics should be considered for inclusion in supplier agreements concerning
supply chain security:
i. Defining cybersecurity requirements to apply to information and communication technology
product or service acquisition in addition to the general cybersecurity requirements for
supplier relationships;
ii. For information and communication technology services, requiring that suppliers propagate
the licensed entity’s security requirements throughout the supply chain if suppliers have
subcontract for parts of information and communication technology service provided to the
licensed entity;
iii. For information and communication technology products, requiring that suppliers propagate
appropriate security practices throughout the supply chain if these products include
components purchased from other suppliers;
iv. Implementing a monitoring process and acceptable methods for validating that delivered
information and communication technology products and services are adhering to stated
security requirements;
v. Implementing a process for identifying product or service components that are critical for
maintaining functionality and therefore require increased attention and scrutiny when built
outside of the licensed entity especially if the top tier supplier outsources aspects of product
or service components to other suppliers;
vi. Obtaining assurance that critical components and their origin can be traced throughout the
supply chain;
vii. Obtaining assurance that the delivered information and communication technology products
are functioning as expected without any unexpected or unwanted features;
viii. Defining rules for sharing of information regarding the supply chain and any potential issues
and compromises among the licensed entity and suppliers; and
ix. Implementing specific processes for managing information and communication technology
component lifecycle and availability and associated security risks. This includes managing
the risks of components no longer being available due to suppliers no longer being in
business or suppliers no longer providing these components due to technology
advancements.

TPRM-2 Third Party Service Delivery Management
To maintain an agreed level of cybersecurity and service delivery in line
Objective
with third party agreements.
TPRM-2-1 Monitoring and Review of Third Party Services

The licensed entity shall regularly monitor, review and audit supplier
Sub control
service delivery.
It is vital to ensure that the third parties adhere to the cybersecurity terms and conditions
recorded in the agreements on an ongoing basis. Further, periodic review of the service
performance is also crucial to ensure that third parties are meeting the agreed services levels.
Service performance monitoring process and acceptable methods for validating the service
delivery should be followed in order to maintain good quality service. The process to be
implemented to measure and monitor performance of the third parties may include the below
considerations:
i. Third party should be required to periodically submit service reports and the reports so
generated must be validated and reviewed by the licensed entity stakeholders for accuracy
and completeness;
ii. Periodic service review meetings should be held with the third-party representatives to
review the service and adherence to the agreed SLAs by the third party;
iii. These service review meeting should be focused on:
• Review of service delivery reports;
• Identifying opportunities of improvement;
• Review records of cybersecurity events, operational problems, failures, tracing of faults
and disruptions related to the service delivery; and
• Way to resolve identified problems in an expeditious manner.
iv. The relationship owners should participate in these periodic review meetings with the third-
party service provider to discuss the performance reports;
v. Minutes of all such meetings must be prepared, communicated to the third-party service
providers and copies maintained;
vi. Appropriate penalty actions should be initiated (if required) for gaps identified in the
performance or quality of the services delivered; and
vii. The contract termination/ renewal decisions should also consider the past performance of
the third party.

TPRM-2-1 Monitoring and Review of Third Party Services
Further, the review to ensure that third party is adhering to the agreed cybersecurity
requirements should also be carried out. This review can be done under the ambit of a broader
TPM framework. The said framework should cover (but not limited to) creating and then
periodically refreshing the list of all third parties, assessing the third-party criticality (e.g., based
on C,I,A,S and BIA etc.), identifying any cybersecurity risks, modes of assessment i.e., validation
of adherence to cybersecurity requirements based on third party criticality (e.g., onsite
assessment at third party premises, self-assessment questionnaires, third party attestation etc.).

TPRM-2-2 Managing Changes to Third Party Services
Changes to the provision of services by suppliers, including maintaining
and improving existing cybersecurity policies, procedures, and controls,
Sub control shall be managed, taking account of the criticality of business
information, systems and processes involved and re-assessment of
risks.
The following type of changes may warrant a re-assessment of risks and adjusting in the
agreements:
i. Changes to supplier agreements;
ii. Changes made by the licensed entity to implement;
• Enhancements to the current services offered;
• Development of any new applications and systems;
• Modifications or updates of the licensed entity’s policies and procedures; and
• New or changed controls to resolve cybersecurity incidents and to improve security.
iii. Changes in supplier services to implement:
• Changes and enhancement to networks;
• Use of new technologies;
• Adoption of new products or newer versions/releases;
• New development tools and environments;
• Changes to physical location of service facilities;
• Change of suppliers; and
• Sub-contracting to another supplier.
If based on the reassessment of third-party risks, any modifications are required to be made in
the cybersecurity requirements documented in the agreement, the agreement should be
changed/modified if deemed necessary and once the changes are vetted the modified
agreement should be signed by both the parties.
Further, the requirements for managing the necessary transitions of information, information
processing facilities etc. (triggered by virtue of above changes) should be identified and it should
be ensured that cybersecurity is maintained throughout the transition period.

TPRM-2-3 Software Source Code Escrow
Escrow of software source code shall be considered for software that is
Sub control
considered critical to business.
For software that are considered critical for operations, when outsourcing software development,
or procuring customized software, the licensed entity should consider either obtaining full
ownership of the software or establishing escrow agreements. This escrow agreement will
provide licensed entity access to source code and documentation under pre-defined conditions.
Software source code escrow agreement with third party may include following:
i. Purpose of source code escrow;
ii. Detail requirement of software source code and its usage;
iii. Liability of escrow agent;
iv. Terms of release of source code by escrow agent to the licensed entity;
v. Fees; and
vi. Effective waiver.
Source code, in the energy sector, also includes application programming and parametrization
data of digital controllers and automation components.

Vulnerability Management
VM
Vulnerability Management (VM)
Objective
To manage the risks associated with technical vulnerabilities, by establishing good vulnerability
and patch management practices.
Description
VM refers to the proactive practice of managing the security weaknesses that exist in the
technology systems. It is an ongoing process that includes identifying, prioritizing, and mitigating
the technical security flaws that might exist in systems in a risk prioritized and timely manner.
Applicability
assessment.
Vulnerability Identification of
Management Vulnerabilities
Procedure
Vulnerability
Management
Deployment of Evaluation and

Patches Prioritization of
Vulnerabilities

Vulnerability Management (VM) (contd.)
VM-1 Vulnerability Management
To protect the licensed entity from risks that can arise from exploitation
Objective
of technical vulnerabilities that might exist in the systems.
VM-1-1 Vulnerability Management Procedure

Vulnerability Management procedure shall be documented, established,
requirements.
Following are the broad steps around which the VM procedure can be designed:
i. Identify:
Proactive process for obtaining information about technical vulnerabilities, for IT/ OT
systems being used in the licensed entity’s environment;
ii. Evaluate and Prioritize:
Evaluation of the vulnerability announcements/ notifications, to see applicability and relevant
for the licensed entity’s environment. Defining criteria to prioritize vulnerability remediation.
Methodology for prioritizing the patch implementation/ remedial actions based on criticality of
systems impacted and the vulnerability Common Vulnerabilities and Exposures (CVE) score
etc.; and
iii. Remediate:
Taking appropriate and timely action, ensuring the change management process is followed
while implementing patches.
These broad steps (Identify, Evaluate and Prioritize, Remediate), along with implementation
guidance have been elaborated in the controls and sub controls of this domain.
Other key aspects that the licensed entity should consider including in the VM procedure are:
i. Roles and responsibilities associated with VM, including vulnerability monitoring,
vulnerability risk assessment, patching, asset tracking and any coordination responsibilities
required;
ii. Integration of VM process with asset induction process, to ensure that new assets are
proactively scanned for any vulnerabilities before they are commissioned. (refer AM-2-1
(Induction of Information Assets));
iii. Defining a timeline SLA to react to notifications of potentially relevant vulnerabilities;
iv. Outline the process to be followed for deploying patches and verifying its effectiveness (or
reference to appropriate clauses of change management procedure; and
v. Requirement to review the VM procedure periodically and in case of major changes.
Further, the licensed entity may consider the controls mentioned in this domain and include them
in the VM procedure, as applicable, based on the risk assessment.

VM-1-1 Vulnerability Management Procedure
Owing to the special characteristics of the ICS/ OT environment, the licensed entity may
consider developing a separate VM Procedure for ICS/ OT environment, considering the safety
aspects, criticality of plant operations and availability of scheduled maintenance windows to
deploy patches etc.

VM-1-2 Identification of Vulnerabilities
Formal process to identify vulnerabilities that might exist in the systems
Sub control
shall be established.
Timely identification of vulnerabilities and their remediation is one of the critical Cybersecurity
controls with respect to protecting the licensed entity’s IT/ OT environments from cyber threats.
The licensed entity should consider two-pronged approach to identify the technical security
vulnerabilities, i.e., establish a proactive process as well as a detective process, as elaborated
below:
i. Proactive monitoring for vulnerability information:
• The licensed entity should Identify different sources of information that have to be
monitored for vulnerability notifications, advisories, announcements etc.;
• These information sources would depend on the systems that are deployed in the
licensed entity’s environment and should be updated based on changes in the asset
inventory or when other new or useful resources are found;
• There are several types of sources available for receiving the information about
vulnerabilities. The most common types of resources are as follows:
o Third party web sites and mailing lists;
o Third-party web sites;
o Third-party mailing lists and newsgroups; and
o Vulnerability databases.
• Enterprise patching tools usually provide lists of all patches available from supported third
party, which alleviates the licensed entity from constantly having to monitor a large
number of third party security web sites and mailing lists; and
• The licensed entity can also consider opting for paid subscriptions, that are provided by
various service providers, regarding threat and vulnerability notifications.
ii. Periodic vulnerability scanning:
• The licensed entity can consider deploying automated vulnerability scanning tools;
• These tools can scan the assets connected to the network and, they can report the list of
missing patches/ firmware upgrades along with the severity rating;
• Having a current and complete asset inventory is a prerequisite for effective
implementation of the periodic scanning activity. The asset induction process should
include a checkpoint to validate that the new asset being inducted has been integrated
with the patch management and vulnerability scanning tools (refer AM-2-1 (Induction of
Information Assets));

VM-1-2 Identification of Vulnerabilities
• The licensed entity can leverage the asset inventory and can consider developing annual
vulnerability scanning calendars (vulnerability scanning plan) that contains the listing of
assets to be scanned, periodicity at which they would be scanned based on the asset
criticality and assessment type (monthly, quarterly, annually etc.) as well as the when they
would be scanned. This vulnerability scanning plan must be approved by the asset owns
prior to performing the scan on the assets; and
• This process should also include periodic assessment of IP’s, applications, servers,
devices and other critical systems in production environment to ensure that all critical
systems have been integrated with the scanning tool.
All vulnerabilities identified either from manual monitoring or automated scanning activities
should be reported to the asset owner (or other concerned stakeholders) for remediation.
The licensed entity should consider developing an annual security assessment calendar wherein
the various types of security assessments (e.g., wireless PT, web application security
assessment, internal and external PT) can be planned as applicable and based on risk
assessment to identify potential vulnerabilities that could be exploited.
For ICS/ OT systems the licensed entity should ensure that agreements with system integrators
and system third party have the clauses related to third party obligation to notify the licensed
entity about the vulnerabilities that effect their systems as well as remediation steps.
Process of identification of vulnerabilities in online ICS/ OT systems should be done via passive
scanning. Active scanning to identify vulnerabilities should only be performed in non-production
ICS/ OT systems or by taking outage of ICS/ OT systems.

VM-1-3 Evaluation and Prioritization of Vulnerabilities
The licensed entity shall evaluate each identified vulnerability based on
Sub control
its potential impact on the entity to prioritize remediation efforts.
For evaluating the vulnerabilities, the licensed entity should determine the significance of the
threat or vulnerability. This evaluation should consider the following guidance:
i. Applicability of the vulnerability to the licensed entity’s environment;
ii. Third party reported criticality (CVE, Common Vulnerability Scoring System (CVSS) etc.);
iii. Likelihood of the vulnerability being exploited (e.g., existence of a known exploit or other
malicious code that uses the vulnerability as an attack vector);
iv. Impact on the systems, the licensed entity, and network if the vulnerability is not removed
and is exploited;
v. Criticality of the affected systems; and
vi. Any compensating controls or other relevant factors that might reduce the urgency to apply
certain patches or applying patches in certain parts of the network. For example, if the
licensed entity disables certain functionality within their browsers (e.g., scripting languages),
then applying patches that fix vulnerabilities within those scripting languages is not a
priority).
This evaluation exercise should lead to a risk/ criticality score being assigned to each
vulnerability, in the licensed entity’s context. This risk score then would be used in development
of prioritized remediation plans.
To further strengthen the process, the licensed entity can consider defining remediation SLAs
based on vulnerability risk/ criticality score.
The criteria to prioritize and plan vulnerability remediation for ICS/ OT systems may also include
impact on safety and plant operations. Scheduled outages/ maintenance periods of plant or ICS/
OT systems may be factored while planning for patch deployments.

VM-1-4 Deployment of Patches
The licensed entity shall deploy vulnerability patches and remediations
Sub control
and shall verify its effectiveness.
Following are the typical methods to remediate the identified vulnerabilities:
i. Security Patch Installation:
Applying a security patch that mitigates the vulnerability;
ii. Configuration Adjustment:
Adjusting how an application or security control is configured may effectively block attack
vectors and reduce the threat of exploitation. Common configuration adjustments include
disabling services and modifying privileges, as well as changing firewall rules and modifying
router access controls. Settings of vulnerable software applications can be modified by
adjusting file attributes or registry settings etc.; and
iii. Software Removal:
Removing or uninstalling the affected software or vulnerable service eliminates the
vulnerability and any associated threat. This is a practical solution when a software is not
needed on a system.
Precautions should be taken before applying the identified patches (or other remediation
measures). These include:
i. Patch Authentication:
The downloaded patch should be checked against any of the authenticity methods the third
party provides, including cryptographic checksums, Pretty Good Privacy signatures, and
digital certificates;
ii. Malware Scanning:
A virus scan should be run on all patches before installation;
iii. Testing:
Patch deployment and configuration modifications should follow the licensed entity’ change
management procedure. Patches and configuration modifications should be tested on non-
production systems (where feasible) prior to deployment;
iv. Approval:
All patches must obtain the appropriate change control approval prior to deployment on
production systems and should be performed during an authorized maintenance time
window unless there is an urgent situation; and
v. Verification:
Post patch deployment, verification of successful closure of vulnerabilities (e.g., by
performing re-scans/clean scans or by reviewing patch logs) should be carried out.

VM-1-4 Deployment of Patches
In case any patches cannot be deployed immediately (or not deployed at all) owing to legacy
issues, technical limitations and/ or operational aspects, supplementary controls like isolation of
specific devices or systems, robust access controls, firewall protection, disabling ports etc.
should be implemented to mitigate the risk.
To further strengthen the process, the licensed entity can consider sharing with entity’s executive
management, reports of high-level information including number of vulnerabilities identified in the
environment, historical trending of vulnerability numbers, categories or types of vulnerabilities,
historical remediation response time frames, open critical security vulnerability with aging etc.


Domain Mapping 06
Domain Mapping
DoE,
ISO NIST IEC
Cybersecurity Others
27001 800-53 62443-3-3
Framework
Cybersecurity Organization of
Governance information
security
Cybersecurity Risk Information risk Risk ISO/IEC 27005
Management management Assessment NIST 800-30
(clause-8)
Cybersecurity Performance
Performance evaluation
Evaluation (clause-9)
Asset Asset System and FR 3 – System
Management management Information integrity
Integrity
FR 4 – Data
Media confidentiality
Protection
Backup Operations
Management security
(Backup)
Cloud Security ISO/IEC 27017
Configuration and Operations Configuration

Change security (Change Management
Management management)
Cryptography Cryptography SR 1.8 – Public
Control key infrastructure
(PKI) certificates
SR 1.9 –
Strength of
public key
authentication

Domain Mapping
DoE,
ISO NIST IEC
Cybersecurity Others
27001 800-53 62443-3-3
Framework
Data Protection Compliance PII Processing GDPR
and Privacy (Privacy and and
protection of Transparency
personally
identifiable
information)
Human Resource Human resource Personnel
Security security Security
Awareness and
Training
Identity Access Access control Access Control FR 1 –
Management Identification
Identification and
and authentication
Authentication control
FR 2 – Use
control
Cybersecurity Information Contingency FR 7 – AE/SCNS/NCE
Continuity security aspects Planning Resource MA 7000:2021
Management of business availability
continuity
management
Cybersecurity in Organization of
Project information
Management security
(Information
security in project
management)
Cybersecurity Information Incident NIST 800-61
Incident Security Incident Response
Management Management

Domain Mapping
DoE, Cybersecurity ISO NIST IEC
Others
Framework 27001 800-53 62443-3-3
Legal, Contractual and Compliance
Regulatory Compliance
Logging and Monitoring Operations Assessment, FR 6 – Timely
security Authorization response to
(Logging and , and events
monitoring) Monitoring
Network Security Communicati System and FR 3 – System
Management ons security Communicati integrity
ons
Protection FR 5 –
Restricted data
flow
Physical and Physical and Physical and
Environmental Security environment Environment
al security al Protection
Third-party Risk Supplier Supply Chain FR 7 – Resource
Management relationships Risk availability
Management
Vulnerability Operations
Management security
(Technical
vulnerability
management
)

Annexures 07
Annexure I: Cybersecurity Risk Management Process
Cybersecurity Risk Management Process
The cybersecurity risk management process can be applied to the licensed entity as a whole,
any discrete part of the entity (e.g. a department, a physical location, a service), any IT/ OT
system, existing or planned or particular aspects of control (e.g. business continuity planning,
third-party, etc.). The licensed entity should consider an iterative approach for risk management
process. The iterative approach provides a good balance between minimizing the time and effort
spent in identifying controls, while still ensuring that high risks are appropriately assessed.
Following figure illustrates iterative process for the cybersecurity risk management.
Context Establishment
Risk assessment
Risk identification
Risk communication and consultation
Risk monitoring and review

Risk analysis
Risk evaluation
RISK DECISION POINT1 No

Assessment satisfactory
Yes
Risk treatment
RISK DECISION POINT 2

No
Treatment satisfactory
Yes
Risk acceptance
Figure-1
The cybersecurity management process include following step:

i. Context establishment:
Context for cybersecurity risk assessment should be establish to define scope of risk
assessment, IT/ OT systems to be considered, business process involved, and stakeholder
roles and responsibilities.

(contd.)
ii. Risk assessment:
Risk assessment is conducted after context is established. Risk assessment is performed to
identify, analyze, and evaluate cybersecurity risks. It provides information to effectively
determine the action required to manage the risks to an acceptable level. If the information is
insufficient then another iteration of the risk assessment with revised context will be
conducted, possibly on limited parts of the total scope (see Figure-1, Risk Decision Point 1).
Risk treatment follows after sufficient information is available to manage the risk.
iii. Risk treatment:
Risk treatment involves a cyclical process of:
• Assessing risk treatment;
• Deciding whether residual risk levels are acceptable;
• Generating a new risk treatment if risk levels are not acceptable; and
• Assessing the effectiveness of that treatment.
It is possible that the risk treatment will not immediately lead to an acceptable level of
residual risk. In this situation, another iteration of the risk assessment with changed context
parameters, if necessary, may be required, followed by further risk treatment (see Figure-1,
Risk Decision Point 2).
iv. Risk acceptance:
The risk acceptance activity has to ensure residual risks are explicitly accepted by the
licensed entity. This is especially important in a situation where the implementation of
controls is omitted or postponed, e.g. due to cost, business operation, etc.
iv. Risk communication and consultation:
During the whole cybersecurity risk management process it is important that risks and their
treatment are communicated and consulted with the appropriate stakeholder. Even before
the treatment of the risks, information about identified risks can be very valuable to manage
incidents and may help to reduce potential damage. The detailed results of every activity of
the cybersecurity risk management process and from the two risk decision points should be
documented.
iv. Risk monitoring and review:
Risks are not static. Threats, vulnerabilities, likelihood or consequences may change
abruptly without any indication. Therefore constant monitoring is necessary to detect these
changes. This may be supported by external services that provide information regarding new
threats or vulnerabilities. The licensed entity should ensure that the following are continually
monitored:
• New assets that have been included in the risk management scope;
• Necessary modification of asset values, e.g. due to changed business requirements;

(contd.)
• New threats that could be active both outside and inside the organization and that have
not been assessed;
• Possibility that new or increased vulnerabilities could allow threats to exploit these new or
changed vulnerabilities;
• Identified vulnerabilities to determine those becoming exposed to new or re-emerging
threats;
• Increased impact or consequences of assessed threats, vulnerabilities and risks in
aggregation resulting in an unacceptable level of risk; and
• Cybersecurity incidents.
Cybersecurity Risk Assessment Approaches

The below section illustrates various approaches for conducting risk assessments. These are not
to be purported as a mandated way of conducting the risk assessments, but are being listed
only for guidance. The licensed entities may adopt these, customize these or use any other
industry accepted risk assessment methodologies. Further, to aid in consistency of risk
management practices and risk communications internally, it would be prudent to align the
cybersecurity risk assessment methodology, with the existing enterprise risk assessment
methodologies/ frameworks that might be already in use in the entity.
Cybersecurity risk assessment process involves in-depth identification and valuation of assets,
the assessment of threats to those assets, and assessment of vulnerabilities. The results from
these activities are then used to assess the risks and then identify risk treatment.
Consequences may be assessed in several ways, including using quantitative, e.g. monetary,
and qualitative measures (which can be based on the use of adjectives such as moderate or
severe), or a combination of both. To assess the likelihood of threat occurrence, the time frame
over which the asset will have value or needs to be protected should be established. The
likelihood of a specific threat occurring is affected by the following:
• The attractiveness of the asset, or possible impact applicable when a deliberate human threat
is being considered;
• The ease of conversion exploiting a vulnerability of the asset into reward, applicable if a
deliberate human threat is being considered;
• The technical capabilities of the threat agent, applicable to deliberate human threats; and
• The susceptibility of the vulnerability to exploitation, applicable to both technical and non-
technical vulnerabilities.
Many methods make use of tables and combine subjective and empirical measures. It is
important that the licensed entity uses a method with which they are comfortable, in which they
have confidence, and that will produce repeatable results. A few examples of table-based
techniques are given below:
Example 1- Matrix with predefined values
In risk assessment methods actual or proposed physical assets are valued in terms of
replacement or reconstruction costs (i.e., quantitative measurements).
(contd.)
These costs are then converted onto the same qualitative scale as that used for information.
Actual or proposed software assets are valued in the same way as physical assets, with
purchase or reconstruction costs identified and then converted to the same qualitative scale as
that used for information. Additionally, if any application software is found to have its own intrinsic
requirements for confidentiality or integrity (for example if source code is itself commercially
sensitive), it is valued in the same way as for information.
The values for information are obtained by interviewing selected business management (the
“data owners”) who can speak authoritatively about the data, to determine the value and
sensitivity of the data actually in use, or to be stored, processed, or accessed. The interviews
facilitate assessment of the value and sensitivity of the information in terms of the worst-case
scenarios that could be reasonably expected to happen from adverse business consequences
due to unauthorized disclosure, unauthorized modification, non-availability for varying time
periods, and destruction.
Valuation is accomplished using information valuation guidelines, which cover such issues as:
• Personal safety;
• Personal information and privacy;
• Legal and regulatory obligations;
• Law enforcement;
• Commercial and economic interests;
• Financial loss/disruption of activities;
• Public order;
• Business policy and operations;
• Loss of goodwill; and
• Contract or agreement with a customer.
The guidelines facilitate identification of the values on a numeric scale, such as the 0 to 4 scale
shown in the example matrix below, thus enabling the recognition of quantitative values where
possible and logical, and qualitative values where quantitative values are not possible, e.g. for
endangerment of human life.
The next major activity is the completion of pairs of questionnaires for each threat type, for each
grouping of assets that a threat type relates to enable the assessment of the levels of threats
(likelihood of occurrence) and levels of vulnerabilities (ease of exploitation by the threats to
cause adverse consequences). Each question answer attracts a score. These scores are
accumulated through a knowledge base and compared with ranges. This identifies threat levels
on say a high to low scale and vulnerability levels, similarly, as shown in the example matrix
below, differentiating between the types of consequences as relevant. Information to complete
the questionnaires should be gathered from interviews with appropriate personnel, physical
location inspections, and reviews of documentation.
The asset values, and the threat and vulnerability levels, relevant to each type of consequence,
are matched in a matrix such as that shown below, to identify for each combination the relevant
measure of risk on a scale of 0 to 8. The values are placed in the matrix in a structured manner.
An example is as follows :
(contd.)
Likelihood of
occurrence- Low Medium High
Threat
Ease of
L M H L M H L M H
Exploitation
0 0 1 2 1 2 3 2 3 4
1 1 2 3 2 3 4 3 4 5
Asset
2 2 3 4 3 4 5 4 5 6
Value
3 3 4 5 4 5 6 5 6 7
4 4 5 6 5 6 7 6 7 8
Table-1
For each asset, the relevant vulnerabilities and their corresponding threats are considered. If
there is a vulnerability without a corresponding threat, or a threat without corresponding
vulnerability, there is presently no risk (but care should be taken in case this situation changes).
Now the appropriate row in the matrix is identified by the asset value, and the appropriate
column is identified by the likelihood of the threat occurring and the ease of exploitation. For
example, if the asset has the value 3, the threat is “high” and the vulnerability “low”, the measure
of risk is 5. Assume an asset has a value of 2, e.g. for modification, the threat level is “low” and
the ease of exploitation is “high”, then the measure of risk is 4.
The size of the matrix, in terms of the number of threat likelihood categories, ease of exploitation
categories and the number of asset valuation categories, can be adjusted to the needs of the
licensed entity. Additional columns and rows will necessitate additional risk measures. The value
of this approach is in ranking the risks to be addressed.
A similar Matrix as shown in Table-2 results from the consideration of the likelihood of an incident
scenario, mapped against the estimated business impact. The likelihood of an incident scenario
is given by a threat exploiting a vulnerability with a certain likelihood. The Table maps this
likelihood against the business impact related to the incident scenario. The resulting risk is
measured on a scale of 0 to 8 that can be evaluated against risk acceptance criteria. This risk
scale could also be mapped to a simple overall risk rating, for example as:
• Low risk: 0-2
• Medium Risk: 3-5
• High Risk: 6-8

(contd.)
Likelihood of
Very
Incident Unlikely Possible Likely Frequent
Unlikely
Scenario
Ver Low 0 1 2 3 4
Low 1 2 3 4 5
Business
Medium 2 3 4 5 6
Impact
High 3 4 5 6 7
Very High 4 5 6 7 8
Table-2
Example 2- Ranking of Threats by Measures of Risk

A matrix or table such as that shown in Table-3 can be used to relate the factors of
consequences (asset value) and likelihood of threat occurrence (taking account of vulnerability
aspects). The first step is to evaluate the consequences (asset value) on a predefined scale,
e.g., 1 through 5, of each threatened asset (column “b” in the table). The second step is to
evaluate the likelihood of threat occurrence on a predefined scale, e.g., 1 through 5, of each
threat (column “c” in the table). The third step is to calculate the measure of risk by multiplying (b
× c). Finally, the threats can be ranked in order of their associated measure of risk. Note that in
this example, 1 is taken as the lowest consequence and the lowest likelihood of occurrence.
Likelihood of
Threat Consequence Measure of
threat Threat Ranking
Descriptor (asset) Value Risk
occurrence (e)
(a) (b) (d)
(c)
Threat A 5 2 10 2
Threat B 2 4 8 3
Threat C 3 5 15 1
Threat D 1 3 3 5
Threat E 4 1 4 4
Table-3
As shown above, this is a procedure which permits different threats with differing consequences
and likelihood of occurrence to be compared and ranked in order of priority, as shown here. In
some instances, it will be necessary to associate monetary values with the empirical scales used
here.

(contd.)
Example 3- Assessing a value for the likelihood and the possible consequences of risks
In this example, the emphasis is placed on the consequences of cybersecurity incidents (i.e.,
incident scenarios) and on determining which systems should be given priority. This is done by
assessing two values for each asset and risk, which in combination will determine the score for
each asset. When all the asset scores for the system are summed, a measure of risk to that
system is determined.
First, a value is assigned to each asset. This value relates to the potential adverse
consequences that can arise if the asset is threatened. For each applicable threat to the asset,
this asset value is assigned to the asset.
Next a likelihood value is assessed. This is assessed from a combination of the likelihood of the
threat occurring and the ease of exploitation of the vulnerability, see Table 4 expressing the
likelihood of an incident scenario.
Likelihood of Threat Low Medium High
Levels of
L M H L M H L M H
Vulnerability
Likelihood Value of an
0 1 2 1 2 3 2 3 4
incident scenario
Table-4
Next, an asset/threat score is assigned by finding the intersection of asset value and likelihood
value in Table-5. The asset/threat scores are totaled to produce an asset total score. This figure
can be used to differentiate between the assets forming part of a system.
Asset Value
Likelihood 0 1 2 3 4
Value
0 0 1 2 3 4
1 1 2 3 4 5
2 2 3 4 5 6
3 3 4 5 6 7
4 4 5 6 7 8
Table-5

(contd.)
The final step is to total all the asset total scores for the assets of the system, producing a
system score. This can be used to differentiate between systems and to determine which
system's protection should be given priority.
In the following examples all values are randomly chosen:
Suppose System S has three assets A1, A2 and A3. Also suppose there are two threats T1 and
T2 applicable to system S. Let the value of A1 be 3, similarly let the asset value of A2 be 2 and
the asset value of A3 be 4.
If for A1 and T1 the threat likelihood is low and the ease of exploitation of the vulnerability is
medium, then the likelihood value is 1 (see Table-4).
The asset/threat score A1/T1 can be derived from Table-5 as the intersection of asset value 3
and likelihood value 1, i.e., 4. Similarly, for A1/T2 let the threat likelihood is medium and the ease
of exploitation of vulnerability is high, giving an A1/T2 score of 6.
Now the total asset score A1T can be calculated, i.e., 10. The total asset score is calculated for
each asset and applicable threat. The total system score is calculated by adding A1T + A2T +
A3T to give ST.
Now different systems can be compared to establish priorities and different assets within one
system as well.

Annexure II: Change Prioritization Guide
Changes should be prioritized to establish the order in which they should be considered for
deployment. This prioritization can be done based on the urgency and impact.
The urgency rating signifies the speed at which the change has to be deployed and may be
assigned based on the following matrix:
Rating Value Examples

Immediate and sustained response involving multiple resources is
Critical 4
required /Changes required for resolving security incidents, outages etc.
High 3 Immediate action required from assigned resources only.
Moderate urgency, the change can be scheduled for deployment at a
Medium 2
later date based on earliest available slot
No urgency; the change can be scheduled for deployment at a later
Low 1
date
The impact of a change describes the effect that a change may have on the IT/ OT infrastructure
or the impact on the business, not performing the change may have on the licensed entity. The
impact rating of change may be assigned based on the following matrix:
Rating Value Examples
• Critical business impact
Critical 4 • Change will impact significant parts of the IT/ OT operations
• Majority of users would be impacted
• Major operational impact
High 3
• Multiple users would be impacted.
• Minor operational impact
Medium 2 • Only noncritical business operations affected
• Limited users would be impacted
• No or Minor Impact on operations.
Low 1
• No significant impact on users
The overall change priority is derived from the ‘Impact’ and ‘Urgency’ ratings.
Priority = Urgency X Impact
Impact Critical High Medium Low
Urgency 4 3 2 1
Critical 4 Critical (16) Critical (12) High (8) Medium (4)
High 3 Critical (12) High (9) Medium (6) Low (3)
Medium 2 High (8) Medium (6) Medium (4) Low (2)
Low 1 Medium (4) Low (3) Low (2) Low (1)

Annexure III: Personal Data Protection Goals
The escalation of security breaches involving personal data has contributed to the loss of
millions of records. Breaches involving personal data can impact both individuals, by contributing
to identity theft, blackmail, or embarrassment, and the licensed entity, by reducing public trust in
the licensed entity or through legal liabilities. Hence, appropriate and adequate security
measures should be implemented to protect personal data from unauthorized access, use, or
disclosure. The goals of security measures implemented to safeguard personal data should be :
i. Confidentiality: Confidentiality of personal data should be ensured by preventing
unauthorized access;
ii. Integrity: Personal data should be protected from unauthorized and improper modification to
ensure data accuracy and integrity;
iii. Availability: Personal data should be available to only authorized personnel when required.
Upon the expiration of identified lawful business purposes or withdrawal of consent, personal
data should either be securely erased or anonymized;
iv. Unlinkability: Personal data should be operated in such a way that it is unlinkable to any
other privacy-relevant data outside of the domain for which it is collected for. Unlinkability
can be ensured by anonymization, pseudonymization, or erasure;
v. Transparency: All parties involved in any personal data processing should comprehend the
legal, technical, and organizational factors to setup the scope for this processing, before;
during and after the processing takes place; and
vi. Intervenability: All parties involved in personal data processing, including the individual
whose personal data is processed, have the possibility to intervene, where necessary. The
objective should be to offer corrective measures and counterbalances in the processes.
Availability,
Resilience 3 4 Unlinkability
Integrity 2 5 Transparency
Confidentiality 1 6 Intervenability
Personal Data
Protection Goals

Annexure IV: Fair Information Practices
It is important to have clear strategies regarding how the personal data would be collected, used,
transferred, and stored. This can be achieved by applying fair information practice principles
while handling personal data. Following fair information practice principles should be considered
that can help make right decisions while handling personal data:
i. Collection Limitation Principle: The licensed entity should identify the personal data that are
required for business purpose and collect only the required data with consent of the data
subject;
ii. Data Quality Principle: Required personal data should be accurate, complete, and updated
regularly;
iii. Purpose Specification Principle: The purposes for which personal data are collected should
be specified at the time of data collection and use of data should be limited to the fulfilment
of those specified purposes only;
iv. Use Limitation Principle: Personal data should not be disclosed, or otherwise used for
purposes other than those specified with the consent of the data subject;
v. Security Safeguards Principle: Personal data should be protected against loss or
unauthorized access, destruction, misuse, modification or disclosure;
vi. Openness Principle: The licensed entity should provide information about processes,
practices and policies with respect to personal data;
vii. Individual Participation Principle: An individual should be able to challenge the accuracy and
completeness of the information and, have the data erased, rectified, completed, or
amended if the challenge is successful; and
viii. Accountability Principle: The licensed entity is responsible for personal information under its
control and should designate personnel who are accountable for the compliance with the
principles stated above.
Collection
Data Quality
Limitation
Purpose
Accountability
Specification
Fair Information
Practices
Individual
Use Limitation
Participation
Security
Openness
Safeguards

Annexure V: Privacy by Design Principles
Appropriate security measure should be implemented to protect personal data. Security
measures implemented should ensure that the following goals are being met:
i. Proactive not reactive, preventative not remedial: Anticipate and prevent privacy invasive
events before they happen. The aim should be to prevent them from occurring;
ii. Privacy by default: Deliver the maximum degree of privacy by ensuring that personal data
are automatically protected in any given system or business process;
iii. Embed privacy into design: Privacy measures should be embedded within the IT systems
and business processes and not included as add-ons;
iv. Full functionality- Positive sum, not Zero sum: It proposes a positive sum "win-win" wherein
the licensed entity have privacy, revenue, and growth, but without sacrificing one for the
other;
v. End-to-end security- Full lifecycle protection: All data should be securely retained as needed
and destroyed when no longer needed;
vi. Visibility and Transparency- Keep it Open: Assure all stakeholders that business processes
or technology involved, are operating according to the stated promises and objectives, and
subjected to independent verification; and
vii. Respect for user privacy- Keep it user centric: Keep the interests of the individual uppermost
by offering measures such as strong privacy defaults, appropriate notices, and empowering
user-friendly options.
Proactive, not
reactive 1 7 User centric
Privacy as Privacy by Visibility and

default setting 2 Design 6 transparency
Principles
Privacy embedded
into design 3 5 End-to-end security
Full functionality

Annexure VI: Personal Data Security Measures
The licensed entity should implement appropriate security controls to protect personal data in
accordance with applicable laws and regulations. Below are the key aspects for consideration:
i. Governance: The licensed entity should appoint a Data Protection Officer (DPO). DPO
should have the following responsibilities:
• Advise top management and process owners regarding their obligations and legislative
requirements;
• Monitor compliance with applicable laws and regulations, including assignment of roles
and responsibilities, increasing awareness, and staff training;
• Provide advice related to data protection impact assessment and performance monitoring;
• Maintaining records of all data processing activities conducted by the licensed entity;
• Responding to data subjects to inform them about how their personal data is being used
and what measures the company has put in place to protect their data; and
• Act as the contact point for issues relating to personal data protection.
ii. Data Collection: Following recommendations should be considered while collecting personal
data:
• The licensed entity should identify the personal data that is required for business purpose
and collect only the required data;
• DPO should regularly review and approve personal data collected and methods used to
collect data;
• Choices should be available to data subjects whether to provide data or not; and
• In case of collection of privacy data is outsourced, then there should be legal agreement
with the third party to comply with the licensed entity’s personal data protection policy
during collection, use and transfer of personal information on behalf of the licensed entity.
iii. Privacy Notice: Following information should be included in the notice while collecting data:
• Purposes for which personal information is collected, used, and disclosed;
• Period for which personal information should be retained as per identified business
purpose or as mandated by regulations;
• Process for an individual to withdraw consent for the collection, use, and disclosure of
their personal information for identified purposes;
• Choices available to the individual regarding collection, use and disclosure of personal
information, wherever applicable;
• Consequences of withholding or withdrawing consent to the collection, use and disclosure
of personal information for identified purposes;
• Methods employed for collection of personal information, including ‘cookies’ and other
tracking techniques, and third party agencies;

Annexure VI: Personal Data Security Measures (contd.)
• That an individual’s personal information should be disclosed to third parties only for
identified lawful business purposes and with the consent of the individual, wherever
possible;
• Data subjects are responsible for providing the licensed entity with accurate and
complete personal information, and for contacting the licensed entity if correction of such
information is required;
• Process for an individual to view and update their personal information records; and
• Process for an individual to register a complaint or grievance with regard to privacy
practices at the licensed entity.
iv. Consent: Implicit or explicit consent should be obtained during following conditions:
• Explicit consent should be obtained from data subjects for the collection, use, and
disclosure of sensitive personal information, unless a law or regulation specifically
requires or allows otherwise;
• A record is maintained of explicit consent obtained from data subjects;
• Implicit consent should be considered adequate for the collection, use and disclosure of
personal information which does not qualify as sensitive personal information;
• Consent should be obtained from data subjects before their personal information is used
for purposes not previously identified; and
• Appropriate consent should be obtained from data subjects before their personal
information is transferred to or from their information processing systems.
v. Use and Retention: Following recommendation may be considered for use and retention of
privacy data:
• DPO should regularly review and approve the process of use of personal data;
• In case privacy data processing is outsourced to third party then regular audits should be
conducted on third parties processing personal data;
• Guidelines and procedures should be developed for the retention and disposal of
personal data. These should address minimum and maximum retention periods, and
modes of storage; and
• Upon the expiration of identified lawful business purposes or withdrawal of consent, the
licensed entity should either securely erase or anonymize the data subjects’ personal
information; and
• The licensed entity should take consent from relevant regulatory authorities before
transferring personal outside United Arab Emirates.
vi. Data Subject Rights: The licensed entity should have a process to mange following data
subjects rights:
• Right to information: The licensed entity should establish processes that allow data
subject to raise request about what personal data is being processed and the rationale
for such processing. The said processes should include replying to such right to
information requests in a timely manner;

• Right to access: The licensed entity should provide facilities that allow data subject to
view their own personal data and request a copy of the same;
• Right to rectification: The licensed entity should provide means that allow data subjects
to ask for modifications to their personal data;
• Right to withdraw consent: The licensed should have facilities that allow data subjects to
withdraw a previously given consent for processing of their personal data for a purpose.
The request would then require the licensed entity to stop the processing of the personal
data that was based on the consent provided earlier;
• Right to object: The licensed entity should have process that allows data subjects to
raise complain regarding use of their personal data. The licensed entity should ensure
that such complains are addressed in a timely manner; and
• Right to be forgotten: The licensed entity should have process that allow data subject to
ask for deletion of their data.
vii. Data Protection Impact Assessment: Data Protection Impact Assessments should be
performed for personal data processing activities. Decision to perform DPIA should be
based on following criteria:
• Evaluation or scoring: The licensed entity should conduct DPIA when profiling people,
especially their performance at work, economic situation, health, personal preferences,
or interests, behavior, location, or movement. Examples include comparing credit scores,
genetic testing to assess health risks, and behavioral-based marketing profiling;
• Automated decision-making: A DPIA is required when the licensed entity enacts
processes that automate legal decision-making. The licensed entity should ensure that
such processing doesn’t lead to exclusion of or discrimination against an individual;
• Systematic monitoring: The licensed entity should conduct DPIA when observing,
monitoring or controlling data subjects — including when they are in public areas.
Examples include remote monitoring, such as controlling appliance using home
automation;
• Sensitive data handling: A DPIA is required any time the licensed entity deals with
sensitive personal data, such as health data;
• Large-scale data processing: A DPIA is required when the licensed entity carries out
large-scale personal data processing. Criteria for determining whether data processing
occurs on a large scale includes the number of data subjects, duration and geographical
extent of the activity;
• Matching or combining datasets: When the licensed entity merges or compares two or
more sets of data collected for different purposes, it must conduct a DPIA;
• Innovative use: New technology solutions such as fingerprint and facial recognition may
be considered innovative uses of data. Internet of things (IoT) devices are another
common technology affected by DPIA requirements; and

• The transfer of data outside the licensed entity environment: If the licensed entity
outsources any process related to personal data, it needs to conduct a DPIA and ensure
that appropriate safeguards are in place.
viii. Security Controls: Based on DPIA, the licensed entity should implement appropriate security
controls to mitigate the risks involved. Following security controls should be considered (but
not limited to):
• The licensed entity’s information assets should be classified according to the data
classification process/procedure and indicate whether or not the information asset
contains personal data;
• Access to personal data is granted in line with the person’s job responsibilities and
based on principles of need to know and least privileges;
• Accesses to personal data are reviewed regularly;
• Implementing a Data Loss Prevention solution to protect the personal data at rest, in use
and while it is in transit.
• Pseudonymization of data where feasible.
ix. The licensed entity should ensure security of personal data shared with third parties by:
• Having signed agreements to protect personal data consistent with the licensed entity
Personal Data Protection policy;
• Having signed non-disclosure agreements or confidentiality agreements which includes
personal data protection clauses; and
• Right to audit third party processes related to collecting, storing or processing personal
data.
x. Incident Response for Breaches Involving Personal Data: Handling incidents and breaches
involving personal is different from regular incident handling and may require additional
actions by the licensed entity, in line with the applicable regulatory requirements. Such
breaches can receive considerable media attention, which can greatly harm the licensed
entity‘s reputation and reduce the public‘s trust in the licensed entity. Moreover, affected
individuals can be subject to identity theft etc. as the result of a breach involving personal
data. The licensed entity should develop process to determine when and how individuals
impacted by the breach should be notified, when and if a breach should be reported publicly,
and whether to provide remedial services to affected individuals. The licensed entity should
integrate these additional processes into their existing incident handling response plan.
Following additional details related to personal data breach incident management may be
considered in the phases of incident response plan:
• Preparation: Licensed entities should integrate the response plans for personal data
breaches into their existing incident response plans. The plan should provide guidance
regarding how to detect and report breaches related to personal data. The incident
response plans should be communicated to all staff through training and awareness
programs. Training may include tabletop exercises to simulate an incident and test
whether the response plan is effective and whether the staff members understand and
are able to perform their roles effectively. Training programs should also inform
employees of the consequences of their actions for inappropriate use and handling of
personal data;
• Detection and Analysis: The licensed entity may continue to use their current detection
and analysis technologies and techniques for handling incidents involving personal data.
However, adjustments to incident handling processes may be necessary, such as
ensuring that the analysis process includes an evaluation of whether an incident involves
personal data. Detection and analysis should focus on both known and suspected
breaches involving personal data. Detection of an incident involving personal data also
requires reporting internal and external stakeholder, as appropriate;
• Containment, Eradication, and Recovery: Existing technologies and techniques for
containment, eradication, and recovery may be used for breaches involving personal
data. However, changes to incident handling processes may be necessary, such as
performing additional media sanitization steps when personal data needs to be deleted
from media during recovery. Additionally, it is important to determine whether personal
data was accessed and how many records or individuals were affected; and
• Post-Incident Activity: As with other security incidents, lessons learnt through detection,
analysis, containment, and recovery should be collected for sharing within the licensed
entity and with third-party as appropriate, to help protect against future incidents. The
incident response plan should be continually updated and improved based on the
lessons learnt during each incident.

Annexure VII: Social Media Policy
The licensed entity should establish a social media policy that employees need to adhere to,
while using social media on behalf of the licensed entity as well as while using their personal
social media accounts and (when referencing the licensed entity). The policy should include
blogs, wikis, microblogs, message boards, chat rooms, electronic newsletters, online forums,
social networking sites (Linkedin, Twitter etc.), and other sites and services that permit users to
share information on public platforms.
Following are the set of recommendations that may be included in the licensed entity’ social
media policy:
i. Employees should be aware of the effect their actions may have on the licensed entity’s
reputation;
ii. Employees should be aware that the licensed entity may observe the social media content
related to it;
iii. Employees should use their judgment while posting material to ensure that it is neither
inappropriate nor harmful to the licensed entity, its employees, or customers;
iv. Although not an exclusive list, some specific examples of prohibited social media conduct
include posting commentary, content, or images that are defamatory, proprietary, harassing,
libelous, or that can create a hostile work environment;
v. Employees are not to publish and/or post or release any information that is considered
confidential or not public. If there are questions about what is considered confidential,
employees should check with the concerned stakeholders like Cybersecurity Department;
vi. Social media networks, blogs and other types of online content sometimes generate press
and media attention or legal questions. Employees should refer these inquiries to authorized
the licensed entity spokespersons;
vii.Employees should disengage from the dialogue in a polite manner and seek the advice of
concerned stakeholders if they encounter a situation while using social media that might
become antagonistic;
viii.Employees should get appropriate permission and approvals before referring to or post
images of current or former employees, members, vendors, or suppliers. Additionally,
employees should get appropriate permissions to use a third party's copyrights, copyrighted
material, trademarks, service marks or other intellectual property; and
ix. If employees publish content that involves work or subjects associated with the licensed entity,
a disclaimer should be used, such as : “The postings on this site are my own and do not
represent the licensed entity’s position or opinion”.

Annexure VIII: Social Media Security Controls
Social media is an important avenue for the licensed entities to engage with their customers. But
compromise of official social media accounts can have serious implications. From social
engineering to sophisticated profile hijacking, social media accounts face many potential attacks.
Thus it’s vital for the licensed entity to implement appropriate security controls to secure their
social media accounts. Following security controls may be considered:
i. Asset Management:
The licensed entity's social media accounts and devices used to manage social media
accounts should be identified and inventoried;
ii. Identity and Access Management:
• The licensed entity’s social media accounts should be created separately, separate from
individual accounts;
• The “corporate account” feature should be used if the social media platform provides it. As
offered by various social media platforms, a corporate account allows an administrator to
assign roles and access privileges to individual user accounts. This feature enhances
security by:
o Limiting the users that possess administrative control; and
o Ensuring that each user retains their own unique credentials for accessing the service.
• Roles and responsibilities for operating and securing social media should be assigned to
relevant individuals or group;
• Strong password should be selected as per the licensed entity’s password policy. Use of
multi factor authentication should be considered for the licensed entity’s social media
account login; and
• Third-party app access to the licensed entity’s social media account should be limited.
This control should be ensured by the licensed entity as well as by individuals that interact
or administer social media accounts.
iii. Social Media Application Security:
• Social Media Mobile apps should be regularly updated;
• Application configuration such as default password, pre-login, lockout, etc. should be
secure;
• Activation of inbuilt features and services in social media accounts should be restricted
based on need, unnecessary features/ services should be deactivated; and
• The default security features provided by social media apps should be utilized.
iv. Logging and Monitoring:
• Notifications and security alerts related to social media accounts should be activated and
monitored;
• Social media network should be monitored regularly to ensure the licensed entity’s
account is not impersonated;

Annexure VIII: Social Media Security Controls (contd.)
• Social media network should be monitored to ensure no rumors or misinformation is
spread in reference to the licensed entity; and
• Social media account should be monitored for any change in the account’s pattern,
indicators of compromise, or the publication of any unauthorized content.
v. Social Media Account Protection:
• Official social media account should be communicated using all relevant platform like the
licensed entity’s website, reports, bills, documents, advertisement, etc. to ensure correct
social media account is followed by customers and other relevant parties;
• The licensed entity should coordinate with social media company to block the fake
accounts that impersonate the licensed entity social media account;
• The licensed entity should coordinate with social media company to block any malicious
content or inappropriate message referring to entity, that is not authorized by entity; and
• If the licensed entity’s social media account is compromised, the licensed entity should
immediately report to the social media company to disable the account and should
communicate to their customers and other relevant stakeholders through various other
platforms.

Annexure IX: Cybersecurity Workforce Development
The licensed entity should develop a formal skill development/ staff training program, wherein the
UAE nationals are trained in a systematic manner and are provided adequate skillset to manage
the cybersecurity aspects of the critical infrastructure.
This should be a gradual and ongoing activity, and the licensed entity may refer to the below
guidelines while developing the training program:
i. Determine the job roles/ profiles based on the licensed entity’s organizational hierarchy and
structure of the cybersecurity function, that should be staffed with UAE nationals (e.g., OT
Security Manager, OT Security Analyst, OT GRC Lead etc.);
ii. Identify the necessary competencies (experience, knowledge, certifications, degree etc.) that
the personnel would require to efficiently execute the responsibilities associated with their role/
job profile;
iii. Determine the approach for staffing these roles/ positions (in house personnel to be developed,
cross training, hiring from outside, hybrid approach etc.) in coordination with the concerned
stakeholders like the HR department, training department etc.;
iv. Based on the specific approach to be adopted, identify competency gaps and training
requirements for the personnel identified;
v. Prepare a formal training program and provide the planned trainings as required, based on the
competency gap assessment;
vi. Periodically evaluate the effectiveness of the trainings provided; and
vii. Maintain records of training.
These job roles/ profiles may be categorized on career levels and the licensed entity may refer to
these (in conjunction with the inputs from the training/ HR department etc.) to determine the
support required for each career level:
i. Entry-Level Cybersecurity Professional:
• Profile:
o College graduate or postgraduate, and career changers; new to Cybersecurity;
o Focused on learning fundamentals; and
o Acclimatizing to organizational environment, establishing support network, and gaining
work experience.
• Support:
o Encourage two-way dialogue for open communication;
o Provide frequent feedback on job performance;
o Provide quality supervision and mentorship;
o Provide opportunities to acquire new skills through established training program,
challenging job assignments, attending seminars etc.; and
o Recognize staff for strong work performance.

Annexure IX: Cybersecurity Workforce Development
(contd.)
ii. Mid-Career Cybersecurity Professional:
• Profile:
o Professionals with previous Cybersecurity experience and skills; and
o Focused on shaping career path and advancing technical skillset through experience,
job rotations, certifications, and supervisory opportunities.
• Support:
o Provide opportunities to obtain advanced training and certifications;
o Offer challenging job assignments;
o Include employees in decision making and innovation; and
o Implement reward program.
iii. Seasoned or Executive Cybersecurity Professional:
• Profile:
o Demonstrated cyber expertise and progressive leadership experience; and
o Focused on expanding technical expertise, making contributions to technical domain
and broader Cybersecurity community, and leadership development.
• Support:
o Provide advanced training and development opportunities;
o Create tailored development plans that identify leadership competencies and areas for
development;
o Recognize leaders for their successes and accomplishments; and
o Promote cyber executives to develop intellectual capital and create information sharing
mechanisms.
The licensed entity may also consider developing cybersecurity workforce in collaboration with
academic institutions:
i. Work together with universities to mentor students and develop cybersecurity professionals;
ii. Include cybersecurity in universities curriculum by adding subjects related to critical
infrastructure cybersecurity;
iii. Arranging guest lectures/ seminars at universities by critical infrastructure cybersecurity
experts; and
iv. Providing internship opportunities.

Annexure X: ICS/ OT Systems Password Management
ICS/ OT systems passwords (for systems like Operating Systems, SCADA Applications,
Historian Databases, and ICS/ OT network equipment) should be configured with “Strong”
passwords. Wherever the requirements of sub controls control IAM-3-3 (Password Management)
cannot be implemented due to technical limitations or other operational constraints, the
exemption request for the same should be presented to Cybersecurity Steering Committee (or
other relevant authority) for approval.
In ICS/ OT environments there might be scenarios where passwords of critical systems might
need to be written for security reasons. If writing of passwords is unavoidable and is supported
by operational needs, the entities can adopt (and tailor) below password management guidelines
specific to ICS/ OT environments, as applicable and deemed necessary.
Storage and Management of Critical Passwords
Below listed table illustrates few examples of passwords that can be deemed to be critical from
an operational perspective. These passwords need to be securely managed to ensure that they
are not forgotten or are not lost.
System Types of Passwords

ICS/ OT Systems Operator ID Unique Password
Workstation Operating Systems Administrator Passwords
ICS/ OT/ SCADA Applications • Super User Password (where applicable)
• Administrator Password
• System Password (for database connectivity - where
applicable)
Historian Data base Historian Database Super User Password
Network equipment/ devices • Device Super User Password
• Administrator Password
The below password management guidelines may be referred and customized based on the
licensed entity’s requirements:
i. Storage of Critical Passwords
• OT Security team should ensure that the written copy of critical passwords is kept in a
sealed tamper proof envelope; and
• Content of the Password Envelopes: The following information should be documented on
the face of the envelope:
o Name / Identity of the Plant operating application, ICS/ OT system Operating System,
or Historian Database etc. for which the password has been recorded; and
o Name of user and his/ her department, designation, and username who is owner of
the password.

Annexure X: ICS/ OT Systems Password Management
(contd.)
ii. Sealing of the Password Envelope
• The password envelope should be sealed and signed across all openings – to ensure that
any attempt to open the envelope can be detected.
iii. Storage of the Password Envelope
• The password of the critical user IDs/system IDs should be kept in a sealed envelope in a
fireproof safe in the custody of the appropriate authority and log should be maintained for
this purpose, noting the date and time of the lodging of the password and the identity of
the person lodging the password; and
• The authority that has the custody of the password is only custodian of the passwords and
is not authorized to open or otherwise tamper with the password envelopes.
iv. Release of Passwords in Safe Custody
• The custodian of the stored passwords should only release the password to the following
persons under the following circumstances:
Password released to Circumstance / Reason Authorization Requirement

Password Owner On request where:- Appropriate authority as per
the licensed entity’s
(As mentioned on the • Password requires to be changed
organization structure (e.g.,
Password envelope) / replaced
General Manager,
• Owner has forgotten the Department Manager etc.)
password
OT Security Team The owner of the password has Appropriate authority as per
become unavailable to the company. the licensed entity’s
(or other relevant
organization structure (e.g.,
authority as per the (E.g., Termination of service,
General Manager,
entity’s organization resignation, illness etc.)
Department Manager etc.)
structure)
• The custodian of stored passwords should release the password only on formal written
request of the parties mentioned above on completion of the following steps:
o Release of a password should be noted in the log maintained by custodian; and
o Once opened, password is to be considered ‘compromised’ and should be changed.
v. Periodic Monitoring of the Password Envelopes
• The relevant stakeholders as per the licensed entity’s organization structure, should monitor
the password envelopes from time to time and ensure that: all password envelopes are
accounted for. (In comparison to the password envelopes registered in the password log)
and ensure envelopes have not been tampered with.
• If the OT Security team detects that password envelopes are missing or have been
tampered with, then he should immediately instruct all relevant users to change their
passwords with immediate effect.

Annexure XI: Network Segmentation
Network segmentation is an important security countermeasure, employed in conjunction with
other layers of defense to reduce the risks associated with ICS/ OT systems. Network
segmentation involves segmenting key ICS/ OT assets into zones with common security levels
in order to manage security risks.
Some ICS/ OT systems are connected to and integrated with business systems. Exposing the
ICS/ OT devices to this traffic increases the likelihood of a security incidents. ICS/ OT systems
should be architected in a manner that filters unnecessary communication packets from reaching
the ICS/ OT systems. This is achieved by compartmentalizing devices into common security
zones. Compartmentalizing devices into zones does not necessarily mean isolating them,
conduits may connect different security zones and facilitate the transport of necessary
communications between the segmented security zones.
Network segments and zones
Purdue Reference Model provides a model for integrating devices and applications at key layers
of the enterprise network and process infrastructure. It shows the interconnections of all the main
components of a typical enterprise architecture, dividing the architecture into two main zones –
Business/enterprise zone and Control zone. These zones are further subdivided into following
six (06) levels:
• Level 4 – Enterprise: This is IT network where the primary business functions run. It includes
systems like Enterprise Resource Planning software, databases, email servers and other
systems to manage business processes and communications;
• Level 3.5 – Demilitarized zone: This is where the IT systems and ICS/ OT systems converge.
The DMZ creates a barrier between the IT and ICS/ OT networks;
• Level 3 – Plant operations systems: This is where the production workflow is managed. It
includes systems like batch management, manufacturing execution systems, manufacturing
operations management systems, and data historians;
• Level 2 – Control systems: This is where the overall processes are controlled within the
system. It includes systems like human-machine interfaces, supervisory control and data
acquisition, Distributed Control Systems etc.;
• Level 1 – Intelligent devices: It includes systems that monitor and send commands to the
devices at Level 0. Examples include PLC, RTU, IED, Gateway etc.; and
• Level 0 – Process I/O devices: It includes physical components like motors, pumps, sensors,
valves, analyzers, actuators etc.
The control zone may be further divided into different zones based on operational and security
requirements. Following are zones that may be created within the control zone:
• Safety system zone: A safety instrument system may require a different set of security
practices from the ones employed in the remaining control zone. The target security level for
this zone should be determined and appropriate actions taken to ensure appropriate
countermeasures are employed to meet the target security level; and
• Isolated ICS/ OT systems: High risk ICS/ OT systems managing critical operations should be
disconnected from other ICS/ OT systems (i.e. they should be isolated) to reduce the
likelihood of these systems being compromised by external agents.

Annexure XI: Network Segmentation (contd.)
Business/enterprise zone Business/enterprise zone
Business Corporate
Level 4
Enterprise resource Office Corporate patch
domain planning work- anti-virus management
Enterprise systems controller system stations server server
(business planning and logistics
Site
Site Resource Manufacturing
Router Domain Application Office
controller Server Workstations
Level 3.5 DMZ

Patch
management
Demilitarized zone Application Support server for PCN
server workstation and DMZ devices
Plant Operation
Domain Controller Management Systems Data Historian
Level 3 Plant operations systems
SCADA System DCS System HMI
Level 2 Control systems
Gateway
Safety System Zone
Intelligent Devices
Controller-1 Controller-2 Controller-3
Level 1
Safety Instrumented Systems
Level 0 Process I/O devices

Field IO Field IO Field IO
Devices Devices Devices
Control Zone Control Zone

Annexure XII: Wireless Communication Cybersecurity
Considerations for ICS/ OT Environment
With advent of new technologies like advance metering, self-healing grid, distributed energy
resources, and IoT, the adoption of wireless communications (like microwave, packet radio -
UHF/VHF, 802.11x, Cellular (3G, 4G, or 5G) and Bluetooth Radio Frequency) is set to increase.
Wireless communication brings business benefits and operational convenience but it also
introduces additional security risks. Thus it is necessary for the licensed entity to identify risks
associated with the wireless communication and the implement appropriate counter measures to
address them.
Wireless Communication Cybersecurity Requirements
The following are key considerations that describe the broad security requirements of wireless
communication networks, these act as guiding principles to determine the security control
requirements:
• Confidentiality: Data transferred using wireless networks can contain sensitive data. Hence
confidentiality of data transmitted through wireless network should be protected from
unauthorized disclosure;
• Integrity: The integrity of data transmitted through wireless networks can be compromised by
data injection attacks, message replays or message delays. Hence integrity of the data should
be protected from unauthorized alterations;
• Availability: Wireless network maybe crucial for the efficiency, sustainability, and reliability of
certain systems, thus availability of the network should be ensured in such cases;
• Authentication: Data and device authentication is essential to prevent the illegitimate nodes to
gain access to the wireless communication network; and
• Non-repudiation: Non-repudiation is an important requirement for accountability of operations
performed.
Wireless Communication Security Constraints
While determining the security requirements of wireless networks, the following constraints and
challenges associated with wireless networks should be taken into account:
• The gateways and smart devices are susceptible to threats owing to their physical location;
• Wireless communication comprise of a variety of network devices, each having its unique
features, communication mechanisms and limitations;
• The entities in wireless communications are a blend of devices from numerous product/
device and network service providers. Modelling a standardized security framework requires
agreements with different vendors; and
• The devices in wireless communication systems have their own capability limitations in terms
of storage, processing, bandwidth, and throughput. The security solutions for the wireless
communication need to ensure lower cryptographic overheads to reduce the computation
cost. Thus, the verification methodologies should be light weight and their computation must
be affordable to the traffic density.

Annexure XII: Wireless Communication Cybersecurity
Considerations for ICS/ OT Environment (contd.)
Countermeasures
Following are potential countermeasures to deal with the wireless security threats and attacks:
• Key Management: The key management system for wireless communication should address
the scalability issue of large-scale communication network. It should also ensure flexibility to
support hybrid transmission modes including unicast, multicast, and broadcast with proper
key management operations such as key generation, key refresh, key recovery etc. and also
considering the capability of wireless devices;
• Secure Routing Protocols: The attacks on routing protocols may disrupt the complete logical
connectivity. The security protocols must be designed considering the requirements of
different modules of wireless communication network such as Local Area Network, Field Area
Network, and Wide Area Network serving numerous applications;
• Secure Data Aggregation: The data aggregation presents one possible solution to address the
constraints of low processing and storage capability of wireless devices and low bandwidth
capacity of wireless networks. It takes the advantage of small sized packets traversing from
wireless device nodes to the control center via tree network topology. Aggregation can be
performed using a number of potential techniques such as concatenating several packets
under a common header or applying an aggregation function like sum, average etc. Hence it
reduces the transmission overheads by eliminating the identical header information. While
carrying out secure data aggregation, the protection for confidentiality of aggregated packets
must be taken into account as they contain a large volume of sensitive information; and
• Secure Network Architecture: For the successful adoption of wireless communication, secure
and reliable communication architecture plays the most crucial role. Moreover, the wireless
network for energy sector, involves the transmission of real-time power related information for
the management of complex power systems which requires on-time and accurate message
delivery. A secure network architecture design must emphasize on providing reliable end-to-
end communication, strong network topology, secure forwarding, and Denial of Service (DoS)
and jamming defense to alleviate attacks and attain high availability.

Annexure XIII: Statement of Applicability Template
Owing to the diverse licensee landscape, with different operating environments like power and/or
water generation, transmission, distribution, and sewerage, it is a possible that some sub
controls mentioned in the seventeen (17) risk-based domains may not be applicable to some
entities.
The licensed entity shall document the Statement of Applicability providing the justification for
implementation and exclusion of sub controls mentioned in the Department of Energy
Cybersecurity Framework. The justification for sub control exclusion is required to be supported
by formal approval from senior management.
The following template should be used by the entities to document the Statement of Applicability:
Justification for Comments

Sr. Applicable/
Domain Control Sub control Sub control Description Applicability/ Non-
No. Not-Applicable (if any)
Applicability
Multiple
business
Personal data protection
Personal processes
policy shall be documented,
Data involve storage
established, and reviewed
1 DPP DPP-1 Protection Applicable and processing
periodically, in accordance
Policy of personal
with applicable laws and
(DPP-1-1) data related to
regulations.
customers and
employee
Cloud Security policy shall
be documented,
established, and
There is no
periodically reviewed that
Cloud adoption of any
enforce guidelines to be
Security Not- cloud
2 CS CS-1 followed while adopting and
Policy Applicable technologies/
integrating cloud solution to
(CS-1-1) services in our
ensure its consistency with
environment.
the licensed entity’s
acceptable levels of
cybersecurity risks.
Hosting of There is no
The licensed entity shall
Data in adoption of any
ensure that cloud service
Cloud Not- cloud
3 CS CS-1 provider host their data
Computin Applicable technologies/
inside the boundary of
g services in our
United Arab Emirates.
(CS-1-2) environment.
Agreemen
There is no
t with All relevant legal and
adoption of any
Cloud cybersecurity requirements
Not- cloud
4 CS CS-1 Service shall be established and
Applicable technologies/
Provider agreed with cloud service
services in our
(CS-1-3) provider.
environment.

Annexure XIV: Cybersecurity Incident Handling Process
System Alert Engaging External

Response +
Recovery
Vendor Alert
Resources
Information/ First Response

Operations Security Team Alerted IRT Support
Vendors+ Service
Threat Alert Providers
Detection
(Endpoint Protection, Initial

Firewall, etc.) Investigation
Industry Resources
Energy Sector
Employee Report
Community
Incident
• Track and assess threat and No Confirmed? Yes
vulnerability information
• Report cyber threats and suspicious Law Enforcement
activity alerts to First Response Team
• Declare a cyber incident and notify Actions Logged Notify Core CIRT
Core CIRT. Government
Resources
• Classify incident, define CIRT
composition and activate full CIRT
DOE
Event Resolved Activate Full CIRT
• Identify initial actions to prevent Regulatory

further damage Initial Containment
Reporting/
• Document the incident from start to Actions
Notification
Containment
finish using approved handling forms

• Follow procedures for forensic Investigation Abu Dhabi,
investigation, system imaging, and +
evidence gathering
Department of Energy
Documentation
• Conduct mandated reporting and
notification within required Other regulatory
thresholds and timelines Required Reporting bodies
+
Notification
Insurance Provider
• Assess resource needs and Eradication Plan

Internal & External
Eradication
available expertise to remove the Development

threat + Communications
Resource Needs Efforts
• Develop response procedures and
assign responsibilities Assessment
• Engage industry response partners

to validate the incident and support Incident Eradication Customers
mitigation when needed
Employees
Restore and Verify
• Restore the system to full operation Recovery Media
• Verify that mitigations were effective
Recovery
and threat is removed Community

• Identify needed improvements to Post Incident Review
plans, procedures, and resources
• Update the plan with lessons learned Update Incident
Response
Plan and Training

Annexure XV: Cybersecurity Incident Response Team
Roles
CIRT Member Roles
Investigate and analyse cyber incidents; and identify and conduct actions necessary to
contain, eradicate, and recover from an incident under direction of the Cyber Incident
Response Manger. Required capabilities include:
• Network : Technical understanding of the utility’s network to analyse, block, or restrict data
IT Technical flow in and out of network;
Response Team • System Administration: Analyse compromised workstations and servers;
• Forensic Investigation: Gather and analyse incident-related evidence in a legally acceptable
manner; conduct root cause analysis; and;
• Applications/Database Administration: Understanding of the normal/baseline operation of
enterprise applications to analyse abnormal behaviour.
Coordinate with IT Technical Response Team and operations staff during cyber incident that
could affect operations.
OT Technical
Assess and communicate potential impacts of a cyber incident on control systems.
Response Team
Communicate impacts to the Cyber Incident Response Manager.
Requires a working knowledge of the entity’s critical operations systems.
Ensure staff resources to enable 24/7 response operations as directed by the Cyber Incident
Response Manager.
Human
Assist with managing any internal communications with employees relating to the cyber
Resources
incident.
Assist in taking disciplinary action against offenders.
Obtain briefing about the nature of incident, extent of damage/ impact, mitigation measures
undertaken, further plan of action other relevant information from Cyber Incident Response
Manager.
Provide input into overall incident response and communications strategy from legal and
Legal regulatory standpoint.
Review the cyber incident communication messages and statements prepared by the CIRT
members and provide advice from legal, regulatory and compliance perspective. This will
include; but not limited to press releases, response to media queries, replying/ reporting to
regulator’s queries etc.
Finance Support with procurement of services and tools as required during incident response efforts.
Obtain the briefing about the nature of incident, extent of damage/ impact, mitigation measures
Manager.
Providing input into internal communications strategy based on likely concerns raised by
Internal internal stakeholders. Share periodic updates of developments.
Communications
Identify appropriate channels/ mechanisms for sharing the communications like email, intranet
postings, notices etc. and initiate formal communication to all internal stakeholders.
Get feedback from the stakeholders on the communications shared and adjust messages if
required. Prepare FAQs and publish them through intranet, emails etc.

Annexure XV: Cybersecurity Incident Response Team
Roles (contd.)
CIRT Member Roles
Obtain the briefing about the nature of incident, extent of damage/ impact, mitigation measures
Manager.
Communications with regulators (i.e., Abu Dhabi, Department of Energy, etc.):
• Draft incident communication messages in consultation with Cyber Incident Response
Manager and Legal team;
• Share incident communication message with regulators after approval from senior
management; and
Media Communication:
• Provide inputs into external communications strategy based on likely questions that might
be raised by media;
• Field all media and public inquiries regarding incident.
• Ensures media information requests are fulfilled; as well as ensure that any communication
Public Affairs/ shared is first approved by senior management;
Communications • Prepare FAQs based on common media queries and publish them through website, press
releases, emails etc.;
• Prioritizes requests for interviews;
• Work to ensure that all media inquiries are routed to appropriate stakeholders;
• Coordinate press releases, and manage news teams and interviews, etc.;
• Prepare statements for press release; and
• Create a log of inquiries received from external parties like media/ journalists etc.
Media Monitoring:
• Monitor and track media to gauge what is being circulated on media regarding incident.
• Issue responses to rectify inaccurate information;
• Assess the level of focus of external interest. Analysis of what is being reported;
• Assess the reputational impact to entity and recommend corrective actions; and
• Identify concerns, interests, and needs arising from the incident and the response.
Physical Security Manage and ensure needed physical access to on-site and off-site premises and physical
Team protection of infrastructure.

Annexure XVI: Cybersecurity Incident Classification
Matrix
Directly impacts Entity can no longer Unpredictable; Poses an imminent

Level 5
Critical system
power or water provide a critical additional resources threat to the
information was
delivery at one or operational service to and outside help are provision of wide-
compromised
multiple areas all users needed scale critical services
Compromise of
network or system
that controls Likely to result in a
Entity can no longer Unpredictable;
Level 4
power and water Critical system significant impact to

provide a critical additional resources
generation and information was the health or safety,
business service to and outside help are
delivery and could compromised national security,
a subset of users needed
lead to an outage economic security
at one or multiple
utilities.
Likely to result in a
Sensitive, PII, or
Compromise or Entity can no longer demonstrable impact
proprietary Unpredictable;
Level 3
denied availability provide a critical to the health or

information was additional resources
to a business- business service to a safety, national
accessed, changed, and outside help are
critical enterprise subset of system security, economic
exfiltrated, deleted, needed
system or service users security, or public
or made unavailable
confidence
Minimal effect; the
entity can still
Non-PII or May impact health
Compromise of provide all critical
Level 2
proprietary Predictable with or safety, national

security of non- business services to
information was existing or additional security, economic
critical enterprise all users, but has
accessed or resources security, or public
business systems lost efficiency or lost
exfiltrated confidence
some non-critical
services
Suspected
security threat or
Minimal effect; the
isolated incident Unlikely to impact
entity can still
Level 1
with minimal Sensitive Predictable with health or safety,

provide all critical
impact (e.g. information at-risk existing or additional national security,
services to all users,
successful but not exfiltrated resources economic security,
but has lost
phishing attempt or public confidence
efficiency
with no loss of
data)
No effect to the
Level 0
Notification of No information was Unsubstantiated or

entity’s ability to
suspicious exfiltrated, changed, - inconsequential
provide all services
behavior or deleted event
to all users

Annexure XVII: References
i. ISO/IEC 27001:2013, Information technology — Security techniques — Information security
management systems — Requirements.
ii. ISO/IEC 27002:2013, Information technology — Security techniques — Code of practice for
information security controls.
iii. ISO/IEC 27005:2018, Information technology — Security techniques — Information security
risk management.
iv. ISO/IEC 27017:2015, Information technology — Security techniques — Code of practice for
information security controls based on ISO/IEC 27002 for cloud services.
v. ISO/IEC 27019:2017, Information technology — Security techniques — Information security
controls for the energy utility industry.
vi. NIST Special Publication 800-30, Revision 1, Guide for Conducting Risk Assessments.
vii. NIST Special Publication 800-40, Revision 3, Guide to Enterprise Patch Management
Technologies.
viii. NIST Special Publication 800-53, Revision 5, Security and Privacy Controls for Information
Systems and Organizations.
ix. NIST Special Publication 800-82, Revision 2, Guide to Industrial Control Systems (ICS)
Security.
x. NIST Special Publication 800-61, Revision 2, Computer Security Incident Handling Guide.
xi. NIST Special Publication 800-114, Revision 1, User’s Guide to Telework and Bring Your
Own Device (BYOD) Security.
xii. NIST Special Publication 800-128, Guide for Security-Focused Configuration Management
of Information Systems.
xiii. NIST Special Publication 800-181, Workforce Framework for Cybersecurity (NICE
Framework).
xiv. ANSI/ISA–62443-2-1 (99.02.01)–2009 Security for Industrial Automation and Control
Systems Part 2-1: Establishing an Industrial Automation and Control Systems Security
Program.
xv. ANSI/ISA-62443-3-3 (99.03.03)-2013 Security for industrial automation and control systems
Part 3-3: System security requirements and security levels.
xvi. CISA: Capacity Enhancement Guide (CEG): Social Media Account Protection.
xvii. The General Data Protection Regulation (GDPR) by European Public Service Union.
xviii.UAE, The National Standard For Business Continuity Management System (Specifications)
AE/SCNS/NCEMA 7000:2021.
xix. Public Power Cyber Incident Response Playbook by American Public Power Association.

abudhabidoe doe.gov.ae Department of Energy Abu Dhabi

DOE Cybersecurity Framework

Uploaded by

Copyright:

Available Formats

You might also like

DOE Cybersecurity Framework

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DOE Cybersecurity Framework

Uploaded by

Copyright:

Available Formats

Abu Dhabi Department of Energy

Emerging technology trends in energy sector have

Modernization of energy infrastructure through

Classification code – Classification: Public 1

Information Technology (IT) and Operational

and respond to the inevitable

Classification code – Classification: Public 2

2 Abbreviation and Glossary 8

3 Scope and Compliance 15

CSG Cybersecurity Governance 24

CSRM Cybersecurity Risk Management 40

CSPE Cybersecurity Performance Evaluation 51

CCM Configuration and Change Management 94

CC Cryptography Control 104

CSCM Cybersecurity Continuity Management 110

CSPM Cybersecurity in Project Management 116

CSIM Cybersecurity Incident Management 125

DPP Data Protection and Privacy 143

HRS Human Resource Security 146

IAM Identity Access Management 157

LCRC Legal, Contractual and Regulatory Compliance 175

LM Logging and Monitoring 181

NSM Network Security Management 191

PES Physical and Environment Security 210

TPRM Third Party Risk Management 228

VM Vulnerability Management 243

6 Domain Mapping 252

I Cybersecurity Risk Management Process 257

II Change Prioritization Guide 265

III Personal Data Protection Goals 266

IV Fair Information Practices 267

V Privacy by Design Principles 268

VI Personal Data Security Measures 269

VII Social Media Policy 274

VIII Social Media Security Controls 275

IX Cybersecurity Workforce Development 277

X ICS/ OT Systems Password Management 279

XI Network Segmentation 281

XIV Cybersecurity Incident Handling Process 286

XV Cybersecurity Incident Response Team Roles 287

XVI Cybersecurity Incident Classification Matrix 289

XVII References 290

Historically, OT environments have been isolated with

Since energy sector is deemed as critical infrastructure

Protecting the energy infrastructure has become more

To help the sector navigate the ever-evolving threat

Embracing the cybersecurity framework will help in

The purpose of the Abu Dhabi Department of Energy

The framework would be supplemented with an ongoing

Classification code – Classification: Public 7

Classification code – Classification: Public 9

Classification code – Classification: Public 10

Classification code – Classification: Public 11

Classification code – Classification: Public 12

Confidentiality The preservation of authorized restrictions on information access

The framework’s cybersecurity controls shall apply to

Licensed entities are expected to establish, implement,

The organizations referred to as “Licensed Entities” in

3.2. Ownership & Revision