UAE IA

For the design and implementation of information security within an entity, it is important to evaluate and understand both the external and internal context of the entity, since these can significantly influence the design of information security solutions. For the external factors, this activity should include topics such as: a. the industry sector, legal, regulatory, financial, technological, economic, political, natural and competitive environment, whether international, regional, national or local. b. key drivers and trends having impact on the information security objectives of the entity. c. relationships with, and dependencies of, external stakeholders. d. emerging technologies and its impact. e. entity’s threat environment. The evaluation of internal factors should address topics such as: 10 a. governance, organizational structure, roles and accountabilities. b. capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems and technologies). c. information systems, information flows and decision-making processes. d. relationships with, and perceptions of, internal stakeholders. e. the form and extent of contractual relationships.

Top management commitment and its visible demonstration is one important contributor to the overall success of information security within an entity. This does not mean that top management is carrying out the actions listed above themselves, but they need to ensure that the actions do take place, and that they are concluded successfully. One important part in these responsibilities is the assignment of appropriate resources, without which information security cannot succeed (see also M1.3.1 below). Another important aspect is the connection between business goals and requirements and information security. Ideally, this is a balance between these items, and it should never be the case that information security hinders the business. It should, of course, also not be the case that an entity takes any unjustified risks and neglects security. The final decision, which takes precedence, should be made by the top management. Management should identify the needs for internal or external specialist information security advice, and review and coordinate results of the advice throughout the entity. 11 The roles of the “Information Security Leadership” and the “Information Security Committee” are important contributors to successful information security and have therefore been defined as sub-controls. When implementing these sub-controls, please keep in mind that it is important to address these roles, but the name and way of implementation of these roles can be chosen by the entity. The Information Security Committee should have a leading role for information security in the entity and should be responsible for handling important information security issues. The members of the Information Security Committee should have a sufficient understanding of information security for directing, monitoring, and completing the necessary tasks. The committee should include representatives from various departments to ensure a holistic approach to information security and compliance across the entity. Typical tasks of an Information Security Committee could be: a. defining and establishing roles and responsibilities for information security. b. establishing information security goals and objectives and overseeing their alignment with business strategies. c. defining the information security strategy. d. prioritizing strategic projects or initiatives related to information security. e. facilitating communication of information security needs and requirements across different business functions or lines. f. monitor the adequacy of resources to maintain and improve information security in the entity and recommend to management the acquiring of additional resources where necessary. g. providing input into the development, approval, implementation and maintenance of information security policies and procedures. h. discussing practical issues regarding the implementation of information security policies and procedures and providing feedback from their respective parts of the entity.

12 i. ensure that the status of information security risks is up to date and approve the updated risk assessment. j. deciding the criteria for accepting information security risks and the acceptable levels of risk. k. reviewing the results of performance measurement activities and the audit reports. The Information Security Leadership should be the focal point for information security within the entity and should be responsible for directing the information security team (if present) and providing valuable input to the Information Security Committee. The entity should maintain sufficient segregation of operational and governance responsibilities for information security and ensure that there is no conflict in reporting lines for information security (such as Information Technology). Additional responsibilities, such as technical security managers or asset owners can also be identified, as needed to implement information security in the entity. If necessary, roles and responsibilities should also be defined for contractors and third-party users, and it should be ensured that all roles and responsibilities are reviewed periodically and kept up to date. M1.2 Information Security Policy Objective To provide a framework and management direction and support for information security in the entity, in accordance with business requirements and relevant laws and regulations. Performance Indicator Percentage of information security policies reviewed as per defined frequency. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Lack of information security policies • Inadequate information security policies • Unawareness of information security policies and procedures among third parties and employees • Non-compliance with information security controls

The following information should be considered for inclusion in the information security policy: a. statement related to management commitment and support of the goals and principles of information security in line with the business strategy and objectives. b. description of the entity’s approach to managing information security. c. definition of information security in terms of confidentiality, integrity, and availability. d. reference to the entity risk management policy and the entity’s approach to information security risk management. e. reference to other risk management activities taking place in the entity, and how the information security risk management relates to that. f. importance of compliance with the information security policy, and all supporting information security policies and procedures, and consequences of violations. g. requirements of particular importance to the entity, e.g.: compliance with contractual requirements or legislative and regulatory requirements of the sector and Emirates. h. security education, training, and awareness requirements. i. business continuity management. j. definition of general and specific responsibilities for information security, including reporting information security incidents. k. references to supporting information security policies and procedures. The information security policy should be written in clear, simple, and easily understandable language appropriate for its intended audience. It should avoid complex or technical jargon unless necessary, ensuring that all stakeholders, regardless of their level of expertise can comprehend its contents and implications. This information security policy should be communicated throughout the entity in a form that is relevant, accessible, and understandable to the intended reader. The information security policy should be made available to interested third parties as required, depending on the needs and requirements of identified interested parties. Interested parties may include but are not limited to suppliers, vendors, customers, and regulators.

Based on the entity’s context and business objectives for information security, information security objectives should be identified (Refer M1.1). The entity can consider high-level objectives, such as: a. maintaining the confidentially of ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ entity information. b. successful management of the information security risks. c. efficient management of information security in the entity. d. compliance with the Emirate, sector, or national requirements. These high-level information security objectives are often directly derived from the business objectives, and other, lower-level objectives, can be identified to support their fulfillment. The lower-level information security objectives can be identified based on the results of the information security risk assessment and risk treatment process (Refer M2.2 and M2.3), and can also be identified by considering the following questions: a. What third-party relationships and agreements exist, and what are associated information security requirements? b. Are there any services that have been outsourced? c. What kind of protection is needed, and against what threats? d. What are the distinct categories of information that require protection? e. What are the distinct types of information activities that need to be protected? f. What are the minimum market requirements for information security? g. What additional information security controls should provide a competitive advantage for the entity? h. What are the critical business processes, and how long can the entity tolerate interruptions to each critical business process? When planning how to achieve the information security objectives, it can be helpful to develop an equivalent of the risk treatment plan, i.e. a plan that details the actions, resources, responsibilities, time frames, and methods of evaluating whether the objectives have been achieved. When planning how to achieve its information security objectives, the entity shall determine: a. what will be done? b. what resources will be required? c. who will be responsible? d. when it will be completed? e. how the results will be evaluated?

The entity should allocate appropriate resources for information security, taking into account people, skills, experience, and competence. a. resources needed for each part of the process to achieve and maintain information security. b. specific resources for information security risk management (refer to M2). c. documentation (refer to M1.3.3). d. knowledge and management of competence. 17 e. training programs (refer to M3.2). Top management is responsible for ensuring that the right resources are allocated and that all resources receive appropriate training. All personnel should have the competence to perform the operations required in the role assigned. The training performed should help all personnel be aware of and understand the meaning and importance of the information security activities they are involved in, and how they can contribute to achieving the objectives of information security.

Internal communication: The entity should establish internal communication and reporting mechanisms in order to support information security. These mechanisms should ensure that: a. key components of the information security controls and any subsequent modifications, are communicated appropriately. b. there is adequate internal reporting on information security, its effectiveness, and the outcomes. c. relevant information derived from the application of security controls is available in the entity, as appropriate. d. there are processes for consultation with internal stakeholders. External communication: The entity should develop and implement a plan as to how it will communicate with external stakeholders. This should involve: a. engaging appropriate external stakeholders and ensuring an effective exchange of information). b. external reporting to comply with legal, regulatory, sector, Emirate, and governance requirements. c. identifying and remediating any liability issues and requirements regarding unauthorized disclosure of information in all information-sharing communities in which the entity participates. d. providing feedback and reporting on communication and consultation. e. using communication to build confidence in the entity and its security. f. communicating with stakeholders in the event of a crisis or contingency. During communication, care should be taken regarding the confidentiality of the information involved. 18 The entity should establish capabilities and processes for cyber security information sharing to promote cyber security awareness, enhance resiliency and preparedness, and enable effective and timely cyber incident response. The entity should maintain access to sector-specific and national cyber situational awareness information by maintaining contact with Sector/ Emirate Security Operations Centers (CSOCs) and the National Security Operations Center (NSOC). The entity should coordinate with sector / Emirates regulators and the National Security Operations Center (NSOC) to stay informed about policy updates, national-level changes, and evolving technologies affecting cyber security. To effectively protect and manage threat-related information, the entity should implement robust controls for information- sharing. While many information-sharing communities operate on a voluntary basis, some entities may face mandatory requirements to participate in specific platforms mandated by regulators or national authorities. The entity should document all methods and mechanisms used in information sharing, ranging from formal, security clearance- based exchanges to more ad-hoc, trust-based interactions. This includes utilizing protocols such as TAXII and the Traffic Light Protocol, as well as person-to-person and machine-to-machine sharing via STIX (Please refer to the information-sharing framework published by the CSC). The entity should adhere to the format, classification, and treatment standards set by the community. In instances where information cannot be fully validated before sharing, any limitations should be clearly indicated, particularly if the source is anonymous. Technical solutions, such as cryptographic mechanisms, may be used to maintain the authenticity of the information without compromising anonymity. Additionally, recipients are responsible for obtaining necessary permissions for further distribution of shared information. Rules for protecting information in transit must be established and accepted by all members before joining the community, and alternative, non-electronic sharing methods should be considered when appropriate.

19 One of the most important aspects of implementing document management in an entity is to do this consistently and throughout the entity, with supporting training, awareness and also checking that the document management controls are followed. It is necessary to include templates for document management in all documentation, irrespective of the form it takes. All this can be supported by using document management systems and other controls to technically ensure that the necessary actions are carried out, wherever it is possible, it is recommended to use technical support to achieve a complete implementation. The entity should consider implementing a document management system (DMS) to centralize, organize, and secure the storage of critical documents. A DMS will help ensure efficient document retrieval, version control, and compliance with regulatory requirements. It should support secure access controls, audit trails, and backup procedures to safeguard sensitive information, while also enabling seamless collaboration across teams. The system should be integrated with other business processes and workflows to improve operational efficiency, reduce the risk of data loss, and ensure business continuity. Particular attention should be given to the protection of records. It is important to maintain a change history for records since records should remain unaltered if they are to provide evidence. The date of issue and the integrity of the record are critical elements to maintain. One of the most effective mechanisms to ensure the integrity of published documents is digital signing. Using digital signatures can provide a secure way to authenticate the document's origin and maintain its integrity over time.

Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). The appropriateness of the information security considerations and activities should be followed up at predefined stages by suitable persons or governance bodies, such as the project steering committee. Responsibilities and authorities for information security relevant to the project should be defined and allocated to specified roles. Information security requirements for products or services to be delivered by the project should be determined using various methods, including deriving compliance requirements from information security policy, topic-specific policies, and regulations. Further information security requirements can be derived from activities such as threat modeling, incident reviews, use of vulnerability thresholds, or contingency planning, thus ensuring that the architecture and design of information systems are protected against known threats based on the operational environment. Information security requirements should be determined for all types of projects, not only ICT development projects. 20 The following should also be considered when determining these requirements: a. what information is involved (information determination), what are the corresponding information security needs (classification; see T1.3.1), and the potential negative business impact which can result from lack of adequate security. b. the required protection needs of information and other associated assets involved, particularly in terms of confidentiality, integrity, and availability. c. the level of confidence or assurance required towards the claimed identity of entities in order to derive the authentication requirements. d. access provisioning and authorization processes, for customers and other potential business users as well as for privileged or technical users such as relevant project members, potential operation staff or external suppliers. e. informing users of their duties and responsibilities. f. requirements derived from business processes, such as transaction logging and monitoring, non-repudiation requirements. g. requirements mandated by other information security controls (e.g. interfaces to logging and monitoring or data leakage detection systems). h. compliance with the legal, statutory, regulatory and contractual environment in which the entity operates. i. level of confidence or assurance required for third parties to meet the entity’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts.

Membership in special interest groups or forums should be considered as a means to: a. improve knowledge about best practices and staying up to date with relevant security information. b. ensure the understanding of the information security environment is current and complete. c. receive early warnings of alerts, advisories, and patches pertaining to attacks and vulnerabilities. d. gain access to specialist information security advice. e. share and exchange information about new technologies, products, threats, or vulnerabilities. f. provide suitable liaison points when dealing with information security incidents. 21 M2 Information Security Risk Management M2 Information Security Risk Management Objective To ensure that information security risks in the entity are identified, assessed and - evaluated and that these risks are treated in accordance with the information security requirements and objectives of the entity. Performance indicator Measure the percentage of risks that appear in the previous and the current risk assessment that have changed to a lower level. Measure the percentage of risks that appear in the previous and the current risk assessment that have changed to a higher level. M2.1 Information Security Risk Management Policy Objective To establish a formal information risk management framework for managing an entity’s information security risks by establishing the context, performing risk assessment, implementing risk treatments, and monitoring their implementation. Performance Indicator Trend in the number of occurrences where the risk assessment has not been performed, reviewed, or updated as planned. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Unsuitable risk management policy • Inconsistent or incomparable risk assessment results • Inconsistent or unsuitable risk evaluation criteria

Entities owning, operating, or maintaining Critical Information Infrastructure should take into account all relevant CSC issuances and guidance with regards to risk management when performing risk assessment. 22 The information security risk management policy should clearly define how the entity is planning to carry out the risk assessment. In addition to the requirements stated above, the policy can, for example, contain: a. the level of detail of asset identification. b. the basis of threat and vulnerability identification. c. the scales to be used for asset valuation in terms of confidentiality, integrity and availability. d. the mechanism to calculate the likelihood of a threat exploiting a vulnerability. e. how the risks severity is calculated. f. who will be responsible for performing the risk assessment. g. the basis of control selection. h. how to measure risk management performance. i. criteria for improving risk management. The risk management policy should also describe the type of risk assessment the entity intends to perform, whether it is more of a higher-level assessment or a detailed one (see also M2.2), and the reasons for that choice. The decision for a particular approach should be made based on: a. the security requirements of the entity. b. their current level of maturity, and where the entity eventually wishes to be (link to self-assessment). c. the capabilities, knowledge, and resources available at this point in time. d. the given mandates by the entity’s sector or national context. The entity should be able to provide reasons for the chosen information security risk management approach. The risk management policy should be communicated appropriately. Please note: the risk management policy is sometimes also denoted as a risk management framework. 23 M2.2 Information Security Risk Assessment Objective To identify, analyze, and evaluate the information security risks the entity is facing. Performance Indicator Percentage of risk assessments that were completed within the planned or scheduled timeframe. Automation Guidance Tools can be used for automating the information security risk management process. When doing so, care should be taken to use a tool that is: • suitable to the entity • complies with the requirements of this standard. • allows to address all controls included in this standard. • easy and effective to use. Relevant Threats and Vulnerabilities • Unidentified risks • Incorrect asset valuation • Threats or vulnerabilities that have not been considered. • Wrongly assessed risks • Inadequate risk evaluation criteria • Inadequate skills and knowledge to conduct risk assessment

There is a lot of information related to the performance of information security risk assessments; therefore, this implementation guidance will just provide an overview of the most important concepts. The entity should take into account relevant the CSC issuances and guidance with regard to risk management when performing risk assessment. Level of detail of the information security risk assessment: Some entities might find it difficult or time-consuming to conduct a detailed risk assessment. The choice of a suitable risk management approach should be taken when drafting the Information Security Risk Management Policy (refer to M2.1.1), and the implementation guidance there explains the considerations the entity should take into account when deciding on a suitable way of doing information security risk management. The entity should document these results and should be able to provide reasons for the decision taken. An entity will only be considered as being compliant with the requirements of this standard if they apply a suitable information security risk management policy. The entity should apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability of its information by: 24 a. defining the scope of the risk assessment exercise. b. identifying critical business functions. c. identifying critical information systems supporting business critical functions within the scope and boundary of the risk assessment. (for asset based risk assessment) d. Identify critical processes supporting the business critical functions within the scope and boundary of the risk assessment (for process based risk assessment) e. identifying vulnerabilities related to the information and information systems or processes. f. identifying existing information security controls. g. identifying threats and threat sources. Guidance for Asset Based Risk Assessment If the entity opts to undertake an asset-based risk management process, it is advised to adhere to the following guidance: Asset identification: The assets to be considered in the information security risk assessment are all information assets, such as: a. information: databases, files, contracts and agreements, system documentation, research information, user manuals, training material, operational or support procedures, etc. b. software assets: application software, system software, development tools, and utilities. c. physical assets: computer equipment, communications equipment, removable media, and other equipment d. services: computing and communications services, general utilities, e.g. heating, lighting, power, and air- conditioning. e. people, and their qualifications, skills, and experience. f. intangibles, such as reputation and image of the entity. The identified assets are summarized in the Asset Inventory (refer to T1.2.1). It might be useful to summarize assets in suitable groups (e.g. all PCs in a call center, processing the same type of information), but care should be taken to only group “alike items” when doing so. It is also helpful to take account of business processes, as they often can help to understand the information flow and how assets are working in the entity. Identification of threats: Threats are not very dependent on the entity and its business; they are just out there trying to succeed. When identifying threats, it can be helpful to use threat lists (e.g. those provided in this standard, or in other standards, such as ISO/IEC 27005), and to look into incident reports (incidents are always related to threats that have been successful- and audit reports, and to keep an open mind to the latest development as new threats will continue to emerge. It is also important to not only look at threats from the outside, such as hackers or malware but also consider inside threats. A disgruntled employee with given access rights can often do more damage than outsiders. Identification of vulnerabilities: The identification of vulnerabilities should be based on an assessment of the existing controls. To do so, it is recommended to conduct a gap analysis, which checks the controls in place against this standard. The results of the gap analysis form an input in the identification of vulnerabilities as well as into the assessment of the risk likelihood (see also M2.2.2 below). 25 Any control, that has been identified as missing, not completely in place, not fully documented, or not complied with, identifies at least one (if not more) vulnerability, which might be exploited by the identified threats. Please note: The identification of threats and vulnerabilities takes place per each identified asset, so this easily produces a lot of information. To keep the amount of information manageable, it is recommended to: a. identify threats and vulnerabilities with the existing controls in mind. b. identify only threat/vulnerability pairs where the threat will actually exploit the vulnerability. Guidance for Process Based Risk Assessment If an entity opts to undertake a process-based risk assessment instead, the focus will shift from individual assets to evaluating business processes and workflows. In this approach, risks are identified by analyzing the processes that involve information flow, software usage, physical and service assets, and people. The process-based assessment includes: a. Process Identification: Identify key business processes that are critical to the entity’s operations, considering all aspects such as data flow, interactions between systems, and dependencies on people and services. b. Threat and Vulnerability Analysis: Threats and vulnerabilities should be identified for each process. However, the focus will be on how threats exploit weaknesses in the process itself. c. Control Effectiveness: Assess the controls in place for each process and conduct a gap analysis to identify any deficiencies that may expose the process to risk. In a process-based approac

This implementation guidance will just provide an overview of the most important concepts related to the information security risk analysis. Consequences of losses of confidentiality, integrity or availability: The first part of assessing the consequences of losses of confidentiality, integrity or availability is to identify the business importance the information asset under consideration has. Damage to an asset that is important for the business is much likely to cause severe consequences than an asset that is not as important. Based on the business use of the asset, the consequences for a loss of the following needs to be assessed: 26 a. confidentiality – this means the information asset is only accessible to those authorized to access it. b. integrity – this means the information asset has not been modified in any unauthorized way. c. availability – this means the information asset is available, when needed. To make the results of this assessment comparable, scales should be used, which should have been defined in the Information Security Risk Management Policy (see M2.1.1 above). The assessment of these consequences should be done together with the business users of the information assets, as these can give important input into the process because they are aware of the security requirements for their assets. This can be done by interviews and/or questionnaires, but it is important to ensure that the business users understand what is asked from them. As a result, each asset should have identified the consequences of losses of confidentiality, integrity and availability. Likelihood of threat/vulnerability combinations: The input into the assessment of the likelihood that a particular threat exploits a vulnerability is based on very similar considerations as the identification of threats and vulnerabilities (see M2.2.1 above). The likelihood of a threat occurring can be derived from threat catalogues and statistics, as well as incident records, audit logs and reports, etc. the entity has produced. The level of vulnerability is based on how good or bad the controls are that have been put in place, so this can also be derived from the results of the gap analysis (see M2.2.1 above). Finally, the likelihood of the threat to occur and the level of vulnerability are put together to determine the likelihood that this threat/vulnerability combination occurs. How exactly these values are put together has been defined in the Information Security Risk Management Policy (see M2.1.1. above). Determining the levels of risk: Based on the method to calculate risks, which has been chosen by the entity and has been documented in the Information Security Risk Management Policy (see M2.1.1. above), the risks should now be calculated using the consequences and likelihoods that have been assessed. Please note: The details on how to calculate the risks and which valuation schemes are used for consequences and likelihood is entirely up to the entity to decide. It is nevertheless important that the approach chosen is applied consistently.

This implementation guidance will provide an overview of the most important concepts related to the performance of information security risk assessments. Once the risks have been calculated (see M2.2.2 above), the entity should compare the risk levels assessed with the risk criteria that have been established documented in the Information Security Risk Management Policy (see M2.1.1. above). This will rank the risks in order of severity and will identify those that are acceptable (because they are below the general threshold of acceptance), and those risks that will require treatment. 27 If necessary, the entity can assign additional priorities to the risks, e.g. if a risk – despite not being high relates to a very vital business process. Any such assignment is entirely up to the entity, any decisions made should be reasoned and documented. Decisions on risks should take account of the wider context of the risk and include consideration of the requirements of other parties, such as sector, Emirate or national initiatives. In some circumstances, the risk evaluation can lead to a decision to undertake further analysis. 28 M2.3 Information Security Risk Treatment Objective To identify and plan appropriate risk treatment for the risks that have been assessed. Performance Indicator Percentage of identified risks that have been successfully treated within the planned timeframe. Automation Guidance See M2.2 Relevant Threats and Vulnerabilities • Inadequately treated risks • Incomplete risk register • Too high residual risks • Wrongly assessed residual risks • Lack of management awareness of information security risks • Delayed implementation of risk treatment plans

Selecting the most appropriate information security risk treatment option involves balancing the costs and efforts of implementation against the benefits derived. Decisions should also take into account risks which can warrant risk treatment that is not justifiable on economic grounds, e.g. severe (high negative consequence-but rare low likelihood- risks). A number of treatment options can and should be considered and applied either individually or in combination. When selecting risk treatment options, the entity should consider the expectations of the sector, Emirate and national level. Though equally effective, some risk treatments can be more acceptable to some stakeholders than to others. If an entity chooses to accept the risk (risk retention), the decision should be accepted by the risk owner and communicated to the top management for their concurrence. Justifications for risk acceptance should be clearly defined and documented. 29 The selected risk treatment options should be documented in the risk treatment plan. The treatment plan should clearly identify the priority order in which individual risk treatments should be implemented. Risk treatment itself can introduce risks. A significant risk can be the failure or ineffectiveness of the risk treatment measures. Monitoring needs to be an integral part of the risk treatment plan to give assurance that the measures remain effective (see also M6).

Controls should be identified to manage the risks, based on the identified risk treatment option(s). It is important to specify the relation between the risks and the identified controls, this relation is important for the ongoing risk management and should be documented in the risk treatment plan. The first basis of control identification should be this standard, which suggests a set of “risk-based applicable” controls that addresses a lot of the common information security risks. Sector-specific and Emirate- specific controls should be identified to support the specific needs of the entity within its context. The entity should also identify controls that are required for risk management and not documented in this standard. It is likely that such controls exist as an entity has risks specific to its business and its way to operate, and the identification of additional controls completes the controls for information security risk management. The entity should compile a list of controls which have been identified to produce a Statement of Applicability (refer to M2.3.4). It might be that the Statement of Applicability (refer to Implementation Guidance of M2.3.4) leads to a revision of the identified controls. This is the intention of producing the Statement of Applicability, it is supposed to act as a safety net that ensures that no important control has been overlooked. It is important to be aware that the list of identified controls is very likely to contain ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information. Therefore, appropriate care should be taken when making the summary of controls available to both internal and external recipients.

The purpose of risk treatment plans is to document how the chosen risk treatment options will be implemented. The information provided in treatment plans should include: a. the reasons for selection of treatment options. b. the controls that have been identified to implement the selected risk treatment option(s). c. the identified risk reduction or other modification that is intended to be achieved by the identified control(s), also called residual risk. d. those who are accountable for approving the plan. e. those responsible for implementing controls and the overall plan. f. proposed actions to achieve this implementation. g. priorities of implementation. h. resource requirements including contingencies. i. target dates for control implementation. j. interdependencies of control implementation (when the implementation of a control requires the complete implementation of another control). k. performance measures and constraints (which can also be documented elsewhere). l. reporting and monitoring requirements. The risk treatment plan should be integrated with the management processes of the entity and discussed with appropriate stakeholders. Management should be aware of the nature and extent of the residual risk after risk treatment and should accept the residual risks. The residual risk should be documented and subjected to monitoring, review and, where appropriate, further treatment.

The Statement of Applicability should be produced to ensure that no control from these that is required by the entity for risk treatment is overlooked. If the first version of the Statement of Applicability identifies controls from this standard whose exclusion cannot be justified, the entity should go back to the control identification process (refer to M2.3.2) and check whether there are risks whose treatment could benefit from this control. If this is the case, the control under consideration should be included in the risk treatment. If this is not the case, the entity should go back to the risk identification and ensure that all important risks have been identified. The reasons for the identification of controls are needed to form the link between risks and controls – this relationship can also be documented in the risk treatment plan (refer to M2.3.3). The Statement of Applicability can be a separate document, or can be combined with the risk treatment plan, this can be decided by the entity. 32 M2.4 Ongoing Information Security Risk Management Objective To ensure that the risk management process is communicated, consulted, and monitored. Performance Indicator Percentage of cases in the past year where the information security risk assessment and/or risk treatment was not updated as scheduled, despite significant changes occurring. Automation Guidance Not Applicable Relevant Threats and Vulnerabilities • No review or update of the information security risk assessment and treatment • Unidentified new information security risks • Low engagement from stakeholders

Risks are not static. Threats, vulnerabilities, likelihood, or consequences can change abruptly without any indication. Therefore, constant monitoring is necessary to detect these changes. This can be supported by external services that provide information regarding new threats or vulnerabilities. The entity should ensure that the following are continually monitored: a. effectiveness of the controls implemented for risk treatment. b. new assets that have been included in the risk management scope. c. necessary modification of asset values, e.g. due to changed business requirements. d. new threats that can be active both outside and inside the entity and that have not been assessed. e. possibility that new or increased vulnerabilities can allow threats to exploit these new or changed vulnerabilities. f. identified vulnerabilities to determine those becoming exposed to new or re-emerging threats. g. increased impact or consequences of assessed threats, vulnerabilities, and risks in aggregation. h. resulting in an unacceptable level of risk. i. information security incidents. 33 New threats, vulnerabilities, or changes in likelihood or consequences can increase risks previously assessed as low ones. Review of low and accepted risks should consider each risk separately, and all such risks as an aggregate as well, to assess their potential accumulated impact. If risks do not fall into the low or acceptable risk category, they should be treated using one or more of the options considered in M2.3. Factors that affect the likelihood and consequences of threats occurring can change, as can factors that affect the suitability or cost of the various treatment options. Major changes affecting the entity should be reason for a more specific review. Therefore, the risk monitoring activities should be repeated regularly and the selected options for risk treatment should be reviewed periodically. The outcome of risk monitoring activities can be input into other risk review activities. The entity should review all risks regularly, and when major changes occur. Responsibilities for monitoring and review should be clearly defined. The results of monitoring and review should be recorded and externally and internally reported as appropriate and should also be used as input to the review of the information security risk management policy (refer to M2.1.1). Ongoing monitoring and review is necessary to ensure that the context, the outcome of the risk assessment and risk treatment, as well as management plans, remain relevant and appropriate to the circumstances. The entity should make sure that the information security risk management process and related activities remain appropriate in the present circumstances and are followed. Any agreed improvements to the process or actions necessary to improve compliance with the process should be notified to the appropriate managers to have assurance that: a. no risk or risk element is overlooked or underestimated. b. the necessary actions are taken. c. decisions are made to provide a realistic risk understanding and ability to respond. Additionally, the 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. It should also regularly verify that changes to the business context are taken into consideration adequately during the information security risk management process. This monitoring and review activity should address (but not be limited to): a. competition context. b. risk assessment approach. c. asset value and categories. d. impact criteria. e. risk evaluation criteria. f. risk acceptance criteria. g. total cost of ownership. h. necessary resources. The entity should ensure that risk assessment and risk treatment resources are continually available to review risk, address new or changed threats or vulnerabilities, and advise management accordingly. Risk monitoring can result in modifying or adding the approach, methodology, or tools used depending on: a. changes identified. b. risk assessment iteration. c. aim of the information security risk management process (e.g. business continuity, resilience to incidents, compliance); and 34 d. object of the information security risk management process (e.g. entity, business unit, information process, its technical implementation, application, connection to the Internet).

Risk communication is an activity to achieve agreement on how to manage risks by exchanging and/or sharing information about risk between the decision-makers and other stakeholders. The information includes, but is not limited to the existence, nature, form, likelihood, severity, treatment, and acceptability of risks. Effective communication among stakeholders is important since this can have a significant impact on decisions to be made. Communication ensures that those responsible for implementing risk management, and those with a vested interest understand the basis on which decisions are made and why particular actions are required. Communication is bi-directional. Perceptions of risk can vary due to differences in assumptions, concepts, and the needs, issues, and concerns of stakeholders as they relate to risk or the issues under discussion. Stakeholders are likely to make judgments on the acceptability of risk based on their perception of risk. This is especially important to ensure that the stakeholders’ perceptions of risk, as well as their perceptions of benefits, can be identified and documented and the underlying reasons clearly understood and addressed. Risk communication should be carried out in order to: • provide assurance of the outcome of the entity’s risk management. • collect risk information. • share the results from the risk assessment and present the risk treatment plan. • avoid or reduce both the occurrence and consequence of information security breaches due to the lack of mutual understanding among decision-makers and stakeholders. • support decision-making. • obtain new information security knowledge. • coordinate with other parties and plan responses to reduce the consequences of any incident. • give decision-makers and stakeholders a sense of responsibility for risks. • improve awareness. The entity should develop risk communication plans for normal operations as well as for emergency situations, taking into account all the CSC issuances with regard to risk management. Therefore, risk communication activity should be performed continually. The coordination between major decision-makers and stakeholders can be achieved by the formation of a committee where debate about risks, their prioritization and appropriate treatment, and acceptance can take place. It is important to cooperate with the appropriate public relations or communications unit within the or entity to coordinate all tasks related to risk communication. 35 M3 Awareness and Training M3 Awareness and Training Objective To ensure sufficient information security awareness and training is provided and to build a specialized workforce. Performance indicator Percentage of awareness and training objectives that have been met successfully. M3.1 Awareness and Training Policy Objective To maintain an awareness and training policy outlining the approach to identifying relevant topics, enrollment of stakeholders, and documentation of activities. Performance Indicator The trend in the number of employees that have not successfully participated in the awareness and training program. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Outdated or insufficient awareness and training policy • Incomplete identification of training needs • Non-comprehensive training identification approach • Accidental information leaks due to lack of awareness • Software malfunction due to lack of trained personnel

The critical entities should also take into account the CSC's relevant issuances, guidance, and activities with regard to National Awareness and Capability Building. The policy document should contain statements concerning: a. the purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. b. the procedures to facilitate the implementation of the security awareness and training policy and associated security awareness and training controls. c. factors to consider when awareness and training objectives are identified. This policy can be included as part of the general information security policy, in a single policy document, or can be represented by multiple policies reflecting the complex nature of certain entities. 36 M3.2 Awareness and Training Planning Objective To ensure that all person(s) carrying out work affecting information security are sufficiently aware of information security requirements and controls and are adequately trained to execute their responsibilities. Performance Indicator Percentage of actions (planned training, participation in conferences, etc.) that have not been carried out as planned. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Non-compliance with controls due to a lack of awareness • Unidentified security breaches • Lack of skilled information security personnel • Promoting a culture of disinterest in information security matters

Critical entities should also take into account the CSC national awareness and capability-building issuances, guidance, and activities. An information security awareness program should aim to make personnel aware of their responsibilities for information security and the means by which those responsibilities are discharged. The awareness program should be planned to take into consideration the roles of personnel in the organization, including internal and external personnel (e.g. external consultants, supplier personnel). The activities in the awareness program should be scheduled over time, preferably regularly, so that the activities are repeated and cover new personnel. It should also be built on lessons learnt from information security incidents. The awareness program should include a number of awareness-raising activities via appropriate physical or virtual channels such as campaigns, booklets, posters, newsletters, websites, information sessions, briefings, e-learning modules and e-mails. The entity should develop a program that ensures continued adequate awareness and competence for all persons doing work under the control of the entity. Please note that the implementation of the awareness and training program might not be carried out by the entity and can, for example, be ensured contractually. The first step in the program is the training needs analysis for the relevant job function. The Information Security personnel, for example, should have a good understanding of the controls contained in this standard and should know how to implement them and to maintain them effectively. 37 The entity should ensure that training takes place as planned, and is not pushed off, e.g. due to work overload. If such problems recur, it might be a sign of inadequate resourcing. The awareness and training program should ensure that records of all trainings are generated. These records should regularly be reviewed to ensure that all personnel have received the training that they require. Whatever training is conducted, it is important that the effectiveness of this training is assessed. An easy way of such an assessment is to select training that includes an exam at the end. Whenever this is not possible, interviews or feedback forms should be used that provide enough information to be able to evaluate the effectiveness of the training. 38 M3.3 Security Training Objective To ensure that all personnel who are assigned responsibilities in information security are competent to perform the required tasks. Performance Indicator Percentage of identified information security training requirements that have been met with satisfactory results. Automation Guidance Web-based training modules (internally or externally created) can be used to implement trainings. This can also be used to automatically update staff training records, as well as to capture CPE credits needed to maintain security certifications. Relevant Threats and Vulnerabilities • Software malfunction due to lack of trained personnel • Error in use due to undelivered training

The entity should determine the appropriate content of security training and techniques based on the specific organizational requirements and in line with the entity’s information security policy. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content should also include advanced security information for the implementation and maintenance of information assets deployed within the entity. Information security training needs can be identified through various sources such as, internal audits, risk assessments, security incident reports, and feedback from employees or departments regarding challenges faced in securing information assets. Additionally, external sources such as industry standards, regulatory requirements, and emerging security threats should also inform the content of security training. By regularly assessing these needs, the organization can ensure that its security training program remains relevant, effective, and up to date, addressing both current and future security risks.

The entity should determine the trainings that should be delivered, the medium (class-based, web-based, documents), and the target audience, and develop the corresponding timeline for the execution in line with known organizational and users constraints.

Security trainings typically focus on topics specific to the applications and systems within the entities, such as security best practices for implementing and maintaining a database or patching operating systems. Specific training methods may include: a. internal training websites. b. manuals, guides, and handbooks. c. slide presentations. The entity should update training based on changes within the IT landscape, such as changing technology, updated systems, new services, or new threats.

Effectiveness of training could be measured through: a. written individual assessment of the training. b. voluntary self-reporting of participants. c. interviews. d. measurement of enhanced individual performance. e. compare events and incidents in the entity with training provided

The entity should consider the following: a. document and monitor individual information system security training activities including basic security awareness training and specific information system security training. b. retain individual training records in line with the training and awareness policy. 41 M3.4 Security Awareness Objective To foster security awareness of the workforce within the entity. Performance Indicator Percentage of identified information security awareness campaigns that have been successfully implemented. Automation Guidance Leverage internally or externally created web-based awareness modules to allow recurring training by the general workforce and external stakeholders. This can also be used to automatically update workforce training records. Relevant Threats and Vulnerabilities • Successful pretexting due to lack of awareness • Accidental leaks of data by staff • Illegal processing of data

Through awareness campaigns, the entity promotes a culture of security. Security awareness programs typically focus on broad topics, such as security threats that could be mitigated through good practice, the choice and usage of passwords, good practice for using a personal computer, sharing of account information, and reporting incidents. The entity should determine the appropriate content of security awareness based on the specific organizational requirements and the information systems to which personnel have authorized access. Specific training methods may include: a. mandatory annual awareness training. b. targeted, role-based training. c. internal security awareness websites. d. manuals, guides, and handbooks. e. seminars and slide presentations. f. events (e.g. security awareness week or month). 42 g. posters and brochures. h. email messages to all employees and contractors. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events. 43 M4 Human Resource Security M4 Human Resource Security Objective To ensure stakeholder awareness of the roles and responsibilities before, during, and in post-employment scenarios. Performance indicator Percentage of employees, contractors, and third parties who have read and formally accepted relevant information security policies. M4.1 Prior to Employment Objective To ensure that employees, contractors, and third party users understand their responsibilities, and are suitable for the roles they are considered for. Performance Indicator Percentage of new employees and contractors that have been fully screened and approved in accordance with company policies prior to starting work. Percentage of employees, contractors, and third parties who read and accepted relevant information security policies. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Intentional leaks and sharing of data by staff. • Successful pretexting due to lack of information security awareness among employees

Verification checks should take into account all relevant privacy, protection of personal data, and/or employment- based legislation, and should, where permitted, include the following: a. availability of satisfactory character references, e.g. one business and one personal. b. a check (for completeness and accuracy) of the applicant’s curriculum vitae. c. confirmation of claimed academic and professional qualifications. d. independent identity check (passport or similar document). e. more detailed checks, such as credit checks or checks of criminal records. 44 Where a job, either on initial appointment or on promotion, involves the person having access to information systems, and in particular if these are handling ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information, e.g. financial information or PII, the entity should also consider furthermore detailed checks. 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. A screening process should also be carried out for contractors, and third party users. Where contractors 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. Information on all candidates being considered for positions within the entity should be collected and handled in accordance with any appropriate legislation existing in the relevant jurisdiction. Examples of such information include, identification records, employment history, educational credentials, reference checks etc. Depending on applicable legislation, the candidates should be informed beforehand about the screening activities. All candidate information related to screening should be collected, processed and stored securely.

The entity should ensure that employees, contractors, and third party users: a. are properly briefed on their information security roles and responsibilities prior to being granted access to ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information or information systems. b. are provided with guidelines to state security expectations of their role within the entity. c. are motivated to fulfill the security policies of the entity. d. achieve a level of awareness on security relevant to their roles and responsibilities within the entity. e. conform to the terms and conditions of employment, which includes the entity’s information security policy and appropriate methods of working. f. continue to have the appropriate skills and qualifications.

The disciplinary process should not be commenced without prior verification that a security breach has occurred. The formal disciplinary process should ensure correct and fair treatment for employees who are suspected of committing breaches of security. The formal disciplinary process should provide for a graduated response that takes 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 offense, whether or not the violator was properly trained, relevant legislation, business contracts and other factors as required. In serious cases of misconduct, the process should allow for instant removal of duties, access rights, and privileges, and for immediate escorting out of the site, if necessary. Where possible, the identity of individuals subject to disciplinary action should be protected in line with applicable requirements. 48 M4.3 Termination or Change of Employment Objective To ensure that employees, contractors and third party users exit an entity or change employment in an orderly manner. Performance Indicator Percentage of employees, contractors, and third-party user accounts that are blocked after termination. Percentage of employees, contractors, and third-party users accounts whose profiles are modified based on role change. Automation Guidance An identity management system could be used to automatically disable terminated employee accounts and identify user accounts that are inactive. Relevant Threats and Vulnerabilities • Abuse of system access/privileges • Intentional leaks and sharing of data by staff • Illegal processing of data

The communication of termination responsibilities should include ongoing security requirements and legal responsibilities and, where appropriate, responsibilities contained within any confidentiality agreement, and the terms and conditions of employment continuing for a defined period after the end of the employees, contractors, or third party users employment. Responsibilities and duties that are still valid after termination of employment should be contained in employees, contractors, or third party users contracts. Changes of responsibility or employment should be managed as the termination of the respective responsibility or employment, and the new responsibility or employment should be controlled.

Applicable legislation for compliance consideration includes, but is not limited to, applicable federal laws, directives, policies, standards, and other guidance. The entity should take into consideration compliance in all relevant countries, if the entity: 51 a. conducts business in other countries. b. uses products and services from other countries where laws and regulations can affect the entity. c. transfers information across jurisdictional borders where laws and regulations can affect the entity. Cryptography is an area that often has specific legal requirements. Compliance with the relevant agreements, laws and regulations relating to the following items should be taken into consideration: a. restrictions on import or export of computer hardware and software for performing cryptographic functions. b. restrictions on import or export of computer hardware and software which is designed to have cryptographic functions added to it. c. restrictions on the usage of cryptography. d. mandatory or discretionary methods of access by the countries’ authorities to encrypted information. e. validity of digital signatures, seals and certificates. It is recommended to seek legal advice when ensuring compliance with relevant legislation and regulations, especially when encrypted information or cryptography tools are moved across jurisdictional borders. Contractual requirements related to information security should include those stated in: a. contracts with clients. b. contracts with suppliers. c. insurance contracts. The specific controls and individual responsibilities to meet these requirements should be similarly defined and documented.

Managers should regularly review the compliance of information processing within their area of responsibility with the appropriate security policies, standards, and any other security requirements. If any non-compliance is found as a result of the review, managers should: a. determine the causes of the non-compliance. b. evaluate the need for actions to ensure that non-compliance do not recur. c. determine and implement appropriate corrective action. d. review the corrective action taken. Technical compliance checking should be performed either manually (supported by appropriate software tools, if necessary) by an experienced system engineer, and/or with the assistance of automated tools, which generate a technical report for subsequent interpretation by a technical specialist. If penetration tests or vulnerability assessments are used, caution should be exercised as such activities could lead to a compromise of the security of the system. Such tests should be planned, documented and repeatable. Any technical compliance check should only be carried out by competent, authorized persons, or under the supervision of such persons. Results of reviews and corrective actions carried out by managers should be recorded and these records should be maintained. Managers should report the results to the persons carrying out the independent reviews, when the independent review takes place in the area of their responsibility. 56 M5.3 Information Systems Audit Considerations Objective To maximize the effectiveness of the information systems audit process Performance Indicator Percentage of audits interrupted due to operational or security issues. Automation Guidance N/A Relevant Threats and Vulnerabilities • Wrongly performed internal audit • Incorrect audit outcomes • Regular operations affected due to non-planned audit activities

Critical entities should also take into account any other the CSC’s relevant issuances, guidance, and activities in this regard. The following guidelines should be observed: a. limiting audit tests to read-only access to software and data. If read-only access is not available to obtain the necessary information, executing the test by an experienced administrator who has the necessary access rights on behalf of the auditor. b. if access is granted, establishing and verifying the security requirements (e.g. antivirus and patching) of the devices used for accessing the systems (e.g. laptops or tablets) before allowing the access. c. only allowing access other than read-only for isolated copies of system files, deleting them when the audit is completed, or giving them appropriate protection if there is an obligation to keep such files under audit documentation requirements. d. identifying and agreeing on requests for special or additional processing, such as running audit tools. e. running audit tests that can affect system availability outside business hours. f. monitoring and logging all access for audit and test purposes. 57 M6 Performance Evaluation and Improvement M6 Performance Evaluation and Improvement Objective To ensure that information security performance is measured, analyzed, evaluated and improved, where necessary. Performance indicator Compliance level achieved against the entity’s information security policy and objectives (e.g. by using the performance indicators suggested in this standard or the entity’s own performance indicators to produce a dashboard demonstrating compliance). M6.1 Performance Evaluation Policy Objective To maintain a performance evaluation policy outlining the approach to measure and evaluate the effectiveness of the information security of the entity. Performance Indicator Percentage of established KPIs that are actively measured and tracked. Automation Guidance Not Applicable Relevant Threats and Vulnerabilities • Lack of performance evaluation • Lack of improvement of information security management system

Ongoing performance monitoring and evaluation is one of the major contributors to overall effective and successful information security operations within any entity. Therefore, the entity should have an overall framework for its monitoring and performance measurement activities. These activities can have several sources of input: a. high-level performance evaluation activities, such as the performance indicators suggested for subfamilies in this standard. b. detailed performance evaluation activities, such as the performance indicators suggested for “risk-based applicable” controls. c. ongoing monitoring, which detects deviations and necessary corrections. d. incident reports, which indicate that one or more of the controls are not working as intended. 58 The performance evaluation policy should define how these different performance indicators are integrated within the entity to provide an overall picture of information security performance to management, and how the results of these performance measurement activities can be presented to management for decision-making. M6.2 Performance Evaluation Objective To ensure that information security performance is measured, analyzed and evaluated. Performance Indicator Percentage of all those non-conformities that have been detected and not resolved within the time frame planned. Automation Guidance There are tools available in the market that can help entities measure, analyze, and evaluate information security KPIs/KRIs. These tools have built-in workflows to fetch information about the defined KPIs/KRIs. They also have reporting dashboards for management to understand and visualize information security performance over time. Relevant Threats and Vulnerabilities • Non-compliance with controls of this standard • Under-performance of information security controls in place • Ineffective controls

The continual improvement the entity needs to apply to its information security controls (see also M6.3.2) needs to make use of the monitoring and performance measurement results to identify which areas require improvement. Therefore, these activities are key to keeping information security up to date and fit for the purpose of the entity’s requirements. The results of monitoring and review should be recorded and externally and internally reported as appropriate and should also be used as input to the review of the information security risk management policy (refer to M2.1.1). 59 The entity should develop a plan to execute the monitoring and performance measurement activities, including all of the topics mentioned in the sub-controls above. It can be helpful to have clear responsibilities and schedule to carry out the monitoring and measuring, and there should be an independent review function that ensures that this monitoring takes place. In addition to executing the monitoring and measurement activities, there is also a need to keep these activities up to date and effective, so all monitoring and performance evaluation activities should be subject to periodical reviews, as well as immediate updates if the situation requires that. The results of the monitoring and performance evaluation activities should be put into context with respect to: a. the information security policy (refer to M1.2.1). b. the information security risk management policy (refer to M2.1.1). c. management expectations with regards to information security and the overall internal context (refer to M1.1.1). d. external requirements for information security, e.g. by the Emirate, sector, or national. The methods selected for monitoring and performance measurement should produce consistent and comparable results to assist the entity in measuring performance over time.

Critical entities should also consider any other CSC’s relevant issuances, guidance, and activities in this regard. Internal audits are another important means, in addition to the performance measurements, to assess compliance with the “always applicable” controls of this standard, the entity’s own policies and procedures, and the applicable requirements from the entity’s Emirate, sector or national context. 60 The information security controls in place at the entity should be subject to independent internal audits at a pre- defined schedule. This type of auditing should not come as a surprise but should be planned in advance, and the auditor should provide an audit plan of the areas to be audited and people to be met, to ensure the audit does not disrupt the business processes more than necessary (see also the sub-controls above). The frequency of internal audits should be determined based on the following factors: a. the size and complexity of the entity b. the nature of the entity’s business c. the level of risk associated with the entity’s information assets d. the frequency of changes to the business or IT environment e. the results of previous audits As a general guideline, annual internal audits are recommended, but more frequent audits may be necessary for critical entities. One of the important concepts of internal audits is the independence of the internal auditor(s) carrying out the audits. If the necessary independence or expertise cannot be found within the entity, external resources can provide this service. If the entity uses external resources, care should be taken to ensure that the external resource have enough knowledge of the entity to successfully conduct the audit. Another important aspect of the internal audit is the entity’s reaction to its results. The results of the internal audits should be considered by the Information Security Committee (refer to M1.1.3), and it should be ensured that all findings of the audit are corrected in a timely manner. 61

The entity should have a clear action plan that describes how identified non-conformities will be addressed. This can take place in the Information Security Committee (refer to M1.1.3) and should be initiated and controlled by the Information Security Management or Leadership Team. Determine whether corrective action is justified based on evaluating the following considerations: a. whether it is a first or a repeat occurrence b. frequency and history of occurrences (repeated occurrences) c. seriousness of the impact d. the root cause for the non-conformity for which the following activities have to be performed: • Collect data. • Get expert advice. • Consult with vendors, partners, and associates. The corrective action(s) identified should be implemented within an appropriate timeframe and prioritized based on the risk treatment plan (see M2); delays should be avoided to reduce the negative effects of non-conformities to the information security in place at the entity. 64 It is also important to ensure that the implemented corrective actions achieve their intended objective and are effective. The review of the effectiveness of corrective actions can be done by the Information Security Committee, and the results should be documented.

Based on the results of monitoring and reviews, decisions should be made on how the information security in place, the controls, processes, policies, and procedures can be improved. These decisions should lead to improvements in the entity’s management of information security and its risk management culture. Continual improvement of information security can be done through the entity’s performance indicators and measurements, incident reports, training, reviews, and audits (refer to M6.1) and the subsequent modification of the entity’s processes, systems, resources, capability, and skills. Continual improvement is a very powerful concept and can help the entity ensure that its information security is up-to-date and suitable for its needs. 65 2.5 Technical controls T1 Information Asset Management T1 Information Asset Management Objective To ensure proper information classification and protection of organizational information and other associated assets. Performance indicator Percentage of information assets that are adequately classified and protected. T1.1 Information Asset Management Policy Objective To maintain an information asset management policy outlining the procedures to identify, classify, and handle information assets. Performance Indicator Extent of asset management policy enforcement across the entity. Automation Guidance Not Applicable Relevant Threats and Vulnerabilities • Incomplete asset inventory • Inconsistent classification of information assets • Unrestricted usage of removable media

The asset management policy provides a structure for the management of information assets (e.g. people, hardware, software, data, facilities, information etc.) from procurement to disposal. The policy can, for example, contain in addition to the required sub-controls: a. information assets classification scheme. b. classified assets security requirements, based on the classification levels. c. information handling, based on the classification levels. The asset management policy can be included as part of the general information security policy, in a single policy document, or can be represented by multiple policies reflecting the complex nature of certain entities. 66 T1.2 Responsibility for Assets Objective To achieve and maintain appropriate protection of the entity’s information assets. Performance Indicator Percentage of employees who have authorized access to information systems only after signing an acknowledgment that they have read and understood rules of behavior. Percentage of entity’s information assets without assigned owners or responsible parties. Automation Guidance As a pre-requisite for any automation to be used, entities should identify information assets and their owners and then decide and document which part of the entity and/or individuals are responsible for each component of the identified information asset (including information, software, and hardware, IT, etc.). The entity could use a tool to automate the following processes: • tracking of information asset inventory, • assignment of information assets ownership, • defining the right use of information assets. Some entities maintain asset inventories using specific commercial products dedicated to the task, or they use free solutions to track and then sweep the network periodically for new assets connected to it. In particular, when entities acquire new systems, they record the owner and features of each new asset, including its network interface Media Access Control (MAC) address and location. This mapping of asset attributes and owner-to-MAC address can be stored in a free or commercial database management system. Some entities also deploy a configuration management database (CMDB) which is a database that contains information about all the components of an organization's IT environment. It stores data about hardware, software, systems, and their relationships, known as Configuration Items (CIs). The entity should determine which asset attributes, based on entity’s needs, should be tracked. The following list of potential attributes could be considered: • Asset name • Asset type • Asset tag • IP address • MAC address • Serial number • Location, etc. Relevant Threats and Vulnerabilities • Use of unapproved hardware and / or devices • Use of counterfeit or copied software • Lack of acceptable use of information asset policy • Lack of updated information asset inventory 67

The entity should identify assets relevant in the lifecycle of information and document their importance. The lifecycle of information should include creation, processing, storage, transmission, deletion, destruction, and protection. Documentation should be done in dedicated or existing inventories as appropriate and includes asset data such as type of asset, location, backup information, related licenses, and its importance/ criticality. The asset inventory should be accurate, up to date, consistent, and aligned with other inventories, such as inventories in Enterprise Asset Management and Enterprise Resource Planning (ERP). Here is a list of inventory assets that might be considered including, but not limited to: Hardware - Server • laptops, workstations, storage, security devices (firewall, IDS / IPS, anti-spam, etc.). Network • routers, gateways, switches, Wireless Access Points, network segments (e.g. cabling and equipment between two computers), Others (SAT, Laser). People • Chief Technology / Information Director. • Information Technology Manager. • Database Development & Administration (manager, analyst, architect, administrator etc.). • Programming / Software Engineering (manager, engineer, programmer, tester etc.) • Back-office Applications. • Financial control, customer care, logistics, ERP, CRM, Email. Client Facing Applications • e-commerce, Internet Service Provisioning – Static, Public IP addresses, DNS services, Registration and management, Email service provisioning, and Web portals. Data and Information • customer personal data, customer financial data, entity’s employee personal and financial data. Facilities • headquarters, secondary premises, branch offices, offices, and data centers. The asset owner should be responsible for: a. ensuring that information and assets associated with information systems are appropriately identified, classified and maintained. 68 b. defining and periodically reviewing access restrictions and classifications, taking into account applicable access control policies. Ownership may be allocated based on: a. a business process. b. a defined set of activities. c. an application, or d. a defined set of data.

All employees, contractors and third-party users should follow rules for the acceptable use of information and assets associated with information systems, including rules for: a. usage of electronic mail, internet usages, and social media. b. usage of GenAI platforms such as ChatGPT. c. software and hardware usage. d. incident reporting. e. data protection and privacy. f. monitoring of user activities. g. guidelines for the use of mobile devices, especially for the use outside the premises of the entity. h. rules for protection of the device from unauthorized access (e.g. pin code). i. rules for storing and / or encrypting personal and entity information. j. clear separation of personal data and entity’s data. k. password management. l. following procedures for the proper handling, storage, and disposal of information. m. understanding individual accountability for actions taken on information systems. 69 Specific rules or guidance should be provided by the relevant management and should be based on the users’ role in the entity. Employees, contractors and third party users using or having access to the entity’s assets should be aware of the limits existing for their use of entity’s information and assets associated with information systems, and resources. They should be responsible for their use of any information processing resources, and of any such use carried out under their responsibility. Entity may consider specific acceptable use requirements for departments processing critical information such as information classified as ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’. Any device used outside the entity’s premises which stores or processes information (e.g. mobile device), including devices owned by the entity and devices owned privately and used on behalf of the entity [bring your own device (BYOD)] needs protection. The use of these devices should also be authorized by management. 70 T1.3 Information Protection Objective To ensure that information receives an appropriate level of protection. Performance Indicator Percentage of information assets that are correctly classified and handled. Automation Guidance Data classification and protection tools can be deployed by entities to automate and enable data classification and handling-related controls. A comprehensive data protection solution can manage and protect classified information. These tools automatically scan, identify, and categorize data based on its content and context, applying appropriate labels and security measures. By doing so, they significantly enhance data security, ensure regulatory compliance, and streamline data governance processes. Entities can more effectively control access to classified information, prevent data breaches, and make informed decisions about data handling and storage. Relevant Threats and Vulnerabilities • Tampering with information with no appropriate protection • Unauthorized access to information • Lack of information classification scheme • Lack of awareness around information classification and handling

Critical information infrastructure entities should also take into account any other CSC’s relevant issuances, guidance, and activities in this regard. Classification and associated protective controls for information should take account of business needs for sharing or restricting information, for protecting integrity of information and for assuring availability as well as legal requirements. Assets other than information can also be classified in conformance with classification of information, which is stored in, processed by or otherwise handled or protected by the asset. The classification can be determined by the level of impact that the information's compromise would have for the entity. Each level defined in the scheme should be given a name that makes sense in the context of the classification scheme’s application. The entity can consider below classification levels: 71 • Open: Data that is publicly shared and published online with minimal restrictions. This type of data is freely accessible to anyone, and there are no confidentiality or sensitivity concerns associated with its dissemination. Examples include public datasets, research publications, and published government statistics, public domain art data, job postings, marketing materials, press releases, product brochures, etc. Open data does not include personal identifiable information (PII) that can be used to identify a specific individual, either on its own or when combined with other data including direct identifiers (Full name, Passport number, Emirates ID, Email address, Phone number, Biometric data, Financial data, Medical records, Genetic information etc.) and indirect identifiers (Date of birth, Gender, Geolocation/ IP, Employment/ Education data, Financial transactions, Medical condition/ diagnosis etc.). • Confidential / Restricted: Data that is restricted and intended for access only by specific individuals or groups. Unauthorized access to Confidential/Restricted data could harm an entity or individual. This data includes non- sensitive personal information (e.g. name, job title, work email, office phone number, department, employee ID, work location), non-critical entity financial data (e.g. budget estimates, internal forecasts), employee records, financial information (e.g. bank account details, financial statements, tax filings), organizational business plans, internal policies & procedures, and supplier contracts. • Secret: Data that requires a higher level of protection due to the significant harm at national, Emirate or sectoral level that could result from unauthorized access or disclosure. Secret data may include sensitive personal and health information (e.g. medical history, biometric data), trade secrets and proprietary algorithms, source code for proprietary software, product design schematics and investment/ legal case strategies. • Top Secret: Data that is highly restricted and protected due to its critical importance. Unauthorized access or disclosure of Top Secret data could cause significant harm to national security or organizational integrity,. This category includes classified government documents, highly sensitive corporate or investment strategies, critical infrastructure details, intelligence reports, personal (including health and financial) information of high-ranking individuals, highly sensitive foreign policies and national defense plans. Classification provides people who deal with information a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in the group facilitate this. This approach reduces the need for case-by-case risk assessment and custom design of controls. Owners of information assets should be accountable for their classification. The scheme should be consistent across the whole entity and included in its procedures 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. The classification scheme used within the entity can be different from the schemes used by other entities, even if the names for levels are similar. In addition, information moving between entities can vary in classification depending on its context in each entity, even if their classification schemes are identical. Therefore, agreements with other entities that include information sharing should include procedures to identify the classification of that information and to interpret the classification levels from other entities. Correspondence between different schemes can be determined by looking for equivalence in the associated handling and protection methods.

Procedures for information labeling should cover information and its related assets in physical and electronic formats. The labeling should reflect the classification scheme established in T1.3.1. The labels should be easily recognizable. Labeling procedures should give guidance where and how labels are attached in consideration of how the information is accessed or the assets are handled. The procedures can define: a. cases where labeling is omitted (e.g. labeling of open information to reduce workloads). b. how to label information sent by or stored on electronic or physical means, or any other format. c. how to handle cases where labeling is not possible (e.g. due to technical restrictions). Examples of labeling techniques include: a. physical labels. b. headers and footers. c. metadata. d. watermarking. e. rubber-stamps. Digital information should utilize metadata in order to identify, manage and control information, especially with regard to confidentiality. Metadata should also enable efficient and correct searching for information. Metadata should facilitate systems to interact and make decisions based on the associated classification labels. The procedures should describe how to attach metadata to information, what labels to use and how data should be handled, in line with the entity’s information model and ICT architecture. Relevant additional metadata should be added by systems when they process information depending on its information security properties. Personnel and other interested parties should be made aware of labelling procedures. All personnel should be provided with the necessary training to ensure that information is correctly labelled and handled accordingly. Output from systems containing information that is classified as being ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ should carry an appropriate classification label in the output.

73 Critical entities should also take into account any other CSC’s relevant issuances, guidance, and activities in this regard. Procedures should be drawn up for handling, processing, storing and communicating information consistent with its classification. The following items should be considered: a. access restrictions supporting the protection requirements for each level of classification. b. maintenance of a formal record of the authorized recipients of information and other associated assets. c. protection of temporary or permanent copies of information to a level consistent with the protection of the original information. d. "Confidential/Restricted”, or ‘Secret’ or ‘Top Secret’ information and related assets should be stored and managed within the applicable legal jurisdiction and geographical boundaries of the United Arab Emirates. e. authorization of disposal of information and other associated assets and supported deletion method(s). f. handling of all storage media to the indicated classification level of the information stored on it. g. clear marking of all copies of storage media (electronic or physical) for the attention of the authorized recipient.

Removable storage media such as optical discs (Blu-ray discs, DVDs, CDs), memory cards (CompactFlash card, Secure Digital card, Memory Stick), floppy disks / zip disks, disk packs, and magnetic tapes, are typically found in scanners, copiers, printers, notebook computers, workstations, network components, and mobile devices. The following guidelines for the management of removable storage media should be considered: a. removable media drives should only be enabled if there is a business reason for doing so. b. all procedures and authorization levels should be documented. c. registration of removable media should be considered to limit the opportunity for data loss. d. prevent content auto-run on laptops, workstations, and servers for removable media. e. all media should be stored in a safe, secure environment, in accordance with manufacturers’ specifications. f. if data confidentiality or integrity are important considerations, cryptographic techniques should be used to protect data on removable media. g. multiple copies of valuable data should be stored on separate media to further reduce the risk of coincident data damage or loss. h. to mitigate the risk of media degrading while stored data are still needed, the data should be transferred to fresh media before it gets unreadable. i. where necessary and practical, authorization should be required for media removed from the entity and a record of such removals should be kept in order to maintain an audit trail. 79 j. if no longer required, the contents of any re-usable media that are to be removed from the entity should be made unrecoverable; data wiping software could be used.

Formal procedures for the secure reuse or disposal of media should be established to minimize the risk of classified information leakage to unauthorized persons. The procedures for secure reuse or disposal of media containing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information should be proportional to the classification of that information. The following items should be considered: a. if storage media containing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information needs to be reused within the entity, ensure the data is securely deleted or the storage media is properly formatted before reuse. b. storage media containing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information should be stored and disposed of securely and safely, e.g. by incineration or shredding, or erased of data for use by another application within the entity. c. procedures should be in place to identify the items that might require secure disposal. d. many entities offer collection and disposal services for media; care should be taken in selecting a suitable external party with adequate controls and experience. e. disposal of sensitive items should be logged where possible in order to maintain an audit trail. f. when accumulating media for disposal, consideration should be given to the aggregation effect, which may cause a large quantity of open information to become ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’. A risk assessment should be performed on damaged devices containing sensitive data to determine whether the items should be physically destroyed rather than sent for repair or discarded. 80 T1.5 User Endpoint Devices Objective To protect information against the risks introduced by using user endpoint devices. Performance Indicator Percentage of mobile devices given access to company resources without any MDM solution. Percentage of endpoint devices that have full disk encryption enabled. Automation Guidance Entities can use Endpoint Detection and Response (EDR) solutions to bolster their cyber security. EDR tools monitor endpoints, detect threats in real-time, and respond automatically to potential breaches. They use advanced analytics to identify suspicious activities, allowing organizations to quickly investigate and mitigate threats, thus reducing the risk of data breaches and minimizing downtime. Entities can use Mobile Device Management (MDM) systems to manage and secure mobile devices in their networks. MDM provides a centralized platform for configuring, monitoring, and securing smartphones, tablets, and laptops. It allows enforcement of security policies, application deployment, and remote data wiping. MDM helps organizations improve productivity, reduce security risks, and maintain compliance with data protection requirements. Relevant Threats and Vulnerabilities • Lack of policy enforcement on endpoints • Insecure devices accessing company resources

The entity should develop, document, and disseminate the following documents to defined personnel or roles: a. a physical and environmental security policy that addresses the purpose, scope, roles, responsibilities, management commitment, coordination to achieve appropriate physical protection among organizational entities, and compliance. b. procedures to facilitate the implementation of the physical and environmental security policy and associated physical and environmental protection controls. c. requirements for physical and environmental security assessments to ensure that controls are adequately implemented. The entity should ensure that the physical and environmental security policy and all supporting procedures are periodically reviewed and updated. This policy can be included as part of the general information security policy, in a single policy document, or can be represented by multiple policies reflecting the complex nature of certain entities. 83 T2.2 Secure Areas Objective To prevent unauthorized physical access, damage, and interference to the entity’s premises and information. Performance Indicator Percentage of resolved/closed corrective items identified from periodic physical security site surveys. Percentage of physical access reviews conducted as per the defined frequency. Automation Guidance Automated physical access management applications are available for entities of all sizes and complexity and are deployed along with physical access control equipment (such as automated gates and doors). Selection of the appropriate physical access management solution requires an entity to have an understanding of its physical landscape and locations, the risks it faces, and the protection level required. Relevant Threats and Vulnerabilities • Under protected secure areas • Unauthorized access to secure areas • Destruction of equipment of media • Interference with security controls

The following guidelines should be considered and implemented where appropriate for physical security perimeters: a. security perimeters should be clearly defined, and the siting and strength of each of the perimeters should depend on the security requirements of the assets within the perimeter and the results of a risk assessment. b. perimeters of a building or site containing information systems should be physically sound (i.e. there should be no gaps in the perimeter or areas where a break-in could easily occur); the external walls of the site should be of solid construction and all external doors should be suitably protected against unauthorized access with control mechanisms, e.g. bars, alarms, locks etc.; doors and windows should be locked when unattended and external protection should be considered for windows, particularly at ground level. c. a manned reception area or other means to control physical access to the site or building should be in place; access to sites and buildings should be restricted to authorized personnel only. d. physical barriers (such as turnstiles, card-controlled entry gates) should, where applicable, be built to prevent unauthorized physical access and environmental contamination. 84 e. 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 national, and international standards; they should operate in accordance with local fire code in a failsafe manner. f. suitable intruder detection systems should be installed to national or international standards and regularly tested to cover all external doors and accessible windows; unoccupied areas should be alarmed at all times; cover should also be provided for other areas, e.g. computer room or communications rooms. Entities should consider establishing a physical security team to manage and enforce security measures. The team’s key responsibilities should include: a. conducting physical security risk assessments and ensuring physical security perimeters are adequately defined and maintained. b. managing access control systems and ensuring authorized personnel access to restricted areas. c. monitoring and maintaining surveillance systems (e.g. CCTV, motion detectors). d. responding to physical security incidents and breaches. e. ensuring regular testing and maintenance of physical security measures (e.g. alarms, locks, barriers). f. providing training and awareness on physical security procedures.

The following guidelines should be considered: a. the date and time of entry and departure of visitors should be recorded, and all visitors should be supervised unless their access has been previously approved; they 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. b. access to areas where ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information is processed or stored should be controlled and restricted to authorized persons only; authentication controls (e.g. access control card plus PIN) should be used to authorize and validate all access; an audit trail of all access should be securely maintained. 85 c. all employees, contractors and third-party users and all visitors should be required to wear some form of visible identification and should immediately notify security personnel if they encounter unescorted visitors and anyone not wearing visible identification. d. third party support service personnel should be granted restricted access to secure areas or ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information systems only when required; this access should be authorized and monitored. e. access rights to secure areas should be regularly reviewed and updated and revoked when necessary. The following guidelines should be considered for delivery and loading areas and incoming material: a. access to delivery and loading area from outside of the building should be restricted to identified and authorized personnel. b. the delivery and loading area should be designed so that supplies can be unloaded without delivery personnel gaining access to other parts of the building. c. the external doors of a delivery and loading area should be secured when the internal doors are opened. d. incoming material should be inspected and registered for potential threats before this material is moved from the delivery and loading area to the point of use. e. incoming material should be registered on entry to the site. f. incoming and outgoing shipments should be physically segregated, where possible. g. Incoming deliveries should be inspected for evidence of tampering during transit. If tampering is discovered, it should be immediately reported to security personnel.

The following guidelines should be considered to secure offices, rooms, and facilities: a. relevant health and safety and standards should be accounted for. b. access by the public should be restricted to key information processing facilities. c. where applicable, information processing facilities 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. 86

Consideration should be given to any security threats presented by neighboring premises, e.g. a fire in a neighboring building, water leaking from the roof or in floors below ground level or an explosion in the street. Risk assessments to identify the potential consequences of physical and environmental threats should be performed prior to beginning critical operations at a physical site, and at regular intervals. Necessary safeguards should be implemented and changes to threats should be monitored. Specialist advice should be obtained on how to manage risks arising from physical and environmental threats such as fire, flood, earthquake, explosion, civil unrest, toxic waste, environmental emissions and other forms of natural disasters or disasters caused by human beings. Physical premises location and construction should take account of: a. local topography, such as appropriate elevation, bodies of water and tectonic fault lines. b. urban threats, such as locations with a high profile for attracting political unrest, criminal activity or terrorist attacks. Based on risk assessment results, relevant physical and environmental threats should be identified, and appropriate controls considered in the following contexts as examples: a. Fire: hazardous or combustible materials should be stored at a safe distance from a secure area. Bulk supplies such as stationery should not be stored within a secure area. Installing and configuring systems able to detect fires at an early stage to send alarms or trigger fire suppression systems in order to prevent fire damage to storage media and to related information processing systems. Fire suppression should be performed using the most appropriate substance concerning the surrounding environment (e.g. gas in confined spaces). b. Flooding: installing systems able to detect flooding at an early stage under the floors of areas containing storage media or information processing systems. Water pumps or equivalent means should be readily made available in case flooding occurs. c. Electrical surges: adopting systems able to protect both server and client information systems against electrical surges or similar events to minimize the consequences of such events. d. Explosives and weapons: performing random inspections for the presence of explosives or weapons on personnel, vehicles or goods entering information processing facilities. e. Fallback equipment and backup media should be sited at a safe distance to avoid damage from a disaster affecting the main site. Entities should maintain thorough documentation and evidence to demonstrate the steps taken to evaluate and address physical security risks. This should include records of security assessments, risk mitigation measures, policy reviews, and corrective actions. All relevant evidence should be readily accessible for review to ensure compliance with security standards and regulations. 87

Secure areas are designated physical spaces within an entity that house information processing facilities or sensitive data and are protected by a set of controls designed to prevent unauthorized access and mitigate the risk of data breaches. These areas may include server rooms, data centers, network equipment rooms, and other locations where critical systems and information assets are stored or processed. The following guidelines should be considered for the protection: a. personnel should only be aware of the existence of, or activities within, a secure area on a need-to-know basis. b. unsupervised working in secure areas should be avoided both for safety reasons and to prevent opportunities for malicious activities. c. vacant secure areas should be physically locked and periodically checked. d. photographic, video, audio or other recording equipment, such as cameras in mobile devices, should not be allowed, unless authorized. e. make sure all personnel accessing secure areas is aware of rules and guidelines. f. emergency procedures should be posted in a readily visible or accessible manner. The arrangements for working in secure areas include controls for the employees, contractors and third-party users working in the secure area, as well as other third-party activities taking place there. Physical premises should be monitored by surveillance systems, which can include guards, intruder alarms, video monitoring systems such as closed-circuit television and physical security information management software either managed internally or by a monitoring service provider. Access to buildings that house critical systems should be continuously monitored to detect unauthorized access or suspicious behavior by: a. installing video monitoring systems such as closed-circuit television to view and record access to sensitive areas within and outside an entity’s premises. b. installing, according to relevant applicable standards, and periodically testing contact, sound or motion detectors to trigger an intruder alarm such as: • installing contact detectors that trigger an alarm when a contact is made or broken in any place where a contact can be made or broken (such as windows and doors and underneath objects) to be used as a panic alarm. • motion detectors based on infra-red technology which trigger an alarm when an object passes through their field of view. • installing sensors sensitive to the sound of breaking glass which can be used to trigger an alarm to alert security personnel. 88 c. using those alarms to cover all external doors and accessible windows. Unoccupied areas should be alarmed at all times; cover should also be provided for other areas (e.g. computer or communications rooms). The design of monitoring systems should be kept confidential because disclosure can facilitate undetected break- ins. Monitoring systems should be protected from unauthorized access in order to prevent surveillance information, such as video feeds, from being accessed by unauthorized persons or systems being disabled remotely. The alarm system control panel should be placed in an alarmed zone and, for safety alarms, in a place that allows an easy exit route for the person who sets the alarm. The control panel and the detectors should have tamperproof mechanisms. The system should regularly be tested to ensure that it is working as intended, particularly if its components are battery powered. Any monitoring and recording mechanism should be used taking into consideration local laws and regulations including data protection and PII protection legislation, especially regarding the monitoring of personnel and recorded video retention periods. Where third party providers are used to provision information processing facilities, the entity should ensure that the requirements are communicated to the third party providers, documented in formal contractual agreements and implemented. The entity should ensure continuous monitoring to verify compliance with these requirements. This includes conducting regular audits, real-time monitoring, and performing risk assessments. Additionally, any security incidents should be promptly reported and addressed, with clear performance metrics set to measure compliance and service quality. 89 T2.3 Equipment Security Objective To prevent loss, damage, theft or compromise of assets and interruption to the entity’s activities. Performance Indicator Percentage of performed checks that revealed unauthorized movement of information assets or other information security-related issues. Percentage of planned maintenance activities for supporting utilities that were not completed as scheduled. Automation Guidance Solutions such as physical access control, video surveillance, and anti-intrusion systems should be considered. Relevant Threats and Vulnerabilities • Equipment failure • Tampering with equipment • Physical theft of information asset

The following guidelines should be considered to protect equipment: a. equipment should be sited to minimize unnecessary access into work areas. b. information systems handling ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ data should be positioned carefully to reduce the risk of information being viewed by unauthorized persons during their use. c. storage facilities storing the equipment should be secured to avoid unauthorized access. d. items requiring special protection should be safeguarded to reduce the general level of protection required. e. 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. f. guidelines for eating, drinking and smoking in proximity to information systems should be established, e.g. environmental conditions, such as temperature and humidity, should be monitored for conditions, which could adversely affect the operation of information systems. g. lightning protection should be applied to all buildings and lightning protection filters should be fitted to all incoming power and communications lines. h. the use of special protection methods, such as keyboard membranes, should be considered for equipment in industrial environments. i. equipment processing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information should be protected to minimize the risk of information leakage due to electromagnetic emanation. 90

Supporting utilities (e.g. electricity, telecommunications, water supply, natural gas, sewage, heating ventilation and air conditioning) should: a. conform to equipment manufacturer’s specifications and local legal requirements. b. be appraised regularly for their capacity to meet business growth and interactions with other supporting utilities. c. be inspected and tested regularly to ensure their proper functioning. d. if necessary, be alarmed to detect malfunctions. e. if necessary, have multiple feeds with diverse physical routing. f. ensure equipment supporting the utilities is on a separate network from the information processing facilities if connected to a network. g. ensure equipment supporting the utilities is connected to the internet only when needed and only in a secure manner. Emergency lighting and communications should be provided. Emergency switches and valves to cut off power, water, natural gas or other utilities should be located near emergency exits and/or equipment rooms.

The following guidelines for cabling security should be considered: a. power and telecommunications lines into information systems should be underground, where possible, or subject to adequate alternative protection. b. power cables should be segregated from communications cables to prevent interference. c. for sensitive or critical systems further controls to consider include: 91 • 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. • controlled access to patch panels and cable rooms. d. labelling cables at each end with sufficient source and destination details to enable the physical identification and inspection of the cable.

The following guidelines for equipment maintenance should be considered: a. equipment should be maintained in accordance with the supplier’s recommended service intervals and specifications. b. implementation and monitoring of the maintenance program should be done by the entity. c. only authorized maintenance personnel should carry out repairs and service equipment. d. records should be kept of all suspected or actual faults, and of all preventive and corrective maintenance. e. appropriate controls should be implemented when equipment is scheduled for maintenance, taking into account whether this maintenance is performed by personnel on site or external to the entity; where necessary, ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information should be cleared from the equipment, or the maintenance personnel should be sufficiently cleared. f. maintenance personnel should be supervised when carrying out maintenance on site. g. the entity should authorize and control access for remote maintenance. h. security measures should be applied for assets off-premises, if equipment containing information is taken off premises for maintenance. i. all maintenance requirements imposed by insurance policies should be complied with. j. before putting equipment back into operation after its maintenance, the entity should ensure that the equipment has not been tampered with and/or does not malfunction. k. measures for secure disposal or re-use of equipment should be applied if it is determined that equipment is to be disposed of. 92

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 entity and those owned privately and used on behalf of the entity. The following guidelines should be considered for the protection of off-site equipment: a. equipment and media taken off the premises should not be left unattended in public places; portable computers should be carried as hand luggage and disguised where possible when travelling. b. manufacturers’ instructions for protecting equipment should be observed at all times, e.g. protection against exposure to strong electromagnetic fields, water, heat, humidity, dust etc. c. controls for off-premise 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. d. 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 entities of those who are responsible for the equipment. e. where necessary and practical, requiring authorization for equipment and media to be removed from the entity’s premises and keeping a record of such removals to maintain an audit trail. f. protecting against viewing information on a device (e.g. mobile or laptop) on public transport, and the risks associated with shoulder surfing. g. implementing location tracking and the ability for remote wiping of devices. The entity should adopt a risk assessment-based approach for identifying cyber security requirements for international travel, such as permitting the cross-border movement of organization devices and information assets, the provision of dedicated “loaner devices”, temporary limitation or enhanced monitoring of access, or tailored awareness packages for individuals who may be traveling to high risk environments. Permanent installation of equipment outside the entity’s premises [such as antennas and automated teller machines (ATMs)] can be subject to higher risk of damage, theft, or eavesdropping. These risks can vary considerably between locations and should be considered in determining the most appropriate measures. The following guidelines should be considered when siting this equipment outside of the entity’s premises: a. physical security monitoring. b. protecting against physical and environmental threats. c. physical access and tamper-proofing controls. d. logical access controls. Risks, e.g. damage, theft, or eavesdropping, may vary considerably between locations and should be taken into account in determining the most appropriate controls. 93

(for information purpose only) Equipment should be verified to ensure whether storage media is contained or not prior to disposal or re-use. Storage media containing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information should be physically destroyed, or the information should be destroyed, deleted or overwritten using techniques to make the original information non-retrievable rather than using these delete or format functions. Labels and markings identifying the entity or indicating the classification, owner, system or network, should be removed prior to disposal, including reselling or donating to charity. The entity should consider the removal of security controls such as access controls or surveillance equipment at the end of the lease or when moving out of the premises. This depends on factors such as: a. its lease agreement to return the facility to its original condition. b. minimizing the risk of leaving systems with ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information on them for the next tenant (e.g. user access lists, video or image files). c. the ability to reuse the controls at the next facility.

The clear desk and clear screen policy should take into account the information classifications, legal and contractual requirements and the corresponding risks and cultural aspects of the entity. The following guidelines should be considered: a. ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ business information (e.g. on paper, flipcharts, white boards 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. 94 b. 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. c. unauthorized use of photocopiers and other reproduction technology (e.g. scanners, digital cameras) should be prevented. d. media containing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ or classified information should be removed from printers immediately. e. protecting user endpoint devices by key locks or other security means when not in use or unattended. f. securely storing documents and removable storage media containing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information and, when no longer required, discarding them using secure disposal mechanisms. g. establishing and communicating rules and guidance for the configuration of pop-ups on screens (e.g. turning off the new email and messaging pop-ups, if possible, during presentations, screen sharing or in a public area). h. clearing ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information on whiteboards and other types of display when no longer required. 95 T3 Operations Management T3 Operations Management Objective To ensure the effective operational control of the security functions related to information and information systems. Performance indicator Frequency of operational failures leading to information security incidents. T3.1 Operational Procedures and Responsibilities Objective To ensure the correct and secure operation of information systems. Performance Indicator Percentage of information systems that meet all operational information security requirements. Automation Guidance The entity can develop a series of system images and secure storage servers for hosting these standard images. Commercial and/or free configuration management tools can then be employed to measure the settings operating system and applications of managed machines to look for deviations from these image configurations used by the entity. ITSM tools can also be leveraged by entities to automate and streamline IT processes, including change management, incident management, problem management, and service request fulfillment. Anti-malware tools can also be leveraged by entities to automate and enhance security processes, including threat detection, malware analysis, incident response, and vulnerability management. Backup tools can also be leveraged by entities to automate and streamline data protection processes, including data backup, recovery, integrity checks, and disaster recovery planning. Relevant Threats and Vulnerabilities • Unauthorized processing of data • Abuse of system access/privileges • Equipment malfunction • Ransomware Attacks • Zero-day exploits • Unpatched software

96 The entity should define and implement processes and tools to enforce the defined configurations (including security configurations) for hardware, software, services (e.g. cloud services) and networks, for newly installed systems as well as for operational systems over their lifetime. Roles, responsibilities, and procedures should be in place to ensure satisfactory control of all configuration changes. Standard templates for the secure configuration of hardware, software, services, and networks should be defined: a. considering the level of protection needed in order to determine a sufficient level of security. b. using publicly available guidance (e.g. vendor recommended security configuration and from independent security entities). c. supporting the entity’s information security policy, topic-specific policies, standards and other security requirements. d. considering the feasibility and applicability of security configurations in the entity’s context. The templates should be reviewed periodically and updated when new threats or vulnerabilities need to be addressed, or when new software or hardware versions are introduced. The following should be considered for establishing standard templates for the secure configuration of hardware, software, services, and networks: a. minimizing the number of identities with privileged or administrator level access rights. b. disabling unnecessary, unused, or insecure identities. c. disabling or restricting unnecessary functions and services. d. restricting access to powerful utility programs and host parameter settings. e. synchronizing clocks. f. changing vendor default authentication information such as default passwords immediately after installation and reviewing other important default security-related parameters. g. invoking time-out facilities that automatically logs off computing devices after a predetermined period of inactivity. h. verifying that license requirements have been met. Established configurations of hardware, software, services, and networks should be recorded and a log should be maintained of all configuration changes. These records should be securely stored. This can be achieved in various ways, such as configuration databases or configuration templates. Changes to configurations should follow the change management process. Configuration records can contain as relevant: a. up-to-date owner or point of contact information for the asset. b. date of the last change of configuration. c. version of configuration template. d. relation to configurations of other assets. Configurations should be monitored with a comprehensive set of system management tools (e.g. maintenance utilities, remote support, enterprise management tools, backup and restore software) and should be reviewed on a regular basis to verify configuration settings, evaluate password strengths, and assess activities performed. Actual configurations can be compared with the defined target templates. Any deviations should be addressed, either by automatic enforcement of the defined target configuration or by manual analysis of the deviation followed by corrective actions. 97

106 The entity should define events that need to be captured, the frequency of audit log reviews, and retention requirements for audit logs. The entity should determine the purpose for which logs are created, what data is collected and logged, and any log-specific requirements for protecting and handling the log data. This should be documented in a topic-specific policy on logging. Monitoring procedures should be developed, detailing the steps of the monitoring, the response actions and how the monitoring process feeds into the incident response process. Clear responsibilities should be assigned for the personnel performing monitoring. Each addition/ change of systems in the environment should be considered for the amendment of the monitoring policy and procedures, to ensure they properly cover the updated environment.

Event logs should include for each event, as applicable: a. user IDs. b. system activities. c. dates, times, and details of relevant events (e.g. log-on and log-off). d. device identity, system identifier and location. e. network addresses and protocols. f. The following events should be considered for logging: g. successful and rejected system access attempts. h. successful and rejected data and other resource access attempts. i. changes to system configuration. j. use of privileges. k. activities performed by the privileged users l. use of utility programs and applications. m. files accessed and the type of access, including deletion of important data files. n. alarms raised by the access control system. o. activation and de-activation of security systems, such as anti-virus systems and intrusion detection systems. 107 p. creation, modification, or deletion of identities. q. transactions executed by users in applications. In some cases, the applications are a service or product provided or run by a third party. It is important for all systems to have synchronized time sources as this allows for correlation of logs between systems for analysis, alerting and investigation of an incident. Special attention should be given to system administrator and operator logs. These should be reviewed on a regular basis. Fault Logging enables systems to log and report faults (problems, errors or failures) related to information processing or communications. Faults reported by users or by system programs should be logged. There should be clear rules for handling reported faults including: a. review of fault logs to ensure that faults have been satisfactorily resolved. b. review of corrective measures to ensure that controls have not been compromised, and that the action taken is fully authorized. Protection of logs Users, including those with privileged access rights, should not have permission to delete or de-activate logs of their own activities. They can potentially manipulate the logs on information processing facilities under their direct control. Therefore, it is necessary to protect and review the logs to maintain accountability for the privileged users. Controls should aim to protect against unauthorized changes to log information and operational problems with the logging facility including: a. alterations to the message types that are recorded. b. log files being edited or deleted. c. failure to record events or over-writing of past recorded events if the storage media holding a log file is exceeded. For protection of logs, the use of the following techniques should be considered: cryptographic hashing, recording in an append-only and read-only file, recording in a public transparency file. Some audit logs can be archived because of requirements on data retention or requirements to collect and retain evidence. Where the entity needs to send system or application logs to a vendor to assist with debugging or troubleshooting errors, logs should be de-identified where possible using data masking techniques for information such as usernames, internet protocol (IP) addresses, hostnames, or entity name, before sending to the vendor. Event logs can contain ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ data and personally identifiable information. Appropriate privacy protection measures should be taken. Log retention The entity should retain the logs for minimum of one year. Entity may denote retention period for logs based on applicable legal and/or regulatory requirements and based on business need. Log analysis Log analysis should cover the analysis and interpretation of information security events, to help identify unusual activity or anomalous behavior, which can represent indicators of compromise. Analysis of events should be performed by taking into account: a. the necessary skills for the experts performing the analysis. b. determining the procedure of log analysis. 108 c. the required attributes of each security-related event. d. exceptions identified through the use of predetermined rules [e.g. security information and event management (SIEM) or firewall rules, and intrusion detection systems (IDSs) or malware signatures.] e. known behavior patterns and standard network traffic compared to anomalous activity and behavior [user and entity behavior analytics (UEBA)]. f. results of trend or pattern analysis (e.g. as a result of using data analytics, big data techniques and specialized analysis tools). g. available threat intelligence. Log analysis should be supported by specific monitoring activities to help identify and analyze anomalous behavior, which includes: a. reviewing successful and unsuccessful attempts to access protected resources [e.g. domain name system (DNS) servers, web portals and file shares]. b. checking DNS logs to identify outbound network connections to malicious servers, such as those associated with botnet command and control servers. c. examining usage reports from service providers (e.g. invoices or service reports) for unusual activity within systems and networks (e.g. by reviewing patterns of activity). d. including event logs of physical monitoring such as entrance and exit to ensure more accurate detection and incident analysis. e. correlating logs to enable efficient and highly accurate analysis. Suspected and actual information security incidents should be identified (e.g. malware infection or probing of firewalls) and be subject to further investigation (e.g. as part of an information security incident management process). Ensure continuous monitoring for relevant activities and other related events arising or related to any suspected events.

The monitoring scope and level should be determined in accordance with business and information security requirements and taking into consideration relevant laws and regulations. Monitoring records should be maintained for defined retention periods. 109 The following should be considered for inclusion within the monitoring system: a. outbound and inbound network, system, and application traffic. b. access to systems, servers, networking equipment, monitoring system, critical applications, etc. c. critical or admin level system and network configuration files. d. logs from security tools [e.g. antivirus, IDS, intrusion prevention system (IPS), web filters, firewalls, data leakage prevention]. e. event logs relating to system and network activity. f. checking that the code being executed is authorized to run in the system and that it has not been tampered with (e.g. by recompilation to add additional unwanted code). g. use of the resources (e.g. CPU, hard disks, memory, bandwidth) and their performance. The entity should establish a baseline of normal behavior and monitor against this baseline for anomalies. When establishing a baseline, the following should be considered: a. reviewing utilization of systems at normal and peak periods. b. usual time of access, location of access, frequency of access for each user or group of users. The monitoring system should be configured against the established baseline to identify anomalous behavior, such as: a. unplanned termination of processes or applications. b. activity typically associated with malware or traffic originating from known malicious IP addresses or network domains (e.g. those associated with botnet command and control servers). c. known attack characteristics (e.g. denial of service and buffer overflows). d. unusual system behavior (e.g. keystroke logging, process injection and deviations in use of standard protocols). e. bottlenecks and overloads (e.g. network queuing, latency levels and network jitter). f. unauthorized access (actual or attempted) to systems or information. g. unauthorized scanning of business applications, systems, and networks. h. successful and unsuccessful attempts to access protected resources (e.g. DNS servers, web portals and file systems). i. unusual user and system behavior in relation to expected behavior. Security monitoring can be enhanced by: a. leveraging threat intelligence systems. b. leveraging machine learning and artificial intelligence capabilities. c. using blocklists or allowlists. d. undertaking a range of technical security assessments (e.g. vulnerability assessments, penetration testing, cyberattack simulations and cyber response exercises), and using the results of these assessments to help determine baselines or acceptable behavior. e. using performance monitoring systems to help establish and detect anomalous behavior. f. leveraging logs in combination with monitoring systems. 110 Continuous monitoring via a monitoring tool should be used. Monitoring should be done in real time or at periodic intervals, subject to organizational need and capabilities. Monitoring tools should include the ability to handle large amounts of data, adapt to a constantly changing threat landscape, and allow for real-time notification. The tools should also be able to recognize specific signatures and data or network or application behavior patterns. CSC has also defined Security Operations Centre (SOC) Baseline Capabilities that provides the mandatory minimum level of maturity for SOCs across each identified Critical Information Infrastructure sector. It further outlines the security capabilities that must be present and integrated across the monitored environment and should be adopted across the CII in the UAE. The framework also specifies the guidance for implementation of the security capabilities of a SOC and can be used to evaluate the compliance of each individual entity to the requirements. Automated monitoring software should be configured to generate alerts (e.g. via management consoles, email messages or instant messaging systems) based on predefined thresholds. The alerting system should be tuned and trained on the entity’s baseline to minimize false positives. Personnel should be dedicated to respond to alerts and should be properly trained to accurately interpret potential incidents. There should be redundant systems and processes in place to receive and respond to alert notifications. Abnormal events should be communicated to relevant parties in order to improve the following activities: auditing, security evaluation, vulnerability scanning and monitoring. Procedures should be in place to respond to positive indicators from the monitoring system in a timely manner, in order to minimize the effect of adverse events on information security. Procedures should also be established to identify and address false positives including tuning the monitoring software to reduce the number of future false positives.

External and internal requirements for time representation, reliable synchronization and accuracy should be documented and implemented. Such requirements can be from legal, statutory, regulatory, contractual, standards and internal monitoring needs. A standard reference time for use within the entity should be defined and considered for all systems, including building management systems, entry and exit systems and others that can be used to aid investigations. A clock linked to a radio time broadcast from a national atomic clock or global positioning system (GPS) should be used as the reference clock for logging systems; a consistent, trusted date and time source to ensure accurate timestamps. Protocols such as network time protocol (NTP) or precision time protocol (PTP) with security enhancement like Network Time Security (NTS) or more advanced measures, should be used to keep all networked systems in synchronization with a reference clock. The entity can use two external time sources at the same time in order to improve the reliability of external clocks, and appropriately manage any variance. 111 Clock synchronization can be difficult when using multiple cloud services or when using both cloud and on-premises services. In this case, the clock of each service should be monitored, and the difference recorded in order to mitigate risks arising from discrepancies. 112 T3.3 Threat and Vulnerability Management Objective To provide awareness of the threat environment and mitigate risks from the exploitation of published or identified technical vulnerabilities. Performance Indicator Percentage of identified vulnerabilities mitigated within the acceptable time periods as defined in security requirements. Automation Guidance A large number of vulnerability scanning tools are available to evaluate the security configuration of systems. Some entities have also found commercial services using remotely managed scanning appliances to be effective. To help standardize the definitions of discovered vulnerabilities in multiple departments of an entity or even across entities it is preferable to use vulnerability scanning tools that measure security flaws and map them to vulnerabilities and issues categorized using one or more of the following industry-recognized vulnerability, configuration, and platform classification schemes and languages: CVE, CCE, OVAL, CPE, CVSS, and/ or XCCDF. Advanced vulnerability scanning tools can be configured with user credentials to log in to scanned systems and perform more comprehensive. The entity can deploy threat intelligence tools to proactively identify, analyze, and mitigate potential security threats. These tools collect and process data from various sources, including open sources, dark web forums, and internal network logs, to provide actionable insights on emerging threats Relevant Threats and Vulnerabilities • Exploitation of Unpatched Vulnerabilities • Increased Attack Surface • Data Breaches • Exposure to zero-day vulnerabilities

Information about existing or emerging threats is collected and analyzed in order to: a. facilitate informed actions to prevent the threats from causing harm to the entity. b. reduce the impact of such threats. Threat intelligence can be divided into three layers, which should all be considered: a. strategic threat intelligence: exchange of high-level information about the changing threat landscape (e.g. types of attackers or types of attacks). b. tactical threat intelligence: information about attacker methodologies, tools and technologies involved. c. operational threat intelligence: details about specific attacks, including technical indicators. 113 Threat intelligence should be: a. relevant (i.e. related to the protection of the entity). b. insightful (i.e. providing the entity with an accurate and detailed understanding of the threat landscape). c. contextual, to provide situational awareness (i.e. adding context to the information based on the time of events, where they occur, previous experiences and prevalence in similar entities). d. actionable (i.e. the entity can act on information quickly and effectively). Threat intelligence activities should include: a. establishing objectives for threat intelligence production. b. identifying, vetting, and selecting internal and external information sources that are necessary and appropriate to provide information required for the production of threat intelligence. c. collecting information from selected sources, which can be internal and external. d. processing information collected to prepare it for analysis (e.g. by translating, formatting or corroborating information). e. analyzing information to understand how it relates and is meaningful to the entity. f. communicating and sharing it to relevant individuals in a format that can be understood. Threat intelligence should be analyzed and used to enhance the security controls of an entity: a. by implementing processes to include information gathered from threat intelligence sources into the entity’s information security risk management processes. b. as an additional input to enhance the monitoring (SIEM solution) by using the technical indicators of the actionable threat or probable threats applicable to the entity. c. as input to the information security test processes and techniques. d. The entity can share threat intelligence with the CSC, Emirate or national level entities on a mutual basis in order to improve overall threat intelligence.

Identifying technical vulnerabilities The entity should have an accurate inventory of assets as a prerequisite for effective technical vulnerability management; the inventory should include the software vendor, software name, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person(s) within the entity responsible for the software. 114 To identify technical vulnerabilities, the entity should consider: a. defining and establishing the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, updating, asset tracking and any coordination responsibilities required. b. for software and other technologies (based on the asset inventory list), identifying information resources that will be used for identifying relevant technical vulnerabilities and maintaining awareness about them. Updating the list of information resources based on changes in the inventory or when other new or useful resources are found. c. requiring suppliers of information system (including their components) to ensure vulnerability reporting, handling, and disclosure, including the requirements in applicable contracts. d. using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether the remediation of vulnerabilities was successful. e. conducting planned, documented, and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities, exercising caution as such activities can lead to a compromise of the security of the system. f. tracking the usage of third-party libraries and source code for vulnerabilities. This should be included in secure coding. The entity should develop procedures and capabilities to: a. detect the existence of vulnerabilities in its products and services including any external component used in these. b. receive vulnerability reports from internal or external sources. The entity should provide a public point of contact to national, emirate or sectoral vulnerability disclosure programs so that researchers and others are able to report issues. The entity should establish vulnerability reporting procedures, online reporting forms and make use of appropriate threat intelligence or information sharing forums. The entity should also consider bug bounty programs where rewards are offered as an incentive to assist entities in identifying vulnerabilities in order to appropriately remediate them. The entity should also share information with competent industry bodies or other interested parties. Evaluating technical vulnerabilities To evaluate identified technical vulnerabilities, the following guidance should be considered: a. analyze and verify reports to determine what response and remediation activity is needed. b. once a potential technical vulnerability has been identified, identifying the associated risks and the actions to be taken. Such actions can involve updating vulnerable systems or applying other compensating controls. Taking appropriate measures to address technical vulnerabilities A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. If changes are necessary, the original software should be retained, and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body. The following guidance should be considered to address technical vulnerabilities: a. taking appropriate and timely action in response to the identification of potential technical vulnerabilities; defining a timeline to react to notifications of potentially relevant technical vulnerabilities. b. depending on the criticality and impact of the technical vulnerability to an entity, carrying out remediation actions to the controls related to change management or by following information security incident response procedures. 115 c. use systems or software updates released by vendors as a fix to the identified vulnerabilities from the legitimate sources. d. testing and evaluating updates before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated [i.e. if an update is available, assessing the risks associated with installing the update (the risks posed by the vulnerability should be compared with the risk of installing the update)]. e. addressing systems at high risk first. f. develop remediation (typically software updates or patches). g. test to confirm if the remediation or mitigation is effective. h. provide mechanisms to verify the authenticity of remediation. If no update is available or the update cannot be installed, considering compensating controls, such as: a. applying any workaround suggested by the software vendor or other relevant sources. b. turning off services or capabilities related to the vulnerability. c. adapting or adding access controls (e.g. firewalls) at network borders. d. shielding vulnerable systems, devices, or applications from attack through deployment of suitable traffic filters (sometimes called virtual patching). e. increasing monitoring to detect actual attacks. f. raising awareness of the vulnerability. For acquired software, if the vendors regularly release information about security updates for their software and provide a facility to install such updates automatically, the entity should decide whether to use the automatic update or not. Technical compliance checking should be performed either manually (supported by appropriate software tools, if necessary) by an experienced system engineer, and/or with the assistance of automated tools, which generate a techni

The entity should identify and promptly remediate security and privacy risks by establishing and implementing policies and procedures for the use of encryption technology to protect data at rest (may include but not limited to file servers, databases, and end-user devices) and in motion (may include but not limited to system interfaces, over public networks, and electronic messaging). a. the entity should implement encryption techniques in accordance with best practices and guidance provided by recognized cryptographic standards and applicable cryptographic laws and regulations approved by the relevant cryptography authority, in accordance with its applicable category. b. the entity should ensure that weak/outdated ciphers and hashing algorithms should not be used by the entity. c. the entity should conduct periodic reviews to confirm that the deployed encryption measures are appropriate for use. d. the entity should identify the need for encryption of data, information or services, based on its classification, risk assessment, and business requirements. e. robust and continuous risk management program should be established and implemented to identify the need for cryptographic controls. 117 f. the entity should comply with applicable legal statutory and regulatory requirements related to encryption, through the maintenance of a compliance management program. g. the entity should define roles and responsibilities for: • the implementation of the rules for the effective use of cryptography. • the key management, including key generation. the entity should perform periodic assessments to ensure compliance with the established policy and relevant UAE laws and regulations.

The network security policy establishes the guidelines and procedures for securing information in transit and information sharing, ensuring the confidentiality, integrity, and availability of ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ data. This policy outlines the roles and responsibilities and necessary controls to prevent unauthorized access, use, disclosure, modification, destruction, or loss of information. The policy can include, but is not limited to: a. network security management b. network segregation c. wireless security d. web security The network security policy can be integrated into a single general information security policy document or may be represented by multiple policies depending on the complexity of the entity ‘s network infrastructure. Network managers should implement controls to ensure the security of information in networks, and the protection of connected services from unauthorized access. In particular, the following items should be considered: a. the type and classification level of information that the network can support. b. operational responsibility for networks should be separated from computer operations where appropriate. c. responsibilities and procedures for the management of remote equipment, including equipment in user areas, should be established. d. establishing controls to safeguard the confidentiality and integrity of data passing over public networks, third- party networks, or over wireless networks and to protect the connected systems and applications. Additional controls can also be required to maintain the availability of the network services and computers connected to the network. e. appropriately logging and monitoring to enable recording and detection of actions that can affect, or are relevant to, information security f. management activities should be closely coordinated both to optimize the service to the entity and to ensure that controls are consistently applied across the information processing infrastructure. 124 Further measures can include: a. implementing ingress and egress filtering to allow only those ports and protocols with an explicit and documented business need. b. restricting access only to trusted sites (whitelists). c. inspecting packets on DMZ networks using Security Event Information Management (SEIM) or log analytics systems. d. authenticating systems on the network. e. hardening of network devices. f. segregating network administration channels from other network traffic. g. temporarily isolating critical subnetworks (e.g. with drawbridges) if the network is under attack. h. disabling vulnerable network protocols. i. deploying Sender Policy Framework (SPF) records in DNS and enabling receiver-side verification in mail servers. j. disabling or uninstalling unused services. k. enabling network firewalls, Web Application Firewalls (WAF) etc. to control and monitor the incoming and outgoing network traffic. l. enabling host-based firewalls or port filtering tools on end systems with a default-deny rule that drops all traffic except those services and ports that are explicitly allowed. m. regularly scanning ports on all key servers and compare results to a known effective baseline. n. backup and protecting firewall, router, and switch configurations. The entity should consider “zero trust” principles such as: a. assuming the entity’s information systems are already breached and thus not be reliant on network perimeter security alone. b. employing a “never trust and always verify” approach for access to information systems. c. ensuring that requests to information systems are encrypted end-to-end. d. verifying each request to an information system as if it originated from an open, external network, even if these requests originated internal to the entity (i.e. not automatically trusting anything inside or outside its perimeters). 125

Owners of information and other associated assets should determine information security and business requirements related to identity and access management. A policy on identity and access management should be defined which takes account of these requirements and should be communicated to all relevant interested parties. These requirements and the policy should consider the following: a. determining which entities require which type of access to the information and other associated assets. b. applications are secure and that access to them is controlled. c. manage physical entry, ensuring secure access to physical locations where information and assets are stored. d. apply the need-to-know principle, consider information security levels, and classify information accordingly to control dissemination and access. 130 e. restrict privileged accounts to essential personnel only, enforce strict access controls, regularly review permissions, and monitor all activities to prevent unauthorized access and misuse. f. segregation of duties, separate the roles access requests, authorization, and administration. g. relevant legislation, regulations and any contractual obligations regarding limitation of access to data or services. h. implement continuous monitoring and logging for all account activities to detect and respond. 131 T5.2 User Access Management Objective To enforce authorized user access and to prevent unauthorized access to information systems. Performance Indicator Percentage of identities that are managed by centralized identity management system. The total number of access requests processed within a specified timeframe. The number of unauthorized access attempts detected and prevented. Percentage of accuracy in access provisioning and deprovisioning. Number of delayed access change requests and the average time taken to action them. Automation Guidance One effective way to automate user access management is to implement an Identity Governance and Administration (IGA) solution. IGA solutions manage user accounts, authentication, authorization, roles, and privileges. They are suitable for entities of all sizes and complexities. Selecting the appropriate IGA solution requires an organization to thoroughly assess its technology landscape, integration requirements, and the readiness of its IT staff to operate and maintain the solution. Additionally, entities should consider which authentication technologies and processes to implement, such as smart cards, security tokens, one-time passwords, smartphone authentication apps, and biometric authentication systems, ensuring they align with organizational security needs and user convenience. One effective way to automate Privileged Access Management (PAM) is to implement a comprehensive PAM solution. PAM solutions manage privileged accounts, access controls, session monitoring, and credential management. They are suitable for entities of all sizes and complexities. Relevant Threats and Vulnerabilities • Use of stolen login credentials • Brute force and dictionary attacks • Authentication bypass • Phishing and Social Engineering Attacks

The processes used in the context of identity management should ensure that: a. for identities assigned to persons, each identity is uniquely linked to a single person to ensure accountability for actions performed under that identity. 132 b. identities assigned to multiple persons (e.g. shared identities) are only permitted when necessary for business or operational reasons and must be subject to dedicated approval and thorough documentation. c. identities assigned to non-human entities (e.g. service accounts, automated processes) undergo appropriately segregated approval processes and are subject to independent ongoing oversight to ensure their use remains justified and secure. d. identities are disabled or removed promptly if they are no longer required, such as when associated entities are deleted, no longer in use, or if the person linked to the identity has left the entity or changed roles. e. within a specific domain, each identity is mapped to a single entity, avoiding the creation of multiple identities for the same entity within the same context to prevent confusion and potential security risks. f. records of all significant events related to the use and management of user identities and authentication information are maintained, including changes, access attempts, and other relevant activities. g. the entity has processes in place to handle changes to information related to user identities, including the re- verification of trusted documents linked to a person to maintain the integrity of identity records. h. when using identities provided or issued by third parties (e.g. social media credentials), the entity ensures these third-party identities meet the required trust levels and that any associated risks are identified, understood, and adequately managed. This may involve implementing controls related to both the third parties and the associated authentication information.

The access control procedure for user access provisioning and de-provisioning should include: a. verifying that the user has authorization from the owner of the information system or service for the use of the information system or service; separate approval for access rights from management may also be appropriate. b. verifying that the level of access granted is appropriate to the business purpose and is consistent with organizational security policy, e.g. it does not compromise segregation of duties. c. ensuring that access rights are activated (e.g. by service providers) only after authorization procedures are successfully completed. 133 d. considering segregation of duties, including segregating the roles of approval and implementation of the access rights and separation of conflicting roles. e. consider giving temporary access rights for a limited time period and revoking them at the expiration date, in particular for temporary personnel or temporary access required by personnel. f. maintaining a formal record of all persons registered to use systems and service centrally. g. immediately removing or blocking access rights of users who have changed roles or jobs or left the entity. h. periodically identifying, and removing or blocking, redundant user IDs and redundant and inactive accounts. i. ensuring that redundant user IDs are not issued to other users.

Multi-user systems that require protection against unauthorized access should have the allocation of privileges controlled through a formal authorization process in accordance with the relevant access control policy. The following steps should be considered: a. privileged access rights associated with each system, e.g. operating system, database and application, should be identified. b. privileged access rights should: • be granted to users strictly on a need-to-use basis and event-by-event basis, according to the access control policy, ensuring users receive the minimum access necessary for their specific roles only when needed. • not be provided until the formal authorization process is fully completed to prevent unauthorized access. • be assigned to a separate User ID from the one used for regular daily activities, ensuring that privileged accounts are not used for non-administrative tasks. c. an authorization process and a record of all privileges allocated should be maintained. d. a process where users periodically confirm their need for privileged access, helping to ensure that only necessary privileges are retained should be implemented. e. requirements for expiry of privileged access rights should be defined. 134 f. the competences of users with privileged access rights should be reviewed regularly in order to verify if they are in line with their duties. g. specific procedures should be established and maintained in order to avoid the use of generic administration User IDs, according to systems configuration capabilities: h. for generic administration User IDs, the confidentiality of security credentials should be maintained when shared (changing them frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms). i. temporary privileged access should be granted just for the time window necessary to implement approved changes or activities (e.g. for maintenance activities or some critical changes), rather than permanently granting privileged access rights. j. Break the glass procedures should be established to provide controlled access to critical IT systems in emergencies, such as system outages, failures, or cyber security incidents. These procedures ensure that emergency access accounts are reserved for urgent scenarios requiring privileged access to facilitate immediate troubleshooting and recovery. These accounts must not be used for regular operations and should be governed by formal incident response protocols. All access requests and actions must be documented, monitored, and authorized to maintain security, business continuity, and accountability. k. ongoing training for users with privileged access should be provided to ensure they understand their responsibilities.

The review of access rights should consider the following guidelines: a. users’ access rights should be reviewed at regular intervals and after any changes, such as promotion, demotion or termination of employment. b. user access rights should be reviewed and re-allocated when moving from one employment to another within the same entity. c. authorizations for special privileged access rights should be reviewed at more frequent intervals. d. privilege allocations should be checked at regular intervals to ensure that unauthorized privileges have not been obtained. e. changes to privileged accounts should be logged for periodic review. 135 T5.3 Secure authentication and authorization Objective To ensure a user or an entity is securely authenticated and authorized, when access to systems, applications and services is granted. Performance Indicator Percentage of accounts that have MFA enabled. Percentage of accounts that have SSO enabled. Percentage of successful authentication attempts relative to the total number of authentication attempts. Automation Guidance The entity can deploy Multi-Factor Authentication (MFA) and Single Sign-On (SSO) solutions to enhance their security posture and streamline user access management. MFA is a security mechanism that requires users to provide two or more verification factors to gain access to a resource such as an application, online account, or VPN. SSO, on the other hand, is an authentication process that allows a user to access multiple applications with one set of login credentials, streamlining the user experience and reducing the number of passwords a user must remember and manage. Relevant Threats and Vulnerabilities • Inadequate authentication • Unauthorized access due to weak or stolen passwords • Increased susceptibility to phishing attacks • Password fatigue • Inconsistent access control policies implementation

Even though most applications have secure log-on implemented, a suitable authentication technique should be chosen to substantiate the claimed identity of a user. The strength of authentication should be appropriate for the classification of the information to be accessed. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, should be used. Authentication information should be accompanied by additional authentication factors for accessing critical information systems (also known as multi-factor authentication). Using a combination of multiple authentication factors, such as what you know, what you have and what you are, reduces the possibilities for unauthorized accesses. Multi-factor authentication can be combined with other techniques to require additional factors under specific circumstances, based on predefined rules and patterns, such as access from an unusual location, from an unusual device or at an unusual time. 136 Biometric authentication information should be invalidated if it is ever compromised. Biometric authentication can be unavailable depending on the conditions of use (e.g. moisture or aging). To prepare for these issues, biometric authentication should be accompanied with at least one alternative authentication technique. The procedure for logging into a system or application should be designed to minimize the opportunity for unauthorized access. The log-on procedure should therefore disclose the minimum of information about the system or application, in order to avoid providing an unauthorized user with any unnecessary assistance. A good log-on procedure should: a. not display system or application identifiers until the log-on process has been successfully completed. b. display a general notice warning that the computer should only be accessed by authorized users. c. not provide help messages during the log-on procedure that would aid an unauthorized user. d. 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. e. protect against brute force log-on attempts. f. log unsuccessful and successful attempts. g. raise a security event if a potential attempted or successful breach of logon controls is detected. h. display the following information on completion of a successful log-on: • date and time of the previous successful log-on. • details of any unsuccessful log-on attempts since the last successful log-on. i. Not display a password being entered. j. not transmit passwords in clear text over a network. k. terminate inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the entity’s security management or on mobile devices. l. restrict connection times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access. Connection time controls should be considered for sensitive computer applications, especially from high-risk locations, e.g. public or external areas that are outside the entity’s security management. Examples of such restrictions include: a. using predetermined time slots, e.g. for batch file transmissions, or regular interactive sessions of short duration. b. restricting connection times to normal office hours if there is no requirement for overtime or extended hours operation. c. considering re-authentication at timed intervals. A time-out facility should clear the session screen and also, possibly later, close both application and network sessions after a defined period of inactivity. The time-out delay should reflect the security risks of the area, the classification of the information being handled, and the applications being used, and the risks related to the users of the equipment. A limited form of time-out facility can be provided for some systems, which clear the screen and prevents unauthorized access but does not close down the application or network sessions. 137

The allocation and management process should ensure that: a. personal passwords or personal identification numbers (PINs) generated automatically during enrolment processes as temporary secret authentication information, are non-guessable and unique for each person, and that users are required to change them after the first use. b. procedures are established to verify the identity of a user prior to providing new, replacement or temporary authentication information. c. authentication information, including temporary authentication information, is transmitted to users in a secure manner (e.g. over an authenticated and protected channel) and the use of unprotected (clear text) electronic mail messages for this purpose is avoided. d. users acknowledge receipt of authentication information. e. default authentication information as predefined or provided by vendors is changed immediately following installation of systems or software. f. records of significant events concerning allocation and management of authentication information are maintained. g. passwords are kept and their confidentiality is granted, and that the record-keeping method is approved (e.g. by using an approved password vault tool). 141

All users should be advised to: a. keep credentials confidential, ensuring that they are not divulged to any other parties, including people of authority. b. avoid keeping a record (e.g. paper, software file or hand-held device- of security credentials, unless this can be stored securely, and the method of storing has been approved (e.g. password vault). c. change security credentials whenever there is any indication of their possible compromise. d. when passwords are used as security credentials, 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. e. change temporary passwords at the first log-on. f. not share individual user’s security credentials. g. when passwords are used as security credentials in automated logon procedures, these should not be stored without proper protection. h. not use the same security credentials for business and non-business purposes. If users need to access multiple services, systems or platforms, and they are required to maintain multiple separate passwords, they should be advised that they may use a single, quality password (see d) for all services where the user is assured that a reasonable level of protection has been established for the storage of the password within each service, system or platform. 142

A management system for user credentials should: a. enforce the use of individual user IDs and credentials to maintain accountability. b. allow users to select and change their own credentials and include a confirmation procedure to monitor input errors. c. enforce a choice of quality credentials. d. enforce credential changes. e. force users to change temporary credentials at the first log-on. f. maintain a record of previous user credentials and prevent re-use. g. not display credentials on the screen when being entered. h. store credential files separately from application system data. i. store and transmit credentials in protected (e.g. encrypted or hashed) form. j. enforce minimum logging attempt before locking out user accounts. 143 T6 Third-Party Security T6 Third Party Security Objective To ensure external stakeholders are compliant with an entity's security requirements. Performance indicator Frequency of information security incidents involving third parties. T6.1 Third Party Security Policy Objective To maintain a third party security policy covering the security of acquired services. Performance Indicator Extent of third party security policy deployment and adoption across the entity. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Unsuitable third party security policy • Unawareness of third party security policy among staff

The senior leadership of the entity should mandate the establishment of a third party security program with appropriate oversight and direction, and assign resources (budget, people, and technology) for the successful implementation of the program. The entity should establish, document, and periodically review the effectiveness of policies governing critical aspects of third party security. The entity should identify and ensure compliance with the applicable legal and regulatory requirements (refer to the CSC’s issued National Third Party Security Policy). The third party security program should establish clear communication channels between stakeholders, such as third-party suppliers, internal departments, and external partners, to ensure effective collaboration and alignment The entity should provide training and awareness programs for all employees who interact with third-party suppliers. 144 T6.2 Management of Third Party and Supply Chain Risks Objective To manage the information security risks associated with the use of supplier’s products or services. Performance Indicator Frequency of information security incidents involving third parties. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Abuse of functionality • Unauthorized access to information

The entity should identify and implement procedures to address security risks associated with the use of products and services provided by third party. This should also apply to the entity’s use of resources of cloud service providers as well. These procedures should include considerations be implemented by the entity, as well as those the entity requires the third party to implement, for the commencement or for the termination of a third party’s products and services, including: a. identifying and documenting the types of third parties (e.g. ICT services, logistics, utilities, financial services, ICT infrastructure components) which can affect the confidentiality, integrity and availability of the entity's information. b. establishing how to evaluate and select third party according to the sensitivity of information, products and services (e.g. with market analysis, customer references, review of documents, onsite assessments, certifications). c. assessing and managing the information security risks associated with: • the third parties’ use of the entity’s information and other associated assets, including risks originating from potential malicious supplier personnel. • malfunctioning or vulnerabilities of the products (including software components and subcomponents used in these products) or services provided by the third parties. The risk mitigation strategy should include appropriate controls and measures to reduce the identified risks to an acceptable level, considering the nature of the vendor's services, the sensitivity of the data or systems involved, and the potential impact of a security breach. The entity should implement additional measures to mitigate the risks associated with high-risk suppliers, which may include: 145 a. Enhanced due diligence and background checks. b. Regular and thorough security assessments, audits, or evaluations to ensure compliance with the defined standards. c. Periodic vulnerability assessments and penetration testing to identify and address potential vulnerabilities and weaknesses. d. Proactive monitoring of the high-risk suppliers' activities, such as real-time event monitoring and anomaly detection. e. Implementing stricter access controls and restrictions to limit their access to ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information or critical systems. f. Implementing contractual provisions allowing for increased oversight and accountability, such as the right to conduct on-site visits or inspections. g. Involving high risk suppliers in resilience assessments and simulations such as red teaming or cyber tabletop exercises. The entity should periodically re-assess the risks associated with each third-party vendor considering the effectiveness of implemented controls, the vendor's adherence to established security requirements, and any additional risks that may have emerged since the previous risk assessment. The entity should document periodic risk assessment results. The risk mitigation strategy should be integrated into contractual agreements as appropriate.

The entity should: a. develop a comprehensive vendor/supplier security assessment template that is aligned to international standards and best practices. The assessment criteria should include relevant topics such as Supplier Governance, Secure Code, Secure Design and Engineering, Information Security, Physical Security, Monitoring and Auditing, Incident Response and Recovery. b. conduct due diligence checks to verify the validity of the vendor’s cyber security posture prior to onboarding as well as regularly, as determined by the criticality of the third party. 146

Prior to procurement of hardware and software, the entity should clearly define its security requirements. The entity should define the types of ICT infrastructure components and services provided by third parties which can affect the confidentiality, integrity, and availability of the entity 's information. Procurement requirements should include security criteria for the product, including but not limited to authentication and authorization mechanisms, data encryption, and security protocols. The entity should evaluate third-party software & hardware products and services, against these requirements to ensure that they meet the entity's security standards before procurement. Other considerations include: a. The entity should require third parties as per their criticality to provide a software bill of materials (SBOM) or hardware bill of materials (HBOM) for products under consideration for procurement. b. The entity should use the SBOMs and HBOMs to identify and evaluate all components of the product and assess their potential security risks. c. The entity should only procure products that have been determined to meet the entity's security standards. d. The entity should implement processes to ensure that components from third parties are genuine and unaltered from their specification. The entity should perform acceptance testing (including functional testing, performance testing, and security testing, as appropriate) on all software and hardware prior to deployment to ensure that they meet the entity's security requirements. The entity should: a. establish testing criteria and test cases based on industry standards, best practices, and the entity's specific security needs. b. document all testing results and use them to inform decisions about whether to deploy the product, apply additional security controls, or reject the product. c. do its due diligence to verify the SBOM/HBOMs provided by the vendor prior to deployment, where appropriate. d. obtain assurance that ICT products achieve required security levels, for example, through formal certification or an evaluation scheme such as the Common Criteria Recognition Arrangement. e. should obtain assurance that critical components and their origin can be traced throughout the supply chain. f. obtain assurance that the delivered ICT products are functioning as expected without any unexpected or unwanted features. 147 g. define rules for sharing of information regarding the supply chain and any potential issues and compromises among the entity and third parties. The entity should: a. ensure that all software and hardware upgrades and maintenance activities are carried out in a timely manner to maintain the security of the supply chain. b. require suppliers to provide advance notice of any planned upgrades or maintenance activities impacting the entity's systems. c. ensure that upgrades and maintenance activities are tested in a test environment before they are deployed in the production environment. d. ensure that any vulnerabilities discovered during the upgrade or maintenance process are documented, prioritized, and addressed in a timely manner prior to deployment. The entity should establish secure decommissioning and disposal processes for all software and hardware products that have reached end-of-life. The entity should identify an alternative supplier and the process to transfer software and competence to the alternative third party, in case of suppliers no longer being in business or third parties no longer providing these components due to technology advancements or other organizational decisions.

The information systems acquisition, development and maintenance policy shall facilitate the implementation of the associated controls to integrate information security requirements into the software life cycle of information systems that contain protected data. The policy should contain in addition to the required sub-controls: a. separation of development, test and production environments. b. guidance on the security in the software development life cycle: • security in the software development methodology. • secure coding guidelines for each programming language used. c. security requirements in the specification and design phase. 151 d. security checkpoints in projects e. system and security testing, such as regression testing, code scan and penetration tests. f. secure repositories for source code and configuration. g. security in the version control. h. required application security knowledge and training. i. developers’ capability for preventing, finding and fixing vulnerabilities. j. licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing issues. The entity should adopt and integrate its policies with modern development methodologies, such as DevSecOps, to ensure ongoing security throughout the Software Development Lifecycle (SDLC). This can be achieved by: a. Embedding security considerations early in the development process: • Conducting threat modeling during the design phase. • Implementing secure coding practices. b. Automating security checks within the CI/CD pipeline, such as: • Static Application Security Testing (SAST). • Dynamic Application Security Testing (DAST). • Software Composition Analysis. The information systems acquisition, development and maintenance policy can be included as part of the general information security policy, in a single policy document, or can be represented by multiple policies reflecting the complex nature of certain entities. 152 T7.2 Security Requirements of Information Systems Objective To ensure that security requirements are established and functionally integrated into information systems. Performance Indicator Percentage of systems implementations accepted into service with all security requirements implemented. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Equipment malfunction • Abuse of functionality • Lack of security in design

Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists. Application security requirements can cover a wide range of topics, depending on the purpose of the application. Application security requirements should include, as applicable: a. level of trust in the identity of entities [e.g. through authentication (refer T5.3.1). b. identifying the type of information and classification level to be processed by the application. c. need for segregation of access and level of access to data and functions in the application. d. resilience against malicious attacks or unintentional disruptions [e.g. protection against buffer overflow or structured query language (SQL) injections]. e. legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored. f. need for privacy associated with all parties involved. g. the protection requirements of any ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information. h. protection of data while being processed, in transit and at rest. i. need to securely encrypt communications between all involved parties. j. input controls, including integrity checks and input validation. k. automated controls (e.g. approval limits or dual approvals). 153 l. output controls, also considering who can access outputs and its authorization. m. restrictions around the content of "free-text" fields, as these can lead to uncontrolled storage of ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ data (e.g. personal data). n. requirements derived from the business process, such as transaction logging and monitoring, and non- repudiation requirements. o. requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems). p. error message handling. Transactional services Additionally, for applications offering transactional services between the entity and a partner, the following should be considered when identifying information security requirements: a. the level of trust each party requires in each other’s claimed identity. b. the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures). c. authorization processes associated with who can approve contents of issue or sign key transactional documents. d. confidentiality, integrity, proof of dispatch and receipt of key documents and non-repudiation (e.g. contracts associated with tendering and contract processes). e. the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts). f. requirements on how long to maintain a transaction confidential. g. insurance and other contractual requirements. Electronic ordering and payment applications Additionally, for applications involving electronic ordering and payment, the following should be considered: a. requirements for maintaining the confidentiality and integrity of order information. b. the degree of verification appropriate to verify payment information supplied by a customer. c. avoidance of loss or duplication of transaction information. d. storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet). e. when a trusted authority is involved, such as for issuing and maintaining digital signatures or certificates, security is seamlessly integrated and embedded throughout the entire certificate or signature management process. Digital services For applications used to provide digital services, the following should be considered: a. requirements for maintaining the confidentiality and integrity of digital services. b. requirements for availability of digital services. c. compliance with the laws, regulations, government policies, and information security and business continuity requirements. d. requirements on storing and retaining customer information. 154 e. the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity. f. strong mechanism for authentication and authorization. Other information Applications accessible via networks are subject to a range of network-related threats, such as fraudulent activities, contract disputes or disclosure of information to the public, incomplete transmission, misrouting, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and secure data transfer.

Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analyzed for security risks and the design should be reviewed against known attack patterns. Secure engineering principles provide guidance on user authentication techniques, secure session control and data validation and sanitization. Secure system engineering principles should include an analysis of: a. the full range of security controls required to protect information and systems against identified threats. b. the capabilities of security controls to prevent, detect, or respond to security events. c. specific security controls required by particular business processes (e.g. encryption of ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information, integrity checking, and digitally signing information). d. where and how security controls are to be applied (e.g. by integrating with a security architecture and the technical infrastructure). e. how individual security controls (manual and automated) work together to produce an integrated set of controls. Security engineering principles should consider: a. the need to integrate with a security architecture. b. technical security infrastructure [e.g. public key infrastructure (PKI), identity and access management (IAM), data leakage prevention, and dynamic access management]. c. capability of the entity to develop and support the chosen technology. d. cost, time, and complexity of meeting security requirements. 155 e. current good practices. Secure system engineering should involve: a. the use of security architecture principles, such as “security by design”, “defense in depth”, “security by default”, “default deny”, “fail securely”, “distrust input from external applications”, “security in deployment”, “assume breach”, "least privilege", “usability and manageability” and “least functionality”. b. a security-oriented design review to help identify information security vulnerabilities, ensure security controls are specified and meet security requirements. c. documentation and formal acknowledgment of security controls that do not fully meet requirements (e.g. due to overriding safety requirements). d. hardening of systems. The entity should establish a comprehensive process to ensure that all newly engineered systems adhere to the entity's approved security engineering principles and architecture. This can be achieved by setting up architecture review boards, which will evaluate and approve system designs for compliance with security standards. The entity should establish a cyber security reference architecture to identify and manage its cyber security capabilities. Security blueprints should be developed for key cyber security domains such as identity and access management, network security, data security, and DevSecOps. These blueprints should be used to guide architectural discussions when new technologies, solutions, or systems are deployed or developed. . 156 T7.3 Secure software development Objective To ensure the software is written securely thereby reducing the number of potential information security vulnerabilities in the software. Performance Indicator Instances where critical security vulnerabilities were not fixed before deployment of code into a production environment. Automation Guidance The entity can enhance the security of their software development lifecycle by implementing automated security testing tools. These tools help identify vulnerabilities early in the development process and ensure continuous security assurance throughout the software lifecycle. Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA) are essential components of a comprehensive security strategy. SAST analyzes source code or binaries for vulnerabilities without executing the program, identifying issues early in the development process. DAST tests running applications by simulating real-world attacks to uncover security flaws that only manifest during execution. SCA focuses on the security of open-source and third-party components, identifying known vulnerabilities and license compliance issues within the software supply chain. Together, these tools provide a multi-faceted approach to securing applications throughout their lifecycle. Relevant Threats and Vulnerabilities • Exposure to critical vulnerabilities • Lack of experienced/unskilled employees • Inadequate review/testing

(For Information Purpose only) The entity should establish entity-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open-source software. The entity should continuously monitor real-world threats and stay informed about the latest advice and information on software vulnerabilities to guide its secure coding principles, fostering continual improvement and learning. This can help to ensure that effective secure coding practices are implemented to combat the fast-changing threat landscape. Planning and before coding 157 Secure coding principles should be used for both new developments and reuse scenarios. These principles should be applied to development activities both within the entity and for products and services supplied by the entity to others. Planning and prerequisites before coding should include: a. entity-specific expectations and approved principles for secure coding to be used for both in-house and outsourced code developments. b. common and historical coding practices and defects that lead to information security vulnerabilities. c. configuring development tools, such as integrated development environments (IDE), to help enforce the creation of secure code. d. following guidance issued by the providers of development tools and execution environments as applicable. e. maintenance and use of updated development tools (e.g. compilers). f. qualification of developers in writing secure code. g. secure design and architecture, including threat modeling. h. secure coding standards and where relevant mandating their use. i. use of controlled environments for development. During coding Considerations during coding should include: a. secure coding practices (aligned with international standards such as OWASP) specific to the programming languages and techniques being used. b. using secure programming techniques, such as pair programming, refactoring, peer review, security iterations, and test-driven development. c. using structured programming techniques. d. documenting code and removing programming defects, which can allow information security vulnerabilities to be exploited. e. prohibiting the use of insecure design techniques (e.g. hard-coded passwords, unapproved code samples and unauthenticated web services). f. perform Software Composition Analysis (SCA) to identify and mitigate vulnerabilities in open-source and third- party components of the software. Testing should be conducted during and after development (see 8.29). Static Application Security Testing (SAST) processes can identify security vulnerabilities in software. Before software is made operational, the following should be evaluated: a. attack surface and the principle of least privilege. b. conducting an analysis of the most common programming errors and documenting that these have been mitigated. Review and maintenance After the code has been made operational: a. updates should be securely packaged and deployed. b. reported information security vulnerabilities should be handled (refer T3.3.2). c. errors and suspected attacks should be logged and regularly reviewed to make adjustments to the code as necessary. 158 d. source code should be protected against unauthorized access and tampering (e.g. by using configuration management tools, which typically provide features such as access control and version control). If using external tools and libraries, the entity should consider: a. ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles. b. selection, authorization and reuse of well-vetted components, particularly authentication and cryptographic components. c. the license, security and history of external components. d. ensuring that software is maintainable, tracked and originates from proven, reputable sources. e. sufficiently long-term availability of development resources and artefacts. Where a software package needs to be modified the following points should be considered: a. the risk of built-in controls and integrity processes being compromised. b. whether to obtain the consent of the vendor. c. the possibility of obtaining the required changes from the vendor as standard program updates. d. the impact if the entity becomes responsible for the future maintenance of the software as a result of changes. e. compatibility with other software in use. Other information A guiding principle is to ensure security-relevant code is invoked when necessary and is tamper-resistant. Programs installed from compiled binary code also have these properties but only for data held within the application. For interpreted languages, the concept only works when the code is executed on a server that is otherwise inaccessible by the users and processes that use it, and that its data is held in a similarly protected database. For example, the interpreted code can be run on a cloud service where access to the code itself requires administrator privileges. Such administrator access should be protected by security mechanisms such as just-in-time administration principles and strong authentication. If the application owner can access scripts by direct remote access to the server, so in principle can an attacker. Webservers should be configured to prevent directory browsing in such cases. Application code is best designed on the assumption that it is always subject to attack, through error or malicious action. In addition, critical applications can be designed to be tolerant of internal faults. For example, the output from a complex algorithm can be checked to ensure that it lies within safe bounds before the data is used in an application such as a safety or financial critical application. The code that performs the boundary checks is simple and therefore mu

160 Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled. For source code, this can be achieved by controlling the central storage or repository of such code, preferably in source code management system. Read access and write access to source code can differ based on the personnel’s role. For example, read access to source code can be broadly provided inside the entity, but write access to source code is only made available to privileged personnel or designated owners. Where code components are used by several developers within an entity, read access to a centralized code repository should be implemented. Furthermore, if open-source code or third-party code components are used inside an entity, read access to such external code repositories can be broadly provided. However, write access should still be restricted. The following guidelines should be considered to control access to program source libraries to reduce the potential for corruption of computer programs: a. managing the access to program source code and the program source libraries according to established procedures. b. granting read and write access to source code based on business needs and managing to address risks of alteration or misuse and according to established procedures. c. updating of source code and associated items and granting of access to source code in accordance with change control procedures and only performing it after appropriate authorization has been received. d. not granting developers direct access to the source code repository, but through developer tools that control activities and authorizations on the source code. e. holding program listings in a secure environment, where read and write access should be appropriately managed and assigned. f. maintaining an audit log of all accesses and of all changes to source code. If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered. If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons. 161 T7.4 Secure testing and deployment Objective To validate if information security requirements are met when applications or code are deployed to the production environment, protect the production environment and data from compromise by development and test activities, and preserve information security when executing changes. Performance Indicator Number of cases where the change management processes have not been executed correctly. Automation Guidance The entity should adopt technical solutions to monitor application and program changes/updates. Relevant Threats and Vulnerabilities • Unsuitable security for development and support processes • Lack of change management process • Information leakage

Introduction of new systems and major changes to existing systems should follow agreed rules and a formal process of documentation, specification, testing, quality control and managed implementation. Management responsibilities and procedures should be in place to ensure satisfactory control of all changes. Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts. Wherever practicable, change control procedures for ICT infrastructure and software should be integrated. The change control procedures should include: a. planning and assessing the potential impact of changes considering all dependencies. b. authorization of changes. c. communicating changes to relevant interested parties. d. tests and acceptance of tests for the changes (refer T7.4.3). e. implementation of changes including deployment plans. 162 f. emergency and contingency considerations including fallback procedures. g. maintaining records of changes that include all of the above. h. ensuring that operating documentation and user procedures are changed as necessary to remain appropriate. i. ensuring that ICT continuity plans and response and recovery procedures are changed as necessary to remain appropriate. Other information Inadequate control of changes to information processing facilities and information systems is a common cause of system or security failures. Changes to the production environment, especially when transferring software from development to operational environment, can impact on the integrity and availability of applications. Changing software can impact the production environment and vice versa. Good practice includes the testing of ICT components in an environment segregated from both the production and development environments (refer T3.1.4). This provides a means of having control over new software and allowing additional protection of operational information that is used for testing purposes. This should include patches, service packs and other updates. Production environment includes operating systems, databases and middleware platforms. The control should be applied for changes of applications and infrastructures.

Test information should be selected to ensure the reliability of test results and the confidentiality of the relevant operational information. ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information (including personally identifiable information) should not be copied into the development and testing environments (refer T3.1.4). The following guidelines should be applied to protect the copies of operational information, when used for testing purposes, whether the test environment is built in-house or on a cloud service: a. applying the same access control procedures to test environments as those applied to operational environments. b. having a separate authorization each time operational information is copied to a test environment. c. logging the copying and use of operational information to provide an audit trail. d. protecting ‘Confidential/Restricted’ or ‘Secret’ or ‘Top Secret’ information by removal or masking if used for testing. 163 e. properly deleting (refer T1.3.6) operational information from a test environment immediately after the testing is complete to prevent unauthorized use of test information. Test information should be securely stored (to prevent tampering, which can otherwise lead to invalid results) and only used for testing purposes.

CII entities should also take into account any other CSC’s relevant issuances, guidance, and activities in this regard. The information security incident management policy facilitates the implementation of the associated controls to ensure appropriate reaction to any actual or suspected security incidents relating to information assets. The policy can, for example, contain in addition to the required sub-controls: a. incident classification. b. requirements for reporting information security events or weaknesses. c. requirements for incident handling. 166 Information Security Incident Management Policy can be included as part of the general information security policy, in a single policy document, or can be represented by multiple policies reflecting the complex nature of certain entities.

CII entities should also take into account any other CSC’s relevant issuances, guidance, and activities in this regard (also refer to National Cyber Response Plan). The entity should consider the following: a. Develop an incident response plan that: • describes the structure of the incident response capability. • provides a high-level approach for how the incident response capability fits into the overall entity. • meets the unique requirements of the entity, which relate to mission, size, structure, and functions. • defines reportable incidents. • defines the resources and management support needed to effectively maintain and mature an incident response capability. • is reviewed and approved by defined personnel or roles. • provides criteria for evaluation of information security incidents. • provides guidance on monitoring, detecting, classifying, analyzing, and reporting information security events and incidents (by human or automatic means). • provides guidance on managing information security incidents to a conclusion, including response and escalation, according to the type and the category of the incident, possible activation of crisis management 168 and activation of continuity plans, controlled recovery from an incident, and communication to internal and external interested parties. • enables coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers, and clients. • provides guidance on logging incident management activities. • provides guidance on handling of evidence. • includes root cause analysis or post-mortem procedures. • enables identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required. • make the incident response plan available to defined incident response personnel (identified by name and/or by role- and organizational elements. • review and test the incident response plan in defined frequency. • update the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing. • protect the incident response plan from unauthorized disclosure and modification. Organizational missions, business functions, strategies, goals, and objectives for incident response help to determine the structure of incident response capabilities. As part of a comprehensive incident response capability, entities consider the coordination and sharing of information with external entities, including, for example, external service providers and entities involved in the supply chain for organizational information systems. Incident Response Team (IRT): The entity should identify members in the entity to form the proper IRT. Here are some of the suggestions for choosing IRT members: a. team leader who is usually a senior manager whose responsibility is to take charge of incidents and direct actions to other team members. b. boundary protection experts. Normally individuals that are expert in firewalls, routers and IDSs that sits at the edge of the network. c. network administrators. d. physical security members. e. human resources might be involved if the attach was originated by an employee. f. communication might be involved to become the public face for incidents that became public. Here are some of the primary responsibilities of the CSIRT: a. develop incident policy, plan, and procedures. b. response to incidents and minimizing the impact. c. investigate incidents and determine the cause. d. prevent future incidents by recommending security controls. e. handle incident reporting and communication to all stakeholders involved internally and externally. f. protect collected evidence. 169

Classification and prioritization of incidents can help to identify the impact and extent of an incident. A point of contact should assess the information security events using the agreed information security event and incident classification scale and decide whether the events should be classified as information security incidents. The entity's incident management framework should align with the CSC’s Cyber Incident Response Plan and Framework for incident prioritization and reporting requirements, as summarized below: Incident Prioritization and Classification: Level 1: Highest level of impact Level 2: High-level impact Level 3: Medium level of impact Level 4: Low-level impact Mean-Time-To-Notify: Level 4: Incident: Within 1440 minutes Level 3: Incident: Within 60 minutes Incident Update Notification Requirements: Level 4 Incident: Within 1440 minutes Level 3 Incident: Within 120 minutes Level 2 Incident: Within 60 minutes Level 1 Incident: Near-Real-Time While an entity’s incident classification may vary, the entity should ensure that their incident classification is mapped to the levels outlines in the CSC’s Cyber Incident Response Plan and Framework. Accordingly, provision should be made by the entity to report on incidents to national agencies. In case where the entity has IRT, the assessment and decision can be forwarded to the IRT for confirmation or reassessment. Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification. An attack is classified as an incident if the attack is directed against information assets, has a realistic chance of success and threatens the confidentiality, integrity and availability of information resources and assets. An indication of an incident can be one or more of the following: a. if dormant or inactive accounts started accessing system resources, querying servers, or engaged in other activities. 170 b. if modification of logs occurs and the systems administrator cannot determine explicitly the authorized individual who modified them. c. presence of hacking tools. d. notifications by partner or peer. e. notification by the attacker.

In designing the incident response training, entities should customize the content and level of details based on the targeted audience to allow attendees to focus on the information that is relevant to them. As such, end users may only need to identify an incident or suspicious activities and call the right contact, system administrators may require technical training on how to handle/remediate incidents, and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration.

The entity should develop testing procedures to determine the overall effectiveness of its incident response capabilities and to identify potential weaknesses or deficiencies. Incident response testing must simulate pre-defined breach scenarios across the incident response lifecycle from including detection, reporting, and recovery to normal operations. Incident response testing includes, for example, the use of checklists, tabletop (discussion-based) exercises, and functional (performance of duties in a simulated environment) exercises. The entity should participate in sector, national, and international exercises to further test incident response capabilities. 171

Documenting information security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports.

There should be mechanisms in place to enable the types, volumes, costs, and impacts of information security incidents to be quantified and monitored. The information gained from the evaluation of information security incidents should be used to identify recurring or high impact incidents and inform risk assessment and risk treatment activities. The information gained should also be used to enhance the incident management plan including incident scenarios and procedures. The entity should ensure that the post-incident report should, at a minimum, cover the following: a. impact and detailed damage assessment. b. mitigating measures and improvements concerning processes and policies. c. identified deficiencies. d. confirmation that the incident is closed. Additionally, investigations based on information distributed by relevant information sharing community should be performed, to reduce the risks of similar incidents and develop a better understanding of the risks facing the community and any related significant information infrastructures. Such investigations could be performed by the community members involved, or by a supporting entity, if one exists. 172 Following reported incidents, post incident reviews should be performed by members of the information sharing community to trigger updates to security incident response plans, related procedures and the business risk profile, and implementation of additional controls even if the member was not affected by the incident in question. Each member should ensure that reported incident responses are assessed, and any lessons or possible improvements to the member’s own processes are identified and acted upon to continuously improve its own response processes.

Internal procedures should be developed and followed when dealing with evidence for the purposes of disciplinary and legal action. Identification is the process involving the search for, recognition and documentation of potential evidence. Collection is the process of gathering the physical items that can contain potential evidence. Acquisition is the process of creating a copy of data within a defined set. Preservation is the process to maintain and safeguard the integrity and original condition of the potential evidence. In general, the procedures for evidence should provide processes of identification, collection, acquisition and preservation in accordance with different types of media, devices and status of devices, e.g. powered on or off. The procedures should take account of: a. chain of custody. b. safety of evidence. c. safety of the personnel. d. roles and responsibilities of personnel involved. e. competency of the personnel. f. documentation. 173 g. briefing. Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence. Forensic evidence may transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the entity is entitled to collect the required information as forensic evidence. The requirements of different jurisdictions should also be considered to maximize the chances of admission across the relevant jurisdictions. 174 T9 Information Systems Continuity Management T9 Information Systems Continuity Management Objective To ensure business continuity and protection of critical information during a crisis. Performance indicator Percentage of information assets with measured availability above the minimum acceptable thresholds. T9.1 ICT readiness for business continuity Objective To ensure the availability of the organization’s information and other associated assets during disruption. Performance Indicator Percentage of organizational units with documented information continuity plans, regular testing and business recovery is meeting expectations, ensuring minimal downtime. Automation Guidance Not applicable Relevant Threats and Vulnerabilities • Lack of availability of critical assets during crises • Destruction of equipment or media • Corruption of data

ICT readiness for business continuity (also referred to as Digital Continuity Management) is an important component in business continuity management and information security management to ensure that the entity’s objectives can continue to be met during disruption. The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services. The BIA involving ICT services can be expanded to define the performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption. 175 Based on the outputs from the BIA and risk assessment involving ICT services, the entity should identify and select ICT continuity strategies that consider options for before, during, and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented, and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes. The entity should ensure that: a. an adequate organizational structure is in place to prepare for, mitigate, and respond to a disruption supported by personnel with the necessary responsibility, authority, and competence. b. ICT continuity plans, including response and recovery procedures detailing how the entity is planning to manage an ICT service disruption, are: • regularly evaluated through exercises and tests. • approved by management. c. ICT continuity plans include the following ICT continuity information: • performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA. d. RTO of each prioritized ICT service and the procedures for restoring those components. e. RPO of the prioritized ICT resources defined as information and the procedures for restoring the information. Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to: a. respond and recover from disruption to ICT services regardless of the cause. b. ensure continuity of prioritized activities are supported by the required ICT services. c. respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services. d. alignment with entity’s crisis management practices. e. alternate mechanisms for communication during crisis. When implementing ICT readiness for business continuity, it is essential to address several key areas to ensure a resilient and responsive environment. Dependencies between systems and services should be mapped, and an updated asset register should be maintained, detailing critical systems, including routers, switches, and other network infrastructure. Each asset should have defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), ensuring that recovery priorities are aligned with business needs. Change management is another vital aspect, ensuring that no new systems or services go live without a signed-off DR plan. Additionally, a comprehensive training program should be rolled out to staff, ensuring they understand their roles in the business continuity process. Consideration must also be given to third-party dependencies, especially for outsourced services, with clear DR expectations and SLAs in place. 176

Business continuity plan tests should ensure that all members of the recovery team and other relevant staff are aware of the plans and their responsibility for business continuity and information security and know their role when a plan is invoked. The test schedule for business continuity plan(s) should indicate how and when each element of the plan should be tested. Each element of the plan(s) should be tested frequently. A variety of techniques should be used in order to provide assurance that the plan(s) will operate in real life. These should include: a. table-top testing of various scenarios (discussing the business recovery arrangements using example interruptions). b. simulations (particularly for training people in their post-incident/crisis management roles). c. technical recovery testing (ensuring information systems can be restored effectively). d. testing recovery at an alternate site (running business processes in parallel with recovery operations away from the main site). e. tests of supplier facilities and services (ensuring externally provided services and products will meet the contracted commitment). f. complete rehearsals (testing that the entity, personnel, equipment, facilities, and processes can cope with interruptions). These techniques can be used by any entity. They should be applied in a way that is relevant to the specific recovery plan. The results of tests should be recorded, and actions taken to improve the plans, where necessary. 178 Responsibility should be assigned for regular reviews of each business continuity plan. The identification of changes in business arrangements not yet reflected in the business continuity plans should be followed by an appropriate update of the plan. This formal change control process should ensure that the updated plans are distributed and reinforced by regular reviews of the complete plan. Examples of changes where updating of business continuity plans should be considered are acquisition of new equipment, upgrading of systems and changes in: a. personnel. b. addresses or telephone numbers. c. business strategy. d. location, facilities, and resources. e. legislation. f. contractors, suppliers, and key customers. g. processes, or new or withdrawn ones. h. risk (operational and financial). 179 Chapter 3: Implementation 180 3.1 Overview The purpose of this chapter is to explain key concepts related to the implementation of the UAE IA Standard such as the risk-based approach to information assurance and the applicability and prioritization of security controls. This chapter also highlights key stakeholder roles and responsibilities for the effective adoption and progression of the UAE IA, and it lists critical implementation success factors. The implementation of this standard is meant to complement any existing information assurance programs at implementing entities. This standard represents the sole point of reference for compliance against its requirements, as measured by the criteria associated with each of its security controls. 3.2 Information Assurance Lifecycle The UAE IA Standard promotes a lifecycle approach for establishing, implementing, maintaining and continuously improving information assurance. This lifecycle approach ensures continual improvement of the UAE’s information assurance capabilities based on well-defined activities: a. Understanding an entity’s and / or sector’s information security requirements and the need to establish a policy and objectives for information security. b. Conducting risk assessments, identifying appropriate risk treatment actions, and selecting controls to manage the risks. c. Implementing and operating security controls to manage information security risks in the context of the entity’s or sector’s overall business risks. d. Monitoring and reviewing the performance and effectiveness of the information security processes and controls. e. Ensuring continual improvement based on objective measurements. The continuous improvement aspect of the IA lifecycle ensures that IA capabilities are continuously adapted and evolved in line with changing requirements. The application of the IA lifecycle is facilitated best when integrated in the planning and governance activities of an entity or sector. 3.3 Risk Based Approach In today’s world, the cyber threat landscape is evolving rapidly at a pace where entities are challenged to keep up with the number and variety of threats. In the face of this growing threat landscape, entities need to adopt practical measures to defend their critical information and information infrastructure against their most critical vulnerabilities that could be exploited by threats. To this end, a risk-based approach provides entities with a pragmatic means to identify the most critical vulnerabilities that could expose them to risks and develop corresponding appropriate treatments. Adopting a risk-based approach ensures that security controls are instituted in accordance with current risk assessments commensurate with the risk and magnitude of the impact that could result if critical information assets are compromised. The risk-based approach briefly outlined below summarizes a systematic methodology for identifying, estimating, evaluating, and treating identified entity-level risks. It consists of eight key activities as illustrated in Figure below; 181 Figure 1 The Risk-Based Approach Process Performing risk management is a key step towards the implementation of the UAE IA Standard as it helps entities identify, prioritize, and measure the effectiveness of the security controls that are needed to treat identified entity- specific risks. Activity 1: Establishing the Environment: The risk assessment process should be initiated by establishing objectives, strategies, scope, and parameters of the activities of the entity, or those parts of the entity where the risk management process is being applied. Furthermore, criteria for assessing risks should be established in lin