convert_library_version: 'v2 ; Compat Mode: [0] {[v2.1] (DEFAULT) Don''t use any Compatibility
  Mode}'
urn: urn:intuitem:risk:library:ccb-cyfun2025
locale: en
ref_id: cyfun2025
name: CyberFundamentals 2025
description: "The CyberFundamentals Framework is a framework owned by the Centre for\
  \ Cybersecurity Belgium (CCB). The Framework is a set of concrete measures and offers\
  \ a clear, step-by-step approach that helps organisations to:\n\xB7 protect their\
  \ data,\n\xB7 significantly reduce their risk of the most common cyber-attacks,\n\
  \xB7 and improve their cyber resilience.\nThe requirements, also known as controls\
  \ or measures, are supported by relevant insights from the NIST Cybersecurity Framework1,\
  \ ISO 27001/ISO 27002, IEC 62443 and the CIS Critical security Controls (ETSI TR\
  \ 103305-1).\nhttps://cyfun.eu/sites/default/files/2025-10/CyFun2025_Booklet-ESSENTIAL.pdf\n\
  Version 2025-10-01"
copyright: "\u24B8 Centre for Cybersecurity Belgium (CCB)"
version: 3
publication_date: null
provider: CCB
packager: intuitem
objects:
  framework:
    urn: urn:intuitem:risk:framework:ccb-cyfun2025
    ref_id: cyfun2025
    name: CyberFundamentals 2025
    description: "The CyberFundamentals Framework is a framework owned by the Centre\
      \ for Cybersecurity Belgium (CCB). The Framework is a set of concrete measures\
      \ and offers a clear, step-by-step approach that helps organisations to:\n\xB7\
      \ protect their data,\n\xB7 significantly reduce their risk of the most common\
      \ cyber-attacks,\n\xB7 and improve their cyber resilience.\nThe requirements,\
      \ also known as controls or measures, are supported by relevant insights from\
      \ the NIST Cybersecurity Framework1, ISO 27001/ISO 27002, IEC 62443 and the\
      \ CIS Critical security Controls (ETSI TR 103305-1).\nhttps://cyfun.eu/sites/default/files/2025-10/CyFun2025_Booklet-ESSENTIAL.pdf\n\
      Version 2025-10-01"
    min_score: 1
    max_score: 5
    scores_definition:
    - score: 1
      name: Initial
      description: Standard process does not exist.
      description_doc: No Process documentation or not formally approved by management.
    - score: 2
      name: Repeatable
      description: Ad-hoc process exists and is done informally.
      description_doc: Formally approved Process documentation exists but not reviewed
        in the previous 2 years.
    - score: 3
      name: Defined
      description: 'Formal process exists and is implemented.

        Evidence available for most activities.

        Less than 10% process exceptions.'
      description_doc: 'Formally approved Process documentation exists, and exceptions
        are documented and approved.

        Documented & approved exceptions < 5% of the time.'
    - score: 4
      name: Managed
      description: 'Formal process exists and is implemented.

        Evidence available for all activities.

        Detailed metrics of the process are captured and reported.

        Minimal target for metrics has been established.

        Less than 5% of process exceptions.'
      description_doc: 'Formally approved Process documentation exists, and exceptions
        are documented and approved.

        Documented & approved exceptions < 3% of the time.'
    - score: 5
      name: Optimizing
      description: 'Formal process exists and is implemented.

        Evidence available for all activities.

        Detailed metrics of the process are captured and reported.

        Minimal target for metrics has been established and continually improving.

        Less than 1% of process exceptions.'
      description_doc: 'Formally approved Process documentation exists, and exceptions
        are documented and approved.

        Documented & approved exceptions < 0,5% of the time.'
    implementation_groups_definition:
    - ref_id: B
      name: basic
      description: null
    - ref_id: I
      name: important
      description: null
    - ref_id: E
      name: essential
      description: null
    - ref_id: BK
      name: basic - key measures
      description: null
    - ref_id: IK
      name: important - key measures
      description: null
    - ref_id: EK
      name: essential - key measures
      description: null
    - ref_id: BG
      name: basic - governance measures
      description: null
    - ref_id: IG
      name: important - governance measures
      description: null
    - ref_id: EG
      name: essential - governance measures
      description: null
    requirement_nodes:
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      assessable: false
      depth: 1
      ref_id: GV
      name: GOVERN
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      ref_id: GV.OC
      name: Organisational context
      description: "The circumstances \u2014 mission, stakeholder expectations, dependencies,\
        \ and legal, regulatory, and contractual requirements \u2014 surrounding the\
        \ organisation's cybersecurity risk management decisions are understood"
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc
      ref_id: GV.OC-01
      description: The organisational mission is understood and informs cybersecurityrisk
        management
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-01
      ref_id: GV.OC-01.1
      description: The organisation's mission shall be established, communicated and
        shall form the basis for information and cybersecurity risk management.
      annotation: "The goal of this control is to ensure that the organisation\u2019\
        s mission is clearly defined and communicated, and that it serves as the foundation\
        \ for managing information and cybersecurity risks. Understanding the mission\
        \ helps identify which risks could interfere with achieving strategic objectives.\n\
        \nTo achieve this goal, the following should be considered: \n\u0387  The\
        \ organisation\u2019s mission should be communicated through materials such\
        \ as vision and mission statements,  service strategies, or marketing documents.\
        \ This helps guide risk identification and prioritisation. \n\u0387  Business\
        \ processes and strategic goals should be developed with consideration for\
        \ information security and cybersecurity. This includes understanding how\
        \ risks may affect operations, assets, individuals, partners, or broader societal\
        \ interests. \n\u0387  The need to protect sensitive information, including\
        \ personal data, should be assessed based on the organisation\u2019s mission\
        \ and how its systems and services operate. \n\u0387  The mission and related\
        \ business processes should be reviewed regularly, for example once a year,\
        \ to ensure they remain relevant and continue to support effective risk management."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc
      ref_id: GV.OC-02
      description: Internal and external stakeholders are understood, and their needs
        and expectations regarding cybersecurity risk management are understood and
        considered
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-02
      ref_id: GV.OC-02.1
      description: The organisation shall demonstrate it understands and considers
        the needs and expectations of both internal and external stakeholders regarding
        information and cybersecurity risk management.
      annotation: "The goal of this control is to ensure that the organisation understands\
        \ and takes into account the needs and expectations of both internal and external\
        \ stakeholders when managing information and cybersecurity risks. This helps\
        \ to align cybersecurity efforts with business priorities, legal obligations,\
        \ and stakeholder trust. \n\nTo achieve this goal, the following should be\
        \ considered: \n\u0387  The organisation should identify key internal stakeholders\
        \ such as employees, senior management, board members, and internal auditors.\
        \ Their roles, responsibilities, and expectations related to cybersecurity\
        \ should  be understood and documented. \n\u0387  Key external stakeholders,\
        \ including customers, suppliers, partners, regulators, shareholders, service\
        \ providers, and external auditors, should be identified, and their compliance,\
        \ contractual, and data protection expectations should be considered. \n\u0387\
        \  Stakeholder needs and expectations should be gathered through methods such\
        \ as interviews, surveys, contract reviews, or regulatory analysis. \n\u0387\
        \  These insights should be integrated into the organisation\u2019s cybersecurity\
        \ risk management strategy to ensure alignment with business and regulatory\
        \ priorities. \n\u0387  Regular communication channels should be established\
        \ to keep stakeholders informed and engaged in cybersecurity matters. \n\u0387\
        \  Stakeholder expectations should be reviewed and updated periodically, especially\
        \ when there are changes in business operations, legal requirements, or risk\
        \ exposure."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc
      ref_id: GV.OC-03
      description: Legal, regulatory, and contractual requirements regarding cybersecurity
        are understood and managed
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-03.1
      description: Legal and regulatory requirements regarding information and cybersecurity
        shall be identified and implemented.
      annotation: "The goal of this control is to ensure that legal, regulatory, and\
        \ contractual requirements related to information security and cybersecurity\
        \ are identified, monitored, and implemented.\n\nTo achieve this goal, the\
        \ following should be considered: \n\u0387  A process should be established\
        \ to track and apply relevant legal and regulatory requirements related to\
        \ both information security and cybersecurity. \n\u0387  These requirements\
        \ should be integrated into all relevant policies, procedures, and operational\
        \ practices. \n\u0387  The areas that should be covered include, but are not\
        \ limited to: \n    \u0387  Risk assessments and protection of information\
        \ systems \n    \u0387  Incident response, business continuity, and crisis\
        \ management \n    \u0387  Supply chain security and secure system development\
        \ \n    \u0387  Vulnerability management and secure configuration \n    \u0387\
        \  Security awareness and training \n    \u0387  Cryptographic controls and\
        \ secure communications \n    \u0387  Emergency communication systems \n \
        \   \u0387  Access control, asset management, and Multi-Factor Authentication\
        \ (MFA) \n    \u0387  Coordinated vulnerability disclosure"
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-03.2
      description: Legal, regulatory, and contractual obligations related to information
        and cybersecurity shall be continuously managed to ensure they remain accurate,
        up to date, and effectively applied.
      annotation: "The goal of this control is to ensure that legal and regulatory\
        \ requirements related to information and cybersecurity are continuously managed,\
        \ kept up to date, and effectively applied across the organisation.\n\nTo\
        \ achieve this goal, the following should be considered: \n\u0387  A structured\
        \ process should be in place to manage legal and regulatory requirements related\
        \ to information and cybersecurity on an ongoing basis. \n\u0387  These requirements\
        \ should be documented, regularly reviewed, and updated to reflect changes\
        \ in laws and regulations. \n\u0387  The organisation\u2019s approach to compliance\
        \ should be clearly defined, including roles, responsibilities, and accountability.\
        \ \n\u0387  Mechanisms should be implemented to monitor changes in the legal\
        \ and regulatory landscape. Such changes should trigger a review of relevant\
        \ policies, procedures, and controls to ensure continued compliance. \n\u0387\
        \  Evidence of compliance activities should be maintained to support audits\
        \ and demonstrate due diligence."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-04.1
      description: The organisation shall identify, document, and communicate the
        critical objectives, capabilities, and services relied upon by external stakeholders,
        prioritise them based on criticality, and integrate this prioritisation into
        the risk assessment process
      annotation: "The goal of this control is to ensure that the organisation understands\
        \ which critical services, capabilities, and objectives are essential to external\
        \ stakeholders, prioritises them based on their importance, and includes them\
        \ in the risk assessment process. \n\nTo achieve this goal, the following\
        \ should be considered: \n\u0387  The focus of this control is on what the\
        \ organisation delivers to others, in other words, the services and functions\
        \ that external stakeholders depend on (the downstream supply chain, such\
        \ as customers, partners, or end users). \n\u0387  Critical services and the\
        \ internal functions that support them should be clearly identified. \n\u0387\
        \  Criteria should be defined to determine how important each service or capability\
        \ is, from both internal and external perspectives. \n\u0387  A business impact\
        \ analysis can help identify which assets and operations are vital to achieving\
        \ key objectives, and what the consequences would be if they were disrupted.\
        \ \n\u0387  Resilience goals, such as how quickly critical services should\
        \ recover during disruptions, should be established and communicated."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-04.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-04.2
      description: The organisation shall define and document cybersecurity requirements
        for essential operations, validate them through testing and audits, maintain
        records of results and corrective actions, and regularly update requirements
        based on evolving risks
      annotation: "The goal of this control is to ensure that essential operations\
        \ are protected by clearly defined and tested security measures, and that\
        \ these measures remain effective and up to date as risks evolve. \n\nTo achieve\
        \ this goal, the following actionable steps should be considered: \n\u0387\
        \  Identification & Documentation \n    \u0387  Define critical services and\
        \ their dependencies through a structured risk assessment. \n    \u0387  Document\
        \ security and operational requirements, including regulatory and industry-specific\
        \ needs (e.g. CyFun\xAE, ISO/IEC 27001, IEC 62443). \n\u0387  Validation &\
        \ Approval \n    \u0387  Establish governance processes for reviewing and\
        \ approving identified security requirements. \n    \u0387  Assign accountability\
        \ to relevant stakeholders (e.g. security teams, compliance officers, executive\
        \ leadership). \n\u0387  Testing & Assurance \n    \u0387  Conduct penetration\
        \ tests, vulnerability assessments, and incident simulations to validate implementation.\
        \ \n    \u0387  Ensure audits are performed to assess effectiveness and identify\
        \ gaps in security measures. \n    \u0387  Implement corrective actions where\
        \ deficiencies are found, ensuring continuous improvement. \n\u0387  Record-Keeping\
        \ & Compliance \n    \u0387  Maintain detailed documentation of testing procedures,\
        \ results, approvals, and corrective measures. \n    \u0387  Align security\
        \ frameworks with regulatory obligations to ensure compliance and governance\
        \ oversight. \n    \u0387  Continuous Review & Adaptation \n    \u0387  Regularly\
        \ reassess requirements in response to evolving threats, incidents, and regulatory\
        \ changes. \n    \u0387  Ensure governance bodies oversee updates and improvements\
        \ to maintain long-term cyber resilience."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-04.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-04.3
      description: Redundancy shall be implemented to meet availability requirements
        as defined by the organisation, legislation and/or regulations
      annotation: "The goal of this control is to ensure that critical systems and\
        \ services remain available by implementing redundancy in line with organisational,\
        \ legal, and regulatory availability requirements. \n\nTo achieve this goal,\
        \ the following should be considered: \n\u0387  The focus of this control\
        \ is on ensuring that essential services continue to operate even if part\
        \ of the system fails. \n\u0387  Redundancy should be built into key components\
        \ such as data storage, network infrastructure, and critical systems. Examples\
        \ include: \n    \u0387  Backup servers, load balancers, RAID arrays, and\
        \ multiple data centres \n    \u0387  Failover internet connections and multiple\
        \ internet service providers (ISPs) \n\u0387  Critical equipment and services\
        \ should be protected against power failures and utility disruptions using:\
        \ \n    \u0387  Uninterruptible  Power  Supplies  (UPS),  backup  generators,\
        \  and  redundant  power  cabling,  2  different power service providers\u200A\
        \u2026 \n    \u0387  Regular testing and maintenance contracts to ensure reliability"
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-04.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-04.4
      description: Recovery time and recovery point objectives for the resumption
        of essential ICT/OT system processes shall be defined and monitored.
      annotation: "The goal of this control is to ensure that the organisation defines\
        \ and monitors clear Recovery Time Objectives (RTO) and Recovery Point Objectives\
        \ (RPO) for restoring essential ICT and OT system processes after a disruption.\
        \ \n\nConsider the following elements for defining and monitoring RTO\u2019\
        s and RPO\u2019s for critical ICT/OT systems: \n\u0387  Governance & Policy\
        \ Definition \n    \u0387  Establish formal policies and accountability for\
        \ defining and monitoring RTO/RPO. \n    \u0387  Align recovery objectives\
        \ with business continuity and disaster recovery frameworks (e.g., ISO 22301,\
        \ ISO/IEC 27031). \n    \u0387  Ensure leadership buy-in and regulatory compliance.\
        \ \n\u0387  Business Impact Analysis (BIA) \n    \u0387  Identify interdependencies\
        \ between ICT and OT systems and their cascading effects on business operations.\
        \ \n    \u0387  Determine acceptable downtime thresholds for different system\
        \ categories. \n\u0387  Risk & Threat Assessment \n    \u0387  Perform real-world\
        \ threat simulations (e.g., ransomware drills, DDoS stress testing). \n  \
        \  \u0387  Integrate threat intelligence into recovery planning to anticipate\
        \ evolving risks. \n    \u0387  Classification & Prioritisation of Systems\
        \ \n    \u0387  Define tiered recovery strategies based on business impact\
        \ (e.g., Tier 1 = immediate restoration, Tier 2 = delayed recovery). \n  \
        \  \u0387  Establish failover mechanisms for critical OT processes that must\
        \ operate continuously. \n\u0387  Backup & Recovery Strategies \n    \u0387\
        \  Implement immutable backups to protect against ransomware. \n    \u0387\
        \  Ensure offsite and cloud-based recovery options for geographic resilience.\
        \ \n    \u0387  Conduct regular validation and integrity checks on backups\
        \ to prevent failures during recovery. \n\xB7 Testing & Validation of Recovery\
        \ Objectives\n    \xB7 Perform disaster recovery testing (tabletop exercises,\
        \ full restoration drills).\n    \xB7 Measure RTO/RPO effectiveness through\
        \ real-time monitoring and incident response simulations.\n    \xB7 Establish\
        \ automated recovery orchestration to speed up resumption of services.\n\xB7\
        \ Continuous Monitoring & Improvement\n    \xB7 Use real-time analytics to\
        \ assess deviations from expected RTO/RPO values.\n    \xB7 Adapt recovery\
        \ objectives based on lessons learned from incidents and audits."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.oc-03
      ref_id: GV.OC-05.1
      description: The organisation shall identify, document, and communicate its
        role in the supply chain, including the external capabilities, services, and
        dependencies it relies on (upstream), as well as its interactions with downstream
        stakeholders.
      annotation: "The goal of this control is to ensure the organisation identifies,\
        \ documents, and communicates its role within the supply chain by understanding\
        \ the external capabilities, services, and dependencies it relies on (upstream),\
        \ while also recognising its interactions with downstream stakeholders. \n\
        \nThis control focuses primarily on the upstream supply chain, what the organisation\
        \ depends on from others, while maintaining  alignment with GV.OC-04, which\
        \ addresses what the organisation delivers to others. Together, they provide\
        \ a complete view of supply chain dependencies and responsibilities. \n\n\
        To support this control, the following should be considered: \n\u0387  The\
        \ organisation\u2019s role in the supply chain should be clearly defined,\
        \ including both what is delivered to others (downstream) and what is received\
        \ from external sources (upstream). \n\u0387  Dependencies on external resources\
        \ \u2014 such as facilities, cloud providers, and suppliers of services, products,\
        \ or capabilities \u2014 should be identified and documented. \n\u0387  These\
        \ dependencies should be mapped to related business functions and organisational\
        \ assets to understand their impact on operations. \n\u0387  Particular attention\
        \ should be given to external dependencies that represent potential points\
        \ of failure for critical services or capabilities. \n\u0387  This information\
        \ should be shared with relevant personnel and stakeholders to support risk\
        \ management, continuity planning, and coordinated response. \n\u0387  Communication\
        \ channels should be established to ensure that supply chain roles and dependencies\
        \ are clearly understood across the organization and with key partners."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      ref_id: GV.RM
      name: Risk Management Strategy
      description: The organisation's priorities, constraints, risk tolerance and
        appetite statements, and assumptions, are established, communicated, and used
        to support operational risk decisions
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm
      ref_id: GV.RM-01
      description: Risk management objectives are established and agreed to by organisational
        stakeholders
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-01
      ref_id: GV.RM-01.1
      description: Information/cybersecurity objectives shall be identified, agreed
        to by organisational stakeholders and approved by senior management
      annotation: "To support this objective, organisations should: \n\u0387  Follow\
        \ the risk management principles outlined in ISO/IEC 27005, which provide\
        \ guidance on identifying, assessing, and mitigating information security\
        \ risks. Specifically: \n    \u0387  Clause 6.1 should be used to establish\
        \ a structured risk assessment process. \n    \u0387  Clause 6.3 should guide\
        \ the definition of appropriate risk treatment strategies. \n\u0387  Update\
        \ near-term and long-term information and cybersecurity objectives during\
        \ annual strategic planning and in response to major organisational changes.\
        \ \n\u0387  In OT-sector organisations, senior management should consider\
        \ health, safety, and environmental factors when identifying risks. \n\u0387\
        \  Establish measurable (SMART) objectives for information and cybersecurity\
        \ (e.g., improving user training quality, ensuring adequate protection for\
        \ industrial control systems). \n\u0387  Use these objectives to measure and\
        \ manage risk and performance across the organisation."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm
      ref_id: GV.RM-02
      description: Risk appetite and risk tolerance statements are established, communicated,
        and maintained
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-02
      ref_id: GV.RM-02.1
      description: Risk appetite and risk tolerance statements shall be defined, documented,
        approved by senior management, communicated, and maintained.
      annotation: "The goal of GV.RM-02.1 is to ensure that an organisation has a\
        \ clear and actionable understanding of its risk boundaries, which helps guide\
        \ decision-making and risk management practices.\n\nThe following should be\
        \ considered to reach this goal: \n\u0387  Risk appetite is the amount and\
        \ type of risk an organisation is willing to take or accept, and is strategic/qualitative\
        \ (Source: ISO/IEC 27005). \n\u0387  Risk tolerance is the acceptable deviation\
        \ from the level set by the risk appetite and business objectives, and is\
        \ tactical/quantitative (source: ISACA). \n\u0387  The organisation's risk\
        \ appetite should take into account its role in critical infrastructure and\
        \ its sector. \n\u0387  Organisations in the OT sector should take into account\
        \ health, safety & environment priorities in the definition of their risk\
        \ appetite. \n\u0387  Risk appetite statements should be translated into specific,\
        \ measurable, and broadly understandable risk tolerance statements (SMART).\
        \ \n\u0387  Organisational objectives and risk appetite should be periodically\
        \ refined based on known risk exposure and residual risk. \n\u0387  With AR-in-a-Box,\
        \ ENISA, the European Union Agency for Cybersecurity, provides organisations\
        \ with the essential tools and resources to effectively raise cybersecurity\
        \ awareness within their operations. This ENISA- Do-It-Yourself Toolbox contains\
        \ a C-level guide."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm
      ref_id: GV.RM-03
      description: Cybersecurity risk management activities and outcomes are included
        in enterprise risk management processes
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-03
      ref_id: GV.RM-03.1
      description: As part of the organisation-wide risk management strategy, a comprehensive
        strategy to manage information and cybersecurity risks shall be developed
        and updated when changes occur.
      annotation: "This control focuses on the creation and maintenance of a specific\
        \ strategy for managing information and cybersecurity risks. It ensures that\
        \ the organisation has a dedicated, actionable plan that evolves with the\
        \ threat landscape. \n\nTo make this happen, the following should be considered:\
        \ \n\u0387  An organisation-wide risk management strategy includes an expression\
        \ of the security risk tolerance for the organisation, security risk mitigation\
        \ strategies, acceptable risk assessment methodologies, a process for evaluating\
        \ security risk across the organisation with respect to the organisation's\
        \ risk tolerance, and approaches for monitoring risk over time. \n\u0387 \
        \ Information and Cybersecurity risks should be aggregated and managed alongside\
        \ other organisation risks (e.g., compliance, financial, operational, regulatory,\
        \ reputational, safety). \n\u0387  The information and cybersecurity risk\
        \ management strategy should include identifying and allocating the necessary\
        \ resources to protect the organisation's business-critical assets. \n\u0387\
        \  This is the cybersecurity-specific implementation of the broader vision\
        \ defined in GV.RM-04.1"
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-03.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-03
      ref_id: GV.RM-03.2
      description: Information and Cybersecurity risks shall be documented, as part
        of the enterprise risk management processes, formally approved by senior management,
        and updated when changes occur.
      annotation: "This control should ensure that the strategy is put into action\
        \ through structured processes. It focuses on operational and governance level,\
        \ ensures accountability and traceability of risks, and emphasises formal\
        \ processes and oversight.\nThe following actionable components should be\
        \ considered while implementing this control: \n\nSystematic Risk Identification\
        \ \n\u0387  Goal: Proactively identify information and cybersecurity risks\
        \ across the organisation. \n\u0387  Actions: \n    \u0387  Regular risk assessments\
        \ should be conducted using methods like threat modelling, risk workshops,\
        \ and vulnerability scans. \n    \u0387  Risks related to all digital and\
        \ physical assets (hardware, software, data, networks) should be included\
        \ in the asset inventory, along with key metadata (location, owner, usage).\
        \ \n    \u0387  Leverage sources such as: \n        \u0387  Security incident\
        \ logs \n        \u0387  Penetration test results \n        \u0387  Regulatory\
        \ requirements \n        \u0387  Industry threat intelligence \n\u0387  Consider\
        \ involving cross-functional teams (IT/OT, legal, compliance, business units).\
        \ \n\u0387  Tools to Consider: \n    \u0387  Risk assessment templates \n\
        \    \u0387  Threat intelligence platforms (e.g., MISP, Recorded Future) \n\
        \    \u0387  Asset inventories and data flow diagrams \n\nRisk Documentation\
        \ in the ERM Framework \n\u0387  Goal: Ensure cybersecurity risks are integrated\
        \ into the broader Enterprise Risk Management (ERM) process. \n\u0387  Actions:\
        \ \n    \u0387  Consider using a centralised risk register or GRC tool to\
        \ document: \n        \u0387  Risk description \n        \u0387  Likelihood\
        \ and impact \n        \u0387  Risk owner \n        \u0387  Controls in place\
        \ \n        \u0387  Residual risk \n        \u0387  Treatment plan \n    \u0387\
        \  Cybersecurity risk management should be aligned with strategic business\
        \ objectives to ensure relevance and support. \n\u0387  Tools to Consider:\
        \ \n    \u0387 GRC platforms \n    \u0387 Excel/SharePoint (for smaller organisations)\n\
        \nFormal Approval and Senior Management Involvement\n\xB7 Goal: Ensure leadership\
        \ oversight and accountability in risk decisions.\n\xB7 Actions:\n    \xB7\
        \ Risk assessments and treatment plans should be presented to a Risk Committee\
        \ or Executive Board.\n    \xB7 Consider including cybersecurity risks in\
        \ quarterly risk reports.\n    \xB7 Formal sign-off should be obtained on:\n\
        \        \xB7 Risk acceptance\n        \xB7 Mitigation plans\n        \xB7\
        \ Budget allocations\n\xB7 Tools to Consider:\n    \xB7 Board reporting templates\n\
        \    \xB7 Risk dashboards\n    \xB7 Meeting minutes with documented approvals\n\
        \nCommunication and Awareness\n\xB7 Goal: Ensure all relevant stakeholders\
        \ are informed and engaged.\n\xB7 Actions:\n    \xB7 Clear lines of communication\
        \ should be established for cybersecurity risks, including those from suppliers\
        \ and third parties.\n    \xB7 Approved risks and mitigation strategies should\
        \ be communicated to relevant teams.\n    \xB7 Awareness should be promoted\
        \ through training, briefings, and internal communications.\n\xB7 Tools to\
        \ Consider:\n    \xB7 Internal communication platforms (e.g., Teams, Slack)\n\
        \    \xB7 Risk communication plans\n    \xB7 Stakeholder maps\n\nContinuous\
        \ Monitoring and Updates\n\xB7 Goal: Keep risk information current and responsive\
        \ to change.\n\xB7 Actions:\n    \xB7 Continuous monitoring should be implemented\
        \ to detect changes in the threat landscape or organisational environment.\n\
        \    \xB7 Consider defining triggers for updates, such as:\n        \xB7 New\
        \ threats or vulnerabilities\n        \xB7 Changes in business processes or\
        \ IT systems\n        \xB7 Regulatory changes\n    \xB7 A change management\
        \ process should be established that includes updating cybersecurity documentation.\n\
        \    \xB7 Regular reviews should be conducted (e.g., quarterly or twice a\
        \ year) of documented risks.\n\xB7 Tools to Consider:\n    \xB7 Change management\
        \ systems\n    \xB7 Continuous monitoring tools\n    \xB7 Risk review calendars\n\
        \nThis control operationalises GV.RM-03.1 by embedding cybersecurity risks\
        \ into the Enterprise Risk Management (ERM) framework and ensuring governance\
        \ and accountability."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm
      ref_id: GV.RM-04
      description: Strategic direction that describes appropriate risk response options
        is established and communicated
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-04
      ref_id: GV.RM-04.1
      description: A high-level plan or vision shall be formally established and clearly
        communicated to everyone involved on how to manage risks, including the different
        strategies the organisation can employ to deal with identified risks based
        on risk appetite or risk tolerance level.
      annotation: "The aim of this control is to set the strategic foundation for\
        \ risk management, including:\n\xB7 Risk tolerance and appetite,\n\xB7 Strategic\
        \ direction for managing risks (e.g., mitigate, transfer, accept),\n\xB7 Ensuring\
        \ alignment across departments.\n\xB7 Ensuring that everyone in the organisation\
        \ understands the big picture of how risks are approached and managed\n\n\
        The control focus on:\n\xB7 Strategic and organisational -level risk management.\n\
        \xB7 Establishing a formal, overarching vision or plan.\n\xB7 Communicating\
        \ risk management strategies (e.g., avoid, mitigate, transfer, accept).\n\xB7\
        \ Applies to all types of risks, not just cybersecurity.\n\nIn relation to\
        \ the controls GV.RM-03.1, GV.RM-03.2 and GV.RM-05.1, this control is the\
        \ starting point; it defines the organisation's risk philosophy, including\
        \ appetite and tolerance, which guides all other activities."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm
      ref_id: GV.RM-05
      description: Lines of communication across the organisation are established
        for cybersecurity risks, including risks from suppliers and other third parties
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rm-05
      ref_id: GV.RM-05.1
      description: To support the high-level risk management vision, the organisation
        shall establish clear lines of communication for cybersecurity risks, including
        those arising from suppliers and third parties.
      annotation: "The aim of this control is to ensure that cybersecurity and information\
        \ security risk information is shared effectively across the organisation\
        \ and with external parties. \n\nThis control focus on operational and tactical\
        \ communication is specific to cybersecurity risks and emphasises communication\
        \ channels (e.g., reporting, escalation, coordination), including external\
        \ risks from suppliers and third parties. \n\nConsider the following elements\
        \ when implementing this control: \n\u0387  Define Communication Roles and\
        \ Responsibilities \n    Assign clear ownership for reporting, escalating,\
        \ and responding to cybersecurity risks across departments and with third\
        \ parties. \n\u0387  Establish Communication Channels \n    Use structured\
        \ channels such as email groups, ticketing systems, incident response platforms,\
        \ or collaboration tools (e.g., Teams, Slack) for timely risk communication.\
        \ \n\u0387  Include Third Parties \n    Integrate suppliers and partners into\
        \ the communication process through contractual clauses, shared reporting\
        \ protocols, or joint incident response plans. \n\u0387  Document and Train\
        \ \n    Maintain a communication protocol or playbook and train relevant staff\
        \ on how and when to report cybersecurity risks. \n\u0387  Review and Improve\
        \ \n    Periodically test and review communication effectiveness through tabletop\
        \ exercises or post-incident reviews.\n\nThis control supports the implementation\
        \ of GV.RM-03.2 by ensuring that identified and documented risks are communicated\
        \ to the right stakeholders, enabling timely response and coordination."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      ref_id: GV.RR
      name: Roles, Responsibilities and Authorities
      description: Cybersecurity roles, responsibilities, and authorities to foster
        accountability, performance assessment, and continuous improvement are established
        and communicated
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr
      ref_id: GV.RR-01
      description: Organisational leadership is responsible and accountable for cybersecurity
        risk and fosters a culture that is risk-aware, ethical, and continually improving
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-01
      ref_id: GV.RR-01.1
      description: Organisation's top management shall be responsible and accountable
        for cybersecurity risk and shall foster a culture that is risk-aware, ethical,
        and continually improving.
      annotation: "The goal of this control is to ensure top management is accountable\
        \ for cybersecurity risk and promotes a risk-aware and continuously-improving\
        \ culture.\n\nTo make this happen, the following should be considered: \n\u0387\
        \  Organisations' top management should agree on their roles and responsibilities\
        \ in developing, implementing, and assessing the organisation\u2019s cybersecurity\
        \ strategy. \n\u0387  The expectations of organisations top management regarding\
        \ a secure culture, including highlighting positive or negative examples of\
        \ cybersecurity risk management, should be shared with the entire organisation.\
        \ \n\u0387  Organisations top management should direct the senior-level executive\
        \ (information) security officer (e.g. CSO, CISO) to maintain a comprehensive\
        \ cybersecurity risk strategy and review and update it at least annually and\
        \ after major events (see also GV.RR-02.2). \n\u0387  Reviews should be conducted\
        \ to ensure adequate authority and coordination among those responsible for\
        \ managing cybersecurity risk."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr
      ref_id: GV.RR-02
      description: Roles, responsibilities, and authorities related to cybersecurity
        risk management are established, communicated, understood, and enforced
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-02
      ref_id: GV.RR-02.1
      description: Information security and cybersecurity roles, responsibilities
        and authorities for employees, suppliers, customers, and partners shall be
        documented, reviewed, authorised, kept up to date, communicated, and coordinated
        internally and externally.
      annotation: "The goal of this control is to ensure all internal and external\
        \ parties understand and fulfil their cybersecurity roles, responsibilities\
        \ and authorities, reducing gaps, overlaps, and delays in incident response\
        \ and compliance.\n\nIt should be considered to: \n\u0387  Describe security\
        \ roles, responsibilities, and authorities: who in the organisation should\
        \ be consulted, informed, held responsible and accountable for all or part\
        \ of the enterprise assets. Use of the RACI model can be considered. Guidance\
        \ can also be found in the ENISA European Cybersecurity Skills Framework Role\
        \ Profiles (https://www.enisa.europa.eu/publications/european-cybersecurity-skills-framework-role-profiles).\
        \ \n\u0387  Include risk management roles, responsibilities, and authorities.\
        \ \n\u0387  Include information/cybersecurity responsibilities and performance\
        \ requirements in personnel descriptions. \n\u0387  Clearly articulate information/cybersecurity\
        \ responsibilities within operations, risk functions, and internal audit functions.\
        \ \n\u0387  Identify one or more specific roles or positions that will be\
        \ responsible and accountable for planning, resourcing, and executing information/cybersecurity\
        \ supply chain risk management activities. \n\u0387  Follow the previous guideline,\
        \ extend internal security roles, responsibilities, and authorities to the\
        \ information/cybersecurity supply chain risk management roles, responsibilities,\
        \ and authorities. \n\u0387  Develop roles, responsibilities, and authorities\
        \ for suppliers, customers, and business partners to address shared responsibilities\
        \ for applicable information/cybersecurity risks, and integrate them into\
        \ organisational policies and applicable third-party agreements. \n\u0387\
        \  Internally communicate information/cybersecurity supply chain risk management\
        \ roles and responsibilities for third parties. \n\u0387  Establish rules\
        \ and protocols for information sharing and reporting processes between the\
        \ organisation and its suppliers. \n\u0387  Consider a clear distinction between\
        \ IT (Information Technology) and OT (Operational Technology) in the implementation\
        \ of this control by taking the following into account: \n    \u0387  Roles\
        \ and Responsibilities \n        \u0387  IT: Define roles such as system administrator,\
        \ network security analyst, incident responder. \n        \u0387  OT: Define\
        \ roles such as control system engineer, OT cybersecurity lead, plant operator.\
        \ \n    \u0387  Documentation and Review \n        \u0387  Ensure both IT\
        \ and OT roles are documented separately but aligned. \n        \u0387  Review\
        \ cycles may differ: IT (quarterly/annually), OT (aligned with maintenance\
        \ windows). \n    \u0387  Authorisation and Updates \n        \u0387  Ensure\
        \ both IT and OT documentation is approved by relevant leadership (e.g., CIO\
        \ for IT, Plant Manager \nfor OT). \n        \u0387  Updates in OT may require\
        \ change control procedures due to safety implications. \n    \u0387  Communication\
        \ and Coordination \n        \u0387  Internal: Ensure IT and OT teams have\
        \ joint incident response plans. \n        \u0387  External: Include suppliers\
        \ and partners specific to OT (e.g., ICS vendors) and IT (e.g., cloud providers)."
      implementation_groups:
      - I
      - IK
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-02
      ref_id: GV.RR-02.2
      description: The organisation shall appoint a senior-level executive information
        security officer.
      annotation: "The goal of this control is to establish clear executive accountability\
        \ for cybersecurity by appointing a senior leader to drive strategy, oversight,\
        \ and alignment with business objectives.\n\nTo achieve this goal, the following\
        \ should be considered: \n\u0387  A senior executive is defined as a high-ranking\
        \ member of the organisation involved in major decision-making processes.\
        \ \n\u0387  The senior-level executive information security officer, which\
        \ could be the Chief Information Security Officer (CISO), should have the\
        \ authority, responsibility and resources to coordinate, develop, implement,\
        \ monitor, and maintain an organisation-wide vision, strategy, and program\
        \ to ensure that information assets and technologies are adequately protected."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr
      ref_id: GV.RR-03
      description: Adequate resources are allocated commensurate with the cybersecurity
        risk strategy, roles, responsibilities, and policies
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-03-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-03
      ref_id: GV.RR-03-1
      description: Sufficient resources shall be allocated in line with the cybersecurity
        risk strategy, roles, responsibilities and policies.
      annotation: "The goal of this control is to ensure that cybersecurity is effectively\
        \ supported by aligning resource allocation with strategic priorities, roles,\
        \ and policies. To make this happen, the following should be considered:\n\
        \xB7 Periodic management reviews should be conducted to ensure that those\
        \ with cybersecurity risk management responsibilities have the necessary authority.\n\
        \xB7 Resource allocation and investment should be determined in line with\
        \ the organisation's risk appetite\n\xB7 Adequate and sufficient people, processes\
        \ and technical resources should be ensured to support the cyber security\
        \ strategy\n\xB7 Expert personnel should have the specialised knowledge and\
        \ skills required for OT security to enable collaboration with OT engineers\
        \ so that alerts are interpreted accurately and threats are responded to effectively."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-03-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-03
      ref_id: GV.RR-03-2
      description: The organisation shall assign roles and responsibilities for reviewing
        and updating response and recovery plans, ensuring they reflect changes in
        the risk environment and remain effective.
      annotation: "The goal of this control is to ensure response and recovery plans\
        \ remain effective by assigning roles and responsibility for their regular\
        \ review and adaptation to evolving risks.\n\nTo implement this control, the\
        \ following elements should be considered:\n\xB7 Define and Assign Responsibilities\n\
        \xB7 Assign clear roles for maintaining, reviewing, and updating response\
        \ and recovery plans.\n\xB7 Ensure responsible individuals have the authority\
        \ and resources to act on identified changes.\n\xB7 Designate a central coordinator\
        \ or team to oversee the update process and ensure accountability.\n\xB7 Understand\
        \ and Monitor Organisational Context\n\xB7 Regularly assess internal and external\
        \ factors such as:\n    \xB7 Organisational structure and critical systems\n\
        \    \xB7 Emerging threats and vulnerabilities\n    \xB7 Regulatory changes\
        \ and market dynamics\n    \xB7 Lessons learned from incidents, tests, or\
        \ exercises\n\xB7 Update Plans Based on Contextual Changes\n\xB7 Revise plans\
        \ to reflect:\n    \xB7 New or evolving threats\n    \xB7 Changes in technology\
        \ or infrastructure\n    \xB7 Operational challenges or gaps identified during\
        \ testing\n\xB7 Updates may include contact lists, communication protocols,\
        \ escalation paths, and resource allocations.\n\xB7 Communicate and Train\n\
        \xB7 Ensure all relevant stakeholders are informed of updates.\n\xB7 Provide\
        \ training or briefings to clarify roles and responsibilities in the revised\
        \ plans.\n\xB7 Test and Improve\n\xB7 Conduct regular exercises and simulations\
        \ to validate the effectiveness of updated plans.\n\xB7 Use results to identify\
        \ gaps and drive continuous improvement.\n\xB7 Continuous Review Cycle\n\xB7\
        \ Establish a review schedule (e.g. quarterly or after major changes).\n\xB7\
        \ Integrate plan updates with broader risk management and governance processes."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr
      ref_id: GV.RR-04
      description: Cybersecurity is included in human resources practices
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-04
      ref_id: GV.RR-04.1
      description: "Personnel with access to the organisation\u2019s most critical\
        \ information or technology shall be authenticated."
      annotation: "The goal of this control is protecting critical assets by ensuring\
        \ only authenticated personnel can access them.\n\nTo achieve this, the following\
        \ should be considered: \n\u0387  \u201CAuthenticated\u201D means the user\
        \ must technically prove their identity at the point of access, ideally using\
        \ MFA or stronger methods, not just be validated during onboarding. \n\u0387\
        \  The access to critical information or technology should be considered during\
        \ recruitment, onboarding, during employment, change of function and when\
        \ offboarding (termination of employment). \n\u0387  Background verification\
        \ checks should be conducted prior to onboarding new personnel for sensitive\
        \ roles, and background checks should be periodically repeated for personnel\
        \ with such roles. Background verification checks should however take into\
        \ account applicable laws, regulations, and ethics in proportion to the business\
        \ requirements, the classification of the information to be accessed and the\
        \ perceived risks. \n\u0387  Cybersecurity expertise should be recognised\
        \ as a valuable asset in recruitment, training, and retention decisions."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-04.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.rr-04
      ref_id: GV.RR-04.2
      description: A cybersecurity process for human resources shall be developed
        and maintained applicable at recruitment, during employment and at termination
        of employment.
      annotation: "The goal of this control is to ensure cybersecurity risks are managed\
        \ throughout the employee lifecycle by integrating security into HR processes,\
        \ from hiring to termination.\n\nTo make this happen, the following should\
        \ be considered:\n\u0387  Cybersecurity  risk  management  considerations\
        \  should  be  integrated  into  human  resources  processes (e.g., personnel\
        \ screening, onboarding, change notification, offboarding) \n\u0387  The human\
        \ resource cybersecurity process should include access to critical information\
        \ or technology; background verification checks; code of conduct; roles, authorities,\
        \ and responsibilities\u2026 \n\u0387  Obligations for personnel to be aware\
        \ of, adhere to and uphold security policies in relation to their role should\
        \ be defined and enforced."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      ref_id: GV.PO
      name: Policy
      description: Organisational cybersecurity policy is established, communicated,
        and enforced
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po
      ref_id: GV.PO-01
      description: Policy for managing cybersecurity risks is established based on
        organisational context, cybersecurity strategy, and priorities and is communicated
        and enforced
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po-01
      ref_id: GV.PO-01.1
      description: Policies and procedures for managing information and cybersecurity
        shall be established, documented, reviewed, approved, updated when changes
        occur, communicated and enforced.
      annotation: "This control sets the foundation for how all information and cybersecurity\
        \ policies and procedures should be managed. It emphasises the governance\
        \ lifecycle, from creation to enforcement, and ensures alignment with the\
        \ organisation's strategic direction. \n\nTo effectively implement this control,\
        \ consider the following practices: \n\u0387  Develop clear and practical\
        \ policies, processes, and procedures which: \n    \u0387  Define acceptable\
        \ behaviours and expectations for protecting the organisation\u2019s information\
        \ and systems. \n    \u0387  Outline how management expects employees to use\
        \ and safeguard company resources. \n\u0387  Ensure employee awareness by\
        \ communicating these policies, processes, and procedures: \n    \u0387  During\
        \ onboarding of new personnel. \n    \u0387  Whenever significant updates\
        \ or changes are made. \n\u0387  Maintain accessibility by making all relevant\
        \ documents easily available to employees. \n\u0387  Review and update regularly\
        \ (e.g. annually) to reflect: \n    \u0387  Organisational changes, such as\
        \ mergers, acquisitions, or new contractual obligations. \n    \u0387  Technological\
        \ developments, such as the adoption of artificial intelligence or new security\
        \ tools. \n\u0387  Define risk assessment criteria within the organisation\u2019\
        s risk management policy: \n    \u0387  The entity should establish and document\
        \ clear criteria for determining the probability and impact of risks. \n \
        \   \u0387  These criteria should be tailored to the organisation\u2019s specific\
        \ context and used consistently to evaluate and prioritise cybersecurity risks.\
        \ This ensures that risk-based decisions are aligned with the organisation\u2019\
        s overall strategy and risk appetite."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.po-01
      ref_id: GV.PO-01.2
      description: Organisational-wide information and cybersecurity policies and
        procedures shall include the use of cryptography and, where appropriate, encryption,
        reflect changes in requirements, threats, technology and organisational roles,
        and be approved by senior management, who oversee its implementation.
      annotation: "This control builds further on GV.PO-01.1 and focuses on the content\
        \ and oversight of the cyber- and information security policies themselves.\
        \ It ensures that specific technical topics (such as cryptography and encryption)\
        \ are addressed, policies are responsive to change and Senior leadership is\
        \ actively involved in approval and oversight.\n\nConsider the following elements\
        \ to be covered:\n\xB7 Define Scope & Objectives\n\xB7 Ensure policies apply\
        \ organisation-wide and align with business and risk priorities.\n\xB7 Include\
        \ Cryptography & Encryption\n\xB7 Address encryption at-rest/in-transit, key\
        \ management, and approved algorithms.\n\xB7 Define where encryption is required\
        \ (e.g., personal data, remote access).\n\xB7 Keep Policies Current\n\xB7\
        \ Update policies to reflect changes in:\n    \xB7 Legal/regulatory requirements\n\
        \    \xB7 Threat landscape\n    \xB7 Technology\n    \xB7 Organisational structure\n\
        \xB7 Senior Management Oversight\n\xB7 Require formal approval by senior leadership.\n\
        \xB7 Assign a policy owner (e.g., CISO) to oversee implementation and compliance.\n\
        \xB7 Assign Roles & Responsibilities\n\xB7 Use ENISA ECSF Role Profiles (https://www.enisa.europa.eu/publications/european-cybersecurity-skills-framework-role-profiles)\
        \ to:\n    \xB7 Define cybersecurity roles (e.g., Policy Officer, Risk Manager)\n\
        \    \xB7 Align tasks, skills, and competencies\n\xB7 Communicate & Train\n\
        \xB7 Disseminate policies and provide role-specific training.\n\xB7 Monitor\
        \ & Enforce\n\xB7 Use technical controls and audits to ensure compliance."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      ref_id: GV.OV
      name: Oversight
      description: Results of organisation-wide cybersecurity risk management activities
        and performance are used to inform, improve, and adjust the risk management
        strategy
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov
      ref_id: GV.OV-02
      description: The cybersecurity risk management strategy is reviewed and adjusted
        to ensure coverage of organisational requirements and risks
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov-02
      ref_id: GV.OV-02.1
      description: The information and cybersecurity risk management strategy shall
        be reviewed and adjusted to ensure coverage of organisational requirements
        and risks.
      annotation: "The goal of this control is to ensure that the information and\
        \ cybersecurity risk management strategy is regularly reviewed and updated\
        \ to reflect organisational needs, evolving risks, and compliance requirements.\
        \ \n\nTo achieve this goal, the following should be considered: \n\u0387 \
        \ The strategy should define the overall direction and goals for managing\
        \ information and cybersecurity risks. \n\u0387  Supporting policies and procedures\
        \ should guide how the strategy is implemented in practice. \n\u0387  The\
        \ strategy should address risks to organisational operations, assets, individuals,\
        \ and other entities, including potential privacy impacts. \n\u0387  Reviews\
        \ should be conducted at planned intervals, including through internal audits,\
        \ based on a documented audit program that defines frequency, methods, responsibilities,\
        \ and reporting. \n\u0387  Audits should be carried out by competent and impartial\
        \ personnel. \n\u0387  Audit results should be reviewed to assess whether\
        \ the strategy meets internal expectations and complies with legal and regulatory\
        \ requirements. \n\u0387  The strategy should be updated when necessary, especially\
        \ after incidents or audit findings.\n\u0387  Evidence of audit activities\
        \ and outcomes should be documented and reported to relevant management."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov
      ref_id: GV.OV-03
      description: Organisational cybersecurity risk management performance is evaluated
        and reviewed for adjustments needed
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.ov-03
      ref_id: GV.OV-03.1
      description: The organisation's cybersecurity risk management performance shall
        be evaluated, reviewed and adjusted when necessary
      annotation: "The goal of this control is to ensure that an organisation's cybersecurity\
        \ risk management performance is continuously evaluated, reviewed, and adjusted\
        \ as necessary. \n\nTo achieve this goal, the following should be considered:\
        \ \n\u0387  Key Performance Indicators (KPIs) should be identified, implemented\
        \ and regularly reviewed to ensure that organisation-wide policies and procedures\
        \ achieve the information- and cybersecurity objectives. \n\u0387  Key information\
        \ and cybersecurity-related risk indicators should be regularly assessed to\
        \ identify risks to the organisation, including likelihood and potential impact.\
        \ Information and cybersecurity-related risk indicators are for example: \n\
        \    \u0387  Number of cyber-attacks detected \n    \u0387  Number of data\
        \ leaks detected \n    \u0387  Time to detection \n    \u0387  Time to recovery\
        \ \n    \u0387  Number of devices not managed by the organisation \n    \u0387\
        \  Level of access different users have to sensitive data \n    \u0387  Number\
        \ of not-up-to-date software and systems \n    \u0387  Number of unmanaged\
        \ network connections\n\u0387  Metrics on information- and cybersecurity risk\
        \ management should be collected and shared with senior leadership."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv
      ref_id: GV.SC
      name: Cybersecurity supply chain risk management
      description: Cyber supply chain risk management processes are identified, established,
        managed, monitored, and improved by organisational stakeholders
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-01
      description: A cybersecurity supply chain risk management program, strategy,
        objectives, policies, and processes are established and agreed to by organisational
        stakeholders
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-01
      ref_id: GV.SC-01.1
      description: A cybersecurity supply chain risk management program, strategy,
        objectives, policies, and processes shall be documented, reviewed, updated
        when changes occur, and approved by organisational stakeholders.
      annotation: "The goal of this control is to ensure supply chain cybersecurity\
        \ risks are proactively managed through a documented, stakeholder-approved,\
        \ and regularly updated risk management program.\n\nThe steps below should\
        \ be considered for organisations to establish a cybersecurity supply chain\
        \ risk management (C-SCRM) program that is aligned with their strategic objectives\
        \ and supported by all relevant stakeholders: \n\nDefine the Program and Strategy\
        \ \n\u0387  Identify Objectives: Clearly define what the organisation aims\
        \ to achieve with its C-SCRM program. Objectives might include protecting\
        \ against supply chain attacks, ensuring compliance with regulations, and\
        \ maintaining business continuity. \n\u0387  Develop a Strategy: Outline a\
        \ high-level strategy that aligns with the organisation's overall cybersecurity\
        \ and business strategies. This should include risk assessment, risk mitigation,\
        \ and continuous monitoring plans. \n\nEngage Stakeholders \n\u0387  Identify\
        \ Stakeholders: Determine who the key stakeholders are, including executives,\
        \ IT, procurement, legal, and compliance teams. \n\u0387  Stakeholder Involvement:\
        \ Engage stakeholders early in the process to ensure their input and buy-in.\
        \ This can be done through workshops, meetings, and regular updates. \n\n\
        Establish Policies and Processes \n\u0387  Develop Policies: Create comprehensive\
        \ documented policies that cover all aspects of C-SCRM, including vendor risk\
        \ management, incident response, and compliance requirements. \n\u0387  Implement\
        \ Processes: Define and document processes for risk assessment, vendor evaluation,\
        \ contract management, and incident response. Ensure these processes are integrated\
        \ into existing business workflows. \n\nRisk Assessment and Management \n\u0387\
        \  Conduct Risk Assessments: Regularly assess risks associated with the supply\
        \ chain, including potential vulnerabilities and threats. \n\u0387  Mitigate\
        \ Risks: Develop and implement risk mitigation strategies based on the assessment\
        \ results. This might include diversifying suppliers, enhancing security controls,\
        \ and establishing contingency plans. \n\nContinuous Monitoring and Improvement\
        \ \n\u0387  Monitor Continuously: Implement continuous monitoring of the supply\
        \ chain to detect and respond to new risks promptly. This includes monitoring\
        \ supplier performance and compliance. \n\u0387  Review and Improve: Regularly\
        \ review the effectiveness of the C-SCRM program and make improvements as\
        \ needed. This should include feedback from stakeholders and lessons learned\
        \ from incidents. \n\nTraining and Awareness \nEducate Employees: Provide\
        \ training and awareness programs for employees to understand their roles\
        \ in C-SCRM. This includes recognising supply chain risks and following established\
        \ policies and procedures. \n\nDocumentation and Communication \n\u0387  Document\
        \ Everything: Ensure all policies, processes, risk assessments, and mitigation\
        \ plans are well-documented, kept up to date, approved by relevant management\
        \ and accessible to relevant stakeholders. \n\u0387  Communicate Effectively:\
        \ Maintain open lines of communication with stakeholders to keep them informed\
        \ about the program\u2019s progress, changes, and any incidents that occur."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-02
      description: Cybersecurity roles and responsibilities for suppliers, customers,
        and partners are established, communicated, and coordinated internally and
        externally
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-02
      ref_id: GV.SC-02.1
      description: Third-party providers shall notify any transfer, termination or
        transition of personnel with physical or logical access to business-critical
        system elements of the organisation.
      annotation: "The goal of this control is to ensure continuity and security of\
        \ critical systems by requiring third-party providers to report personnel\
        \ changes affecting access. \n\nTo achieve this goal, the following should\
        \ be considered: \n\u0387  Third-party providers include, for example, service\
        \ providers, contractors, and other organisations providing system development,\
        \ technology services, outsourced applications, or network and security management.\
        \ \n\u0387  Rules and protocols for information sharing between the organisation\
        \ and its suppliers and sub-tier suppliers should be defined in contractual\
        \ agreements."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-03
      description: Cybersecurity supply chain risk management is integrated into cybersecurity
        and enterprise risk management, risk assessment, and improvement processes
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-03
      ref_id: GV.SC-03.1
      description: Information- and Cybersecurity supply chain risk management shall
        be integrated into information/cybersecurity and enterprise risk management,
        risk assessment, and improvement processes.
      annotation: "The goal of this control is to ensure supply chain cybersecurity\
        \ risks are consistently identified, assessed, and mitigated by embedding\
        \ them into enterprise risk assessments, control reviews, and continuous improvement\
        \ cycles.\n\nTo effectively integrate supply chain risk management into broader\
        \ cybersecurity and enterprise risk frameworks, organisations should consider\
        \ to: \n\nIdentify Alignment and Overlap \n\u0387  Map existing information/cybersecurity\
        \ risk management and enterprise risk management (ERM) processes. \n\u0387\
        \  Identify touchpoints where supply chain risks intersect with: \n    \u0387\
        \  Vendor management \n    \u0387  Procurement \n    \u0387  Business continuity\
        \ \n    \u0387  Legal and compliance \n\u0387  Document areas of overlap,\
        \ duplication, or gaps to streamline integration. \n\nEstablish Integrated\
        \ Control Sets \n\u0387  Develop a unified control framework that includes:\
        \ \n\u0387  Controls specific to supply chain cybersecurity (e.g., third-party\
        \ access, data handling, software integrity). \n\u0387  Controls from existing\
        \ cybersecurity standards (e.g., ISO/IEC 27036). \n\u0387  Ensure controls\
        \ are risk-based, scalable, and aligned with both IT and OT environments.\
        \ \n\nEmbed in Risk Assessment Processes \n\u0387  Include supply chain-specific\
        \ threat scenarios in risk assessments (e.g., supplier compromise, counterfeit\
        \ hardware, software vulnerabilities). \n\u0387  Evaluate supplier criticality\
        \ and risk exposure as part of the enterprise risk register. \n\u0387  Use\
        \ tiered risk assessments based on supplier impact and sensitivity of services/data.\
        \ \n\nIntegrate into Continuous Improvement \n\u0387  Incorporate supply chain\
        \ risk insights into: \n    \u0387  Lessons learned from incidents and audits\
        \ \n    \u0387  Post-mortem reviews of supplier-related disruptions \n   \
        \ \u0387  Process improvement cycles (e.g., PDCA) \n\u0387  Update policies,\
        \ procedures, and controls based on evolving threats and supplier performance.\
        \ \n\nEscalate Material Risks to Senior Management \n\u0387  Define criteria\
        \ for materiality (e.g., financial impact, regulatory exposure, operational\
        \ disruption). \n\u0387  Establish a formal escalation path to senior leadership\
        \ and risk committees. \n\u0387  Ensure material supply chain risks are: \n\
        \    \u0387  Reflected in the enterprise risk register \n    \u0387  Addressed\
        \ in strategic risk discussions \n    \u0387  Considered in business continuity\
        \ and crisis management planning"
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-05
      description: Requirements to address cybersecurity risks in supply chains are
        established, prioritised, and integrated into contracts and other types of
        agreements with suppliers and other relevant third parties
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05
      ref_id: GV.SC-05.1
      description: Requirements for addressing cybersecurity risks and the sharing
        of sensitive information in supply chains shall be established, prioritised,
        integrated into contracts and other types of formal agreements, and enforced.
      annotation: "The goal of this control is to establish and enforce cybersecurity\
        \ and sensitive data handling requirements in supply chain agreements, by\
        \ integrating them into contracts and prioritising them based on risk.\n\n\
        To make this happen, the following should be considered: \n\u0387  Contractual\
        \ agreements and other types of formal agreements with suppliers and other\
        \ relevant third parties should define expectations, responsibilities, and\
        \ security requirements. \n\u0387  Key elements of these agreements include\
        \ information sharing between the organisation and its suppliers and sub-tier\
        \ suppliers, security controls, incident response, and required compliance\
        \ with standards and regulations. \n\u0387  Security requirements should be\
        \ set for suppliers, products and services that are proportionate to the criticality\
        \ and potential consequences if compromised. \n\u0387  All cybersecurity and\
        \ supply chain requirements that third parties must comply with, should be\
        \ included in standard contractual language (i.e., pre-drafted, commonly used\
        \ terms and clauses that ensure consistency, compliance, and clarity). The\
        \ contract should also specify how compliance with these requirements will\
        \ be verified.\n\u0387  Consider to include in the enforcement that third-party\
        \ providers and users (e.g. suppliers, customers, partners) should be able\
        \ to demonstrate the understanding of their roles and responsibilities. \n\
        \u0387  Consider defining security requirements in service-level agreements\
        \ (SLAs) for monitoring suppliers for acceptable security performance throughout\
        \ the supplier relationship lifecycle. \n\u0387  Consider to contractually\
        \ require suppliers to vet their employees and guard against insider threats.\
        \ \n\u0387  Consider to contractually require suppliers to provide evidence\
        \ of performing acceptable security practices through, for example, self-assessment\
        \ (e.g. CyFun\xAE), conformance to known standards, verifications (e.g. CyFun\xAE\
        ), certifications (e.g. CyFun\xAE), or inspections. \n\u0387  Keep in mind\
        \ that GDPR requirements must be met if business information contains personal\
        \ data (applicable at all levels), i.e. safeguards should be included in the\
        \ contractual framework."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05
      ref_id: GV.SC-05.2
      description: Contractual information/cybersecurity requirements for suppliers
        and external partners shall be implemented to ensure a verifiable flaw resolution
        process and to ensure that deficiencies identified during information/cybersecurity
        testing and evaluation are remedied.
      annotation: "The goal of this control, which is related to GV.SC-09.1, is to\
        \ embed enforceable requirements in supplier contracts to guarantee timely\
        \ flaw remediation and resolution of cybersecurity issues identified through\
        \ testing and evaluation.\n\nTo achieve this goal, the following should be\
        \ considered: \n\u0387  Information systems containing software (or firmware)\
        \ affected by recently announced software flaws (and potential vulnerabilities\
        \ resulting from those flaws) should be identified. \n\u0387  Newly released\
        \ security relevant patches, service packs, and hot fixes should be installed,\
        \ and these patches, service packs, and hot fixes are tested for effectiveness\
        \ and potential side effects on the organisation\u2019s information systems\
        \ before installation. Flaws discovered during security assessments, continuous\
        \ monitoring, incident response activities, or information system error handling\
        \ are also addressed expeditiously. Flaw remediation should be incorporated\
        \ into configuration management as an emergency change. \n\u0387  Consider\
        \ to contractually require suppliers to disclose information/cybersecurity\
        \ features, functions, and vulnerabilities of their products and services\
        \ for the life of the product or the term of service. \n\u0387  Consider to\
        \ contractually require suppliers to provide and maintain a current component\
        \ inventory (e.g. software or hardware bill of materials) for critical products."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-05
      ref_id: GV.SC-05.3
      description: The organisation shall establish contractual requirements permitting
        the organisation to review the information/cybersecurity programs implemented
        by suppliers and third-party partners.
      annotation: "The goal of this control is to ensure that the organisation can\
        \ assess and verify the information/cybersecurity practices of suppliers and\
        \ third-party partners through contractual agreements. \n\nTo achieve this\
        \ goal: \n\u0387  Information/Cybersecurity Requirements \n    Contracts should\
        \ define clear information/cybersecurity expectations, including OT-specific\
        \ controls where  relevant. \n\u0387  Audit and Review Rights \n    Agreements\
        \ should grant the organisation the right to audit, assess, or review the\
        \ information/cybersecurity programs of suppliers and partners. \n\u0387 \
        \ Verification Methods \n    Conformance should be verified through self-assessments,\
        \ third-party certifications, or scheduled security evaluations. \n\u0387\
        \  Information Sharing Protocols \n    Contracts should specify what information/cybersecurity-related\
        \ information must be shared, how often, and through which channels. \n\u0387\
        \  Continuous Monitoring \n    Suppliers should regularly report on their\
        \ information/cybersecurity posture and disclose incidents that could impact\
        \ operations, especially in OT environments. \n\u0387  Non-Compliance Consequences\
        \ \n    Contracts should outline consequences for failing to meet information/cybersecurity\
        \ requirements, such as penalties or contract termination."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-06
      description: Planning and due diligence are performed to reduce risks before
        entering into formal supplier or other third-party relationships
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-06
      ref_id: GV.SC-06.1
      description: Planning and due diligence shall be carried out to reduce risks
        before entering into formal relationships with suppliers or other third parties.
      annotation: "The goal of this control is to reduce cybersecurity and operational\
        \ risks by ensuring that appropriate planning and due diligence are conducted\
        \ before entering into formal relationships with suppliers or third parties.\n\
        \nTo achieve this goal: \n\u0387  Risk-Based Due Diligence \n    Due diligence\
        \ should be performed on prospective suppliers in line with the organisation\u2019\
        s procurement policy and scaled to the level of risk, criticality, and complexity\
        \ of the relationship. \n\u0387  Cybersecurity and Risk Capability Assessment\
        \ \n    The cybersecurity maturity, risk management practices, and OT-specific\
        \ capabilities of suppliers should be evaluated for suitability. \n\u0387\
        \  Supplier Risk Assessments \n    Risk assessments should be conducted to\
        \ ensure alignment with business needs and applicable cybersecurity requirements,\
        \ including those relevant to OT environments. \n\u0387  Product Integrity\
        \ and Security \n    The authenticity, integrity, and security of critical\
        \ products and components should be verified before acquisition and deployment,\
        \ especially in OT systems where vulnerabilities can impact safety and operations."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-07
      description: The risks posed by a supplier, their products and services, and
        other third parties are understood, recorded, prioritised, assessed, responded
        to, and monitored over the course of the relationship
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07
      ref_id: GV.SC-07.1
      description: The risks posed by a supplier, its products and services and other
        third parties shall be identified, documented, prioritised, mitigated and
        assessed at least annually and when changes occur during the relationship.
      annotation: "The goal of this control is to ensure that risks related to suppliers,\
        \ their products and services, and other third parties are continuously identified,\
        \ assessed, prioritised, and managed throughout the relationship, especially\
        \ when changes occur in critical systems. \n\nTo achieve this goal: \n\u0387\
        \  Tailored Risk Assessments \n    Assessment formats and frequencies should\
        \ be adapted based on the supplier\u2019s reputation and the criticality of\
        \ the products or services provided, including OT components. \n\u0387  Broader\
        \ Risk Considerations \n    Risk evaluations should include potential service\
        \ disruptions and concentration risks that could impact operations or OT environments.\
        \ \n\xB7 Evidence of Compliance\n    Suppliers should provide evidence of\
        \ compliance with contractual cybersecurity requirements, such as self-assessments\
        \ (e.g. CyFun\xAE), certifications, warranties, test results, labels, or third-party\
        \ audit reports.\n\xB7 Ongoing Monitoring\n    Critical suppliers should be\
        \ monitored throughout the relationship using inspections, audits, tests,\
        \ or other evaluation methods to ensure security obligations remain fulfilled.\n\
        \xB7 Risk Profile Updates\n    Changes in supplier services, products, or\
        \ performance should trigger a reassessment of their risk profile and criticality,\
        \ especially when OT systems are involved.\n\xB7 Business Continuity Planning\n\
        \    An action plan should be in place to address unexpected supplier disruptions\
        \ and maintain operational continuity."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07
      ref_id: GV.SC-07.2
      description: A documented list of all critical suppliers, vendors and partners
        of the organisation that may be involved in a major incident shall be established,
        kept up-to-date and made available online and off-line with due regard to
        confidentiality and security.
      annotation: "The goal of this control is to ensure that a reliable, up-to-date\
        \ list of critical suppliers, vendors, and partners is maintained and accessible,\
        \ both online and offline, to support rapid response during major incidents,\
        \ while safeguarding confidentiality and security. \n\nTo achieve this goal:\
        \ \n\u0387  Maintain a Comprehensive Record \n    A complete list of suppliers,\
        \ vendors, and partners should be maintained as a foundation for identifying\
        \ those critical to operations, including OT environments. \n\u0387  Define\
        \ Criticality Criteria \n    Clear criteria should be established to classify\
        \ supplier criticality based on factors such as: \n        \u0387  Sensitivity\
        \ of data handled \n        \u0387  Access to systems or networks \n     \
        \   \u0387  Importance to core business or OT functions \n\u0387  Document\
        \ Key Information \n    For each critical supplier, the list should include:\
        \ \n        \u0387  Primary and secondary contact details \n        \u0387\
        \  Description of services provided \n        \u0387  Escalation paths and\
        \ support availability \n\u0387  Ensure Online and Offline Availability \n\
        \    The list should be: \n        \u0387  Regularly updated and securely\
        \ stored \n        \u0387  Accessible both online and offline (e.g. printed\
        \ copies, encrypted USBs) to ensure availability during cyber incidents or\
        \ outages"
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07
      ref_id: GV.SC-07.3
      description: The organisation shall audit business-critical third-party service
        providers for security compliance.
      annotation: "The goal of this control is to ensure that business-critical third-party\
        \ service providers are regularly audited to confirm conformance with agreed-upon\
        \ security requirements, helping to manage risks to operations and critical\
        \ systems. \n\nTo achieve this goal: \n\u0387  Identify Critical Providers\
        \ \n    The criticality of third-party service providers should be assessed\
        \ based on their impact on operations, including OT systems, and the level\
        \ of risk they introduce. \n\u0387  Acceptable Audit Evidence \n    Third-party\
        \ audit results, such as certifications, independent assessments, or security\
        \ attestations, should be accepted as valid evidence of conformance where\
        \ appropriate. \n\u0387  Conduct Security Audits \n    Regular audits should\
        \ be performed on critical providers to verify that they meet contractual\
        \ and policy-based security obligations."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-07
      ref_id: GV.SC-07.4
      description: The organisation shall ensure conformity with information/cybersecurity
        contractual obligations by suppliers and third-party partners through regular
        reviews of independent audits, assessments, and third party evaluations.
      annotation: "The goal of this control is to ensure that suppliers and third-party\
        \ partners conform to contractual information and cybersecurity obligations\
        \ through regular reviews of independent audits, assessments, and third-party\
        \ evaluations. \n\nTo achieve this goal: \n\u0387  Build on Related Controls\
        \ \n    This control should be implemented in alignment with GV.SC-05.3 and\
        \ GV.SC-07.1 to strengthen supplier oversight. \n\u0387  Integrate Risk Assessments\
        \ \n    Independent audits and third-party assessments should include evaluations\
        \ of corporate and applicable cybersecurity requirements, including supply\
        \ chain and OT-specific risks. \n\u0387  Pre-Engagement Verification \n  \
        \  Before engaging with critical suppliers, independent evaluations should\
        \ be reviewed to confirm conformance with agreed cybersecurity standards and\
        \ obligations. \n\u0387  Risk-Based Review Depth \n    The depth and frequency\
        \ of reviews should be adapted based on the criticality of the supplier\u2019\
        s products or services. More critical suppliers should undergo more thorough\
        \ evaluations."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-08
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-08
      description: Relevant suppliers and other third parties are included in incident
        planning, response, and recovery activities
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-08.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-08
      ref_id: GV.SC-08.1
      description: The organisation shall identify and document key personnel from
        relevant suppliers and other third parties to include them in incident planning,
        response, and recovery activities.
      annotation: "The goal of this control is to strengthen incident preparedness\
        \ and recovery by ensuring that key personnel from critical suppliers and\
        \ third parties are identified and actively integrated into response planning\
        \ and execution.\n \nTo achieve this goal: \n\u0387  Establish Communication\
        \ Protocols\n    Clear rules and procedures should be defined for reporting\
        \ incident status and coordinating response and recovery activities between\
        \ the organisation and its business-critical suppliers.\n\u0387  Define Roles\
        \ and Responsibilities \n    Roles, responsibilities, and authority for incident\
        \ response should be documented for both internal teams and third-party participants,\
        \ including those supporting OT systems and infrastructure. \n\u0387  Promote\
        \ Joint Learning \n    Collaborative lessons-learned sessions should be conducted\
        \ with critical suppliers and third parties following major incidents to improve\
        \ future coordination and resilience."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-09
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-09
      description: Supply chain security practices are integrated into cybersecurity
        and enterprise risk management programs, and their performance is monitored
        throughout the technology product and service life cycle
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-09.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-09
      ref_id: GV.SC-09.1
      description: Supply chain security practices shall be integrated into information/cybersecurity
        and enterprise risk management programs, and their performance shall be monitored
        throughout the product and service life cycle.
      annotation: "The goal of this control is to ensure that supply chain security\
        \ practices are embedded into the organisation\u2019s information security,\
        \ cybersecurity, and enterprise risk management programs, with performance\
        \ monitored and improved throughout the lifecycle of products and services.\
        \ \n\nTo achieve this goal: \n\u0387  Align with Related Controls \n    This\
        \ control builds on GV.SC-05.2 by ensuring that contractual information and\
        \ cybersecurity requirements, such as flaw resolution and remediation of identified\
        \ deficiencies, are actively managed within broader risk programs. \n\u0387\
        \  Establish Governance Foundations \n    Supply chain security policies should\
        \ be documented, covering both information and cybersecurity expectations\
        \ for suppliers and third parties. \n\u0387  Integrate into Risk Frameworks\
        \ \n    Supply chain risks should be embedded in enterprise and information\
        \ security risk management frameworks, including OT-specific risks and dependencies.\
        \ \n\u0387  Formalise Security Expectations \n    Contracts and SLAs should\
        \ include clear clauses on information and cybersecurity, audit rights, and\
        \ performance metrics. \n\u0387  Monitor and Evaluate Performance \n    Risk\
        \ assessments, audit reports, and incident records should be reviewed regularly\
        \ to assess supplier posture and identify areas for improvement. \n\u0387\
        \  Enable Continuous Monitoring \n    Monitoring tools and KPIs should be\
        \ used to track supplier security performance across the lifecycle, including\
        \ incident response times and conformance rates. \n\u0387  Support Awareness\
        \ and Training\n    Training and awareness programs should address supply\
        \ chain-related information and cybersecurity risks for both internal teams\
        \ and suppliers. \n\u0387  Ensure Lifecycle Coverage \n    Documentation should\
        \ demonstrate that supply chain security is considered from procurement through\
        \ to decommissioning, especially for OT systems and components."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc
      ref_id: GV.SC-10
      description: Cybersecurity supply chain risk management plans include provisions
        for activities that occur after the conclusion of a partnership or service
        agreement
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-10.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:gv.sc-10
      ref_id: GV.SC-10.1
      description: Cybersecurity supply chain risk management plans shall include
        actions and responsibilities for managing risks that may arise after a supplier
        relationship or service agreement has ended.
      annotation: "The goal of this control is to ensure that residual cybersecurity\
        \ and information security risks are effectively addressed after supplier\
        \ relationships end, thereby preventing disruptions, data exposure, and vulnerabilities\
        \ in operational and OT environments. \n\nTo achieve this goal: \n\u0387 \
        \ Plan for Termination of the Relationship\n    Formal offboarding procedures\
        \ should be defined for ending supplier relationships under both normal and\
        \ adverse conditions, including breach, insolvency, or security incidents.\
        \ \n\u0387  Ensure Secure Transition or Exit \n    Transition plans should\
        \ be developed for critical services, to maintain continuity and address supply\
        \ chain resilience, including fallback suppliers or internal alternatives.\
        \ \n\u0387  Revoke Access and Secure Data \n    Supplier access to systems,\
        \ networks, and data should be promptly revoked. All credentials and remote\
        \ access tools should be deactivated or removed. \n\u0387  Protect Organisational\
        \ Assets \n    Devices, storage media, and documents containing organisational\
        \ data should be securely returned or sanitised. Controls should prevent unauthorised\
        \ retention or leakage of sensitive information. \n\u0387  Address Component\
        \ Obsolescence \n    Plans should be in place to manage end-of-life components\
        \ or services, ensuring continued support or secure replacements, especially\
        \ for OT systems. \n\u0387  Monitor Residual Risks \n    Post-termination\
        \ risks should be identified, assessed, and escalated to senior management\
        \ when necessary. These risks should be tracked within the enterprise risk\
        \ management process."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id
      assessable: false
      depth: 1
      ref_id: ID
      name: IDENTIFY
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id
      ref_id: ID.AM
      name: Asset Management
      description: Assets (e.g., data, hardware, software, systems, facilities, services,
        people) that enable the organisation to achieve business purposes are identified
        and managed consistent with their relative importance to organisational objectives
        and the organisation's risk strategy.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-01
      description: Inventories of hardware managed by the organisation are maintained.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01
      ref_id: ID.AM-01.1
      description: "An inventory of physical and virtual infrastructure assets\u2014\
        such as hardware, network devices, and cloud-hosted environments\u2014that\
        \ support information processing shall be documented, reviewed, and updated\
        \ as changes occur."
      annotation: "The goal of this control is to ensure that critical systems and\
        \ services remain available by implementing redundancy in line with organisational,\
        \ legal, and regulatory availability requirements.\n\nWhile ID.AM-01.1 focuses\
        \ on the infrastructure layer, this control is closely linked to ID.AM-02.1\
        \ which tracks the software and services that run on top of it, such as applications,\
        \ platforms, and digital tools. Together, they provide a full picture of the\
        \ organisation\u2019s technology environment.\n\nTo achieve the goal of ID.AM-01.1,\
        \ the following should be considered:\n\xB7 Organisations should identify\
        \ and document all physical and virtual infrastructure assets that support\
        \ information processing, including servers, workstations, network devices,\
        \ storage systems, and cloud-hosted resources.\n\xB7 The inventory should\
        \ include key attributes such as asset type, location, owner, configuration,\
        \ and lifecycle status.\n\xB7 Organisations should consider automated asset\
        \ discovery and management tools where possible to ensure accuracy and real-time\
        \ updates.\n\xB7 The inventory should be reviewed and updated regularly, especially\
        \ following changes such as deployments, decommissions, or relocations.\n\xB7\
        \ The inventory should be accessible to relevant stakeholders and should be\
        \ integrated with risk management and incident response processes."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01
      ref_id: ID.AM-01.2
      description: "The inventory of enterprise assets associated with information\
        \ and information processing facilities shall reflect changes in the organisation\u2019\
        s context and include all information necessary for effective accountability."
      annotation: "The goal of this control is to ensure that asset inventories support\
        \ operational transparency, enable responsible ownership, and adapt to changes\
        \ in the organisation\u2019s structure, technology, and risk landscape.\n\n\
        To achieve this goal:\n\xB7 Include Essential Asset Details\n    Inventories\
        \ should capture key specifications such as manufacturer, device type, model,\
        \ serial number, machine name, network address, and physical location. OT\
        \ assets should be included where applicable.\n\xB7 Support Accountability\n\
        \    Asset records should enable traceability of actions and decisions, ensuring\
        \ that responsible parties can be identified and held answerable for outcomes.\n\
        \xB7 Reflect Organisational Changes\n    Inventories should be updated to\
        \ reflect changes such as asset relocation, upgrades, or decommissioning,\
        \ including those affecting OT environments."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01
      ref_id: ID.AM-01.3
      description: When unauthorised hardware is detected, it shall be quarantined
        for possible exception handling, removed, or replaced, and the inventory shall
        be updated accordingly.
      annotation: "The goal of this control is to reduce security risks by ensuring\
        \ that unauthorised hardware is promptly identified, isolated, and addressed,\
        \ while maintaining an accurate and accountable asset inventory.\n\nTo make\
        \ this happen:\n\xB7 Define Unauthorised hardware\n    Any hardware not approved\
        \ or lacking documented exceptions should be designated as unauthorised.\n\
        \xB7 Respond to Detection\n    Unauthorised hardware should be quarantined\
        \ for review, removed, or replaced as appropriate. The asset inventory should\
        \ be updated accordingly.\n\xB7 Include OT Considerations\n    Unauthorised\
        \ devices in OT environments should be treated with heightened caution due\
        \ to potential safety and operational impacts.\n\nExamples of unauthorised\
        \ hardware may include:\n\xB7 Unapproved Endpoints: Personal or unregistered\
        \ laptops, desktops, or mobile devices connected to the network without Authorisation.\n\
        \xB7 External Storage Devices: USB drives or external hard disks not approved\
        \ for use, which may introduce malware or data leakage risks.\n\xB7 Unvetted\
        \ IoT and OT Devices: Smart devices, sensors, or industrial components connected\
        \ without proper vetting, posing risks to both IT and OT environments.\n\xB7\
        \ Unauthorised Network Equipment: Wireless access points or switches installed\
        \ without approval, potentially bypassing network security controls."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-01
      ref_id: ID.AM-01.4
      description: "Mechanisms for detecting the presence of unauthorised hardware\
        \ and firmware components within the organisation\u2019s ICT/OT environment\
        \ shall be identified."
      annotation: "The goal of this control is to proactively identify unauthorised\
        \ hardware and firmware components within ICT and OT environments, thereby\
        \ enabling timely response and reducing the risk of compromise or operational\
        \ disruption.\n\nTo achieve this goal:\n\xB7 Automate Where Feasible\n   \
        \ Detection mechanisms should be automated where safe and technically possible,\
        \ especially in complex or high-risk environments.\n\xB7 Continuously Monitor\
        \ Networks\n    Networks should be continuously monitored to detect new or\
        \ unauthorised hardware and firmware components. Detected changes should trigger\
        \ automatic updates to the asset inventory.\n\xB7 Establish a Response Process\n\
        \    A defined process should exist to regularly review and address unauthorised\
        \ components.\n    \xB7 For unauthorised hardware, refer to ID.AM-01.3\n \
        \   \xB7 For unauthorised firmware, refer to ID.AM-02.4\n\xB7 Include OT-Specific\
        \ Considerations\n    Detection methods in OT environments should account\
        \ for safety, availability, and vendor-specific constraints when identifying\
        \ unauthorised components."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-02
      description: Inventories of software, services, and systems managed by the organisation
        are maintained
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02
      ref_id: ID.AM-02.1
      description: An inventory of software, digital services, and business systems
        used within the organisation shall be documented, reviewed, and updated as
        changes occur.
      annotation: "This control ensures that all software, digital services, and business\
        \ systems used within the organisation are identified, tracked, and regularly\
        \ updated. It focuses on the functional and intangible parts of the technology\
        \ environment, such as applications, platforms, and cloud services, that operate\
        \ on or interact with the underlying infrastructure. Keeping this inventory\
        \ up-to-date supports operational continuity, strengthens security, and helps\
        \ meet compliance requirements.\n\nIt is closely linked to ID.AM-01.1, which\
        \ covers the physical and virtual infrastructure (such as servers, network\
        \ devices, and cloud environments) that supports these systems.\n\nTogether,\
        \ both controls provide a complete view of the organisation\u2019s technology\
        \ landscape, from the foundational infrastructure to the applications and\
        \ services that deliver business value.\n\nTo achieve this goal, the following\
        \ steps should be considered:\n\xB7 Identify Software and Services\n    The\
        \ inventory should include all applications, cloud services, APIs, and business\
        \ systems (e.g. ERP, CRM, HR platforms).\n\xB7 Record Key Information\n  \
        \  Each entry should include version, owner, purpose, licence type, and deployment\
        \ environment.\n\xB7 Use Automation Where Possible\n    Automated discovery\
        \ tools should be used to accurately detect and update software and services.\n\
        \xB7 Maintain a Software Bill of Materials (SBOM)\n    An SBOM should be maintained\
        \ for critical or internally developed software to track components and dependencies.\n\
        \xB7 Keep the Inventory up-to-date\n    The inventory should be reviewed and\
        \ updated regularly, especially after installations, upgrades, or removals.\n\
        \xB7 Align with Infrastructure Inventory (ID.AM-01.1)\n    Software records\
        \ should be linked to the infrastructure they run on to provide a complete\
        \ view of the technology environment."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02
      ref_id: ID.AM-02.2
      description: "The inventory reflecting which software, services and systems\
        \ are used in the organisation shall reflect changes in the  organisation\u2019\
        s context and include all information necessary for effective accountability."
      annotation: "The goal of this control is to ensure that inventories of software,\
        \ services, and systems remain current and complete, enabling traceability,\
        \ responsible ownership, and alignment with changes in the organisation\u2019\
        s operational and risk context.\n\nTo achieve this goal:\n\xB7 Include Key\
        \ Inventory Details\n    Inventories should capture relevant attributes such\
        \ as software title, publisher, initial install or use date, business purpose,\
        \ version, deployment method, and decommission date. URLs or app store sources\
        \ should be included where applicable.\n\xB7 Support Accountability\n    Inventory\
        \ records should enable traceability of actions and decisions, ensuring that\
        \ responsible roles can be identified and held answerable for the use and\
        \ management of software and services.\n\xB7 Reflect Organisational Changes\n\
        \    Inventories should be updated to reflect changes such as new deployments,\
        \ upgrades, or removals, including those affecting OT systems and embedded\
        \ software components."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02
      ref_id: ID.AM-02.3
      description: The people responsible and accountable for managing software platforms
        and applications within the organisation shall be formally identified.
      annotation: "The goal of this control is to ensure that software platforms and\
        \ applications are properly managed, by clearly identifying who is responsible\
        \ for day-to-day operations and who is accountable for overall oversight and\
        \ outcomes.\n\nTo achieve this goal:\n\xB7 Define Roles Clearly\n    Individuals\
        \ responsible for managing software should be formally designated. These are\
        \ the people who perform the work, make technical decisions, and carry out\
        \ operational tasks (e.g. developers, system administrators, testers).\n\xB7\
        \ Assign Accountability\n    A separate role should be formally assigned to\
        \ oversee and approve the successful completion of software-related tasks.\
        \ This may include project managers, product owners, or team leads.\n\xB7\
        \ Apply to All Environments\n    These roles should be defined for both IT\
        \ and OT environments, ensuring that software used in industrial systems is\
        \ also properly governed."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02
      ref_id: ID.AM-02.4
      description: When unauthorised software is detected, it shall be quarantined
        for possible exception handling, removed, or replaced, and the inventory shall
        be updated accordingly.
      annotation: "The goal of this control is to minimise security, operational,\
        \ and compliance risks by ensuring that unauthorised software is promptly\
        \ identified, handled appropriately, and reflected in the organisation\u2019\
        s software inventory.\n\nTo make this happen:\n\xB7 Define Unauthorised Software\n\
        \    Software installed or used without proper licensing, approval, or documented\
        \ exceptions should be classified as unauthorised.\n\xB7 Understand the Risks\n\
        \    Unauthorised software may introduce:\n    \xB7 Security vulnerabilities\
        \ (e.g. malware or backdoors)\n    \xB7 Data protection risks (e.g. unapproved\
        \ data handling)\n    \xB7 Operational inefficiencies (e.g. compatibility\
        \ issues)\n    \xB7 Loss of control over software usage and updates\n\xB7\
        \ Establish Response Procedures\n    Unauthorised software should be quarantined\
        \ for possible exception handling, removed, or replaced. The software inventory\
        \ should be updated accordingly.\n\xB7 Support with Centralised Management\n\
        \    A centralised software management process should be in place to oversee\
        \ vendor selection, legacy software, and security controls.\n\xB7 Use SBOMs\
        \ Where Applicable\n    Software Bills of Materials (SBOMs) should be used\
        \ to track components, libraries, and modules, supporting licence compliance\
        \ and vulnerability management, especially in OT and embedded systems."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-02
      ref_id: ID.AM-02.5
      description: "Mechanisms for detecting the presence of unauthorised software\
        \ within the organisation\u2019s ICT/OT environment shall be identified."
      annotation: "The goal of this control is to ensure that mechanisms are in place\
        \ to detect unauthorised software across ICT and OT environments, thereby\
        \ enabling timely response and maintaining an accurate software inventory.\n\
        \nTo achieve this goal:\n\xB7 Automate Where Feasible\n    Detection mechanisms\
        \ should be automated where safe and technically appropriate, especially in\
        \ complex or high-risk environments.\n\xB7 Monitor All Platforms\n    All\
        \ platforms, including physical systems, virtual machines, containers, and\
        \ embedded OT systems, should be continuously monitored for new or unauthorised\
        \ software. Detected changes should trigger automatic updates to the software\
        \ inventory.\n\xB7 Establish a Review Process\n    A process should be in\
        \ place to regularly investigate and address unauthorised software. When unauthorised\
        \ software is detected, ID.AM-02.4 should be applied.\n\xB7 Adapt Detection\
        \ to OT Environments\n    In OT environments, detection mechanisms should\
        \ be tailored to avoid operational disruption. Passive monitoring, vendor-approved\
        \ tools, and scheduled scans should be considered to ensure safety and system\
        \ availability."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-03
      description: Representations of the organisation's authorised network communication
        and internal and external network data flows are maintained
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-03-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-03
      ref_id: ID.AM-03-2
      description: The organisation's network communication and internal data flows
        shall be mapped, documented, authorised, and updated when changes occur.
      annotation: "The goal of this control is to ensure that internal network communications\
        \ and data flows are clearly understood, properly documented, and kept up\
        \ to date to support secure operations and informed decision-making across\
        \ ICT and OT environments.\n\nTo achieve this goal:\n\xB7 Establish Network\
        \ Baselines\n    Communication and data flows across wired, wireless, and\
        \ cloud-based infrastructure (e.g. IaaS) should be mapped, documented, and\
        \ authorised. Updates should be made when changes occur.\n\xB7 Document Technical\
        \ Details\n    Expected network ports, protocols, and services used between\
        \ authorised systems should be recorded to support monitoring and troubleshooting.\n\
        \xB7 Integrate with Configuration Management\n    Configuration management\
        \ processes should support the maintenance and validation of network flow\
        \ documentation.\n\xB7 Ensure Resilient Documentation\n    Network flow documentation\
        \ should be stored securely and not solely on the network it describes. A\
        \ protected offline copy (e.g. encrypted external drive or hardcopy) should\
        \ be maintained to ensure availability during outages or incidents."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-03-3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-03
      ref_id: ID.AM-03-3
      description: The organisation's network communication and external data flows
        shall be mapped, documented, authorised, and updated when changes occur.
      annotation: "The goal of this control is to ensure that external network communications\
        \ are clearly understood, controlled, and monitored to reduce the risk of\
        \ unauthorised access, data leakage, or service disruption across ICT and\
        \ OT environments.\n\nTo achieve this goal:\n\xB7 Map and Document External\
        \ Flows\n    Communication and data flows between the organisation and external\
        \ parties should be mapped, documented, and authorised. These records should\
        \ be updated when changes occur.\n\xB7 Enforce Access Controls\n    Network\
        \ connections should be restricted to explicitly authorised interfaces to\
        \ reduce the attack surface and prevent unauthorised data transfers.\n\xB7\
        \ Enhance Monitoring When Needed\n    Monitoring should be intensified in\
        \ response to elevated risk levels. This may include real-time alerts, enhanced\
        \ logging, or more frequent audits of external network activity.\n\xB7 Prevent\
        \ Information Leakage\n    The risk of data leakage through electromagnetic\
        \ emissions or side-channel attacks should be assessed. Where appropriate,\
        \ mitigation measures such as EMSEC or TEMPEST controls should be applied,\
        \ especially for systems handling sensitive or classified information.\n\n\
        The two controls \u2014 ID.AM-03-3 and ID.AM-04.2 \u2014 are closely related\
        \ but focus on different scopes of information flow and network activity.\
        \ This control, ID.AM-03-3, covers network-layer interactions with external\
        \ entities, including:\n    \xB7 Internet traffic (e.g., outbound web access,\
        \ DNS queries, email traffic).\n    \xB7 VPN connections, remote access, and\
        \ cloud service communications.\n    \xB7 Any communication that traverses\
        \ the organisational perimeter, regardless of whether it involves a specific\
        \ external system."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-04
      description: Inventories of services provided by suppliers are maintained.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-04
      ref_id: ID.AM-04.1
      description: Organisations shall keep a clear and up-to-date list of all external
        services it uses, including how they connect to their systems. These services
        shall be reviewed and approved before use, and the list shall be updated whenever
        changes happen.
      annotation: "The goal of this control is to ensure that all external services\
        \ used by the organisation are clearly identified, reviewed, and kept up to\
        \ date to reduce the risk of unauthorised access, unmanaged third-party dependencies,\
        \ or service disruption across ICT and OT environments.\n\nTo achieve this\
        \ goal:\n\xB7 Maintain an Inventory of External Services\n    All external\
        \ services relied upon by the organisation should be identified and documented.\
        \ This includes services used in both IT and OT environments. The inventory\
        \ should be updated whenever services are added, changed, or removed.\n\xB7\
        \ Describe and Map Service Connections\n    The way each external service\
        \ connects to internal systems should be clearly described and recorded. This\
        \ includes remote access tools, cloud-based SCADA platforms, and vendor-managed\
        \ OT systems.\n\xB7 Review and Approve Services Before Use\n    External services\
        \ should be reviewed and approved before being used. This process should verify\
        \ that the service aligns with internal security, compliance, and operational\
        \ requirements.\n\xB7 Categorise and Classify Services\n    External services\
        \ should be categorised by type (e.g. IaaS, SaaS, APIs) and classified based\
        \ on their criticality and data sensitivity. This helps prioritise oversight\
        \ and risk management efforts.\n\xB7 Integrate with Risk and Change Management\n\
        \    The inventory should be integrated into broader risk and change management\
        \ processes. Any changes to external services should trigger a review of associated\
        \ risks and required controls."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-04.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-04
      ref_id: ID.AM-04.2
      description: The organisation shall map, document and authorise the flow of
        information to/from external systems and update the flow when changes occur.
      annotation: "The goal of this control is to ensure that the flow of information\
        \ to and from external systems is clearly understood, securely managed, and\
        \ kept up to date to reduce the risk of data leakage, unauthorised access,\
        \ or disruption across ICT and OT environments.\n\nTo achieve this goal:\n\
        \xB7 Identify and Map Data Pathways\n    All pathways through which data enters\
        \ or exits the organisation\u2019s systems should be identified and documented.\
        \ This includes functions, ports, protocols, and services used in both IT\
        \ and OT environments.\n\xB7 Document Data Flows in Detail\n    Records should\
        \ describe the types of data being transferred, the systems involved, and\
        \ the security measures applied (e.g. encryption, authentication, access controls).\
        \ This supports transparency and secure data handling.\n\xB7 Authorise and\
        \ Control Access\n    Only designated and authorised personnel should be allowed\
        \ to approve and manage data transfers. This helps prevent unauthorised access\
        \ and ensures accountability.\n\xB7 Review and Update Regularly\n    Information\
        \ flow documentation should be reviewed and updated whenever systems, processes,\
        \ or external connections change. This ensures that controls remain effective\
        \ and aligned with the current environment.\n\nThe two controls \u2014 ID.AM-03-3\
        \ and ID.AM-04.2 \u2014 are closely related but focus on different scopes\
        \ of information flow and network activity. This control focuses on granular,\
        \ content-specific data flows between the organisation and specific external\
        \ systems. It includes:\n\xB7 Data transfers to/from third-party platforms\
        \ such as CRM systems, cloud storage providers, and external APIs.\n\xB7 File\
        \ transfers, API calls, and database synchronisation with external systems."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-05
      description: Assets are prioritised based on classification, criticality, resources,
        and impact on the mission.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-05
      ref_id: ID.AM-05.1
      description: "The organisation\u2019s assets shall be prioritised based on classification,\
        \ criticality, and business value."
      annotation: "The goal of this control is to ensure that all organisational assets,\
        \ such as devices, systems, services, data, and business processes, are prioritised\
        \ based on their classification, criticality, and business value. \n\nThis\
        \ prioritisation helps direct protection efforts toward the most important\
        \ assets, supporting operational continuity, security, and compliance.\n\n\
        To make this happen, the following steps should be considered:\n\xB7 Asset\
        \ Identification\n    All relevant assets, including devices, systems, software,\
        \ cloud services, data, employees, and business processes, should be identified\
        \ and recorded in a central inventory.\n\xB7 Asset Classification\n    Each\
        \ asset should be classified based on its role:\n    \xB7 Primary assets should\
        \ be defined as those directly supporting core business functions.\n    \xB7\
        \ Secondary assets should be defined as those that support, protect, or enable\
        \ primary assets.\n\xB7 Criticality Assessment\n    \xB7 The organisation\
        \ should assess how critical each asset is to business continuity.\n    \xB7\
        \ The assessment should consider potential impacts such as operational disruption,\
        \ financial loss, legal or regulatory consequences, safety risks, and reputational\
        \ damage.\n\xB7 Prioritisation Method\n    A consistent scoring or ranking\
        \ method should be used to prioritise assets based on classification, criticality,\
        \ and business value.\n\xB7 Ownership Assignment\n    Each asset should have\
        \ an assigned owner responsible for maintaining accurate and up-to-date information.\n\
        \xB7 Regular Review\n    Asset classifications and priorities should be reviewed\
        \ at least annually or when significant changes occur (e.g. new systems, business\
        \ restructuring).\n\xB7 Documentation and Evidence\n    \xB7 The asset register\
        \ should include classification, prioritisation criteria, assigned owners,\
        \ and evidence of regular reviews.\n    \xB7 Definitions of primary and secondary\
        \ assets should be clearly documented."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-07
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-07
      description: Inventories of data and corresponding metadata for designated data
        types are maintained
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-07.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-07
      ref_id: ID.AM-07.1
      description: Data that the organisation stores and uses shall be identified..
      annotation: "The goal of this control is to ensure that all data stored and\
        \ used by the organisation is clearly identified. This supports proper data\
        \ management, protection, and alignment with business and regulatory requirements.\n\
        \nTo achieve this goal, the following should be considered:\n\xB7 Data Identification\n\
        \    All types of data, regardless of format, location, or system, should\
        \ be identified and recorded.\n\xB7 Data Classification\n    Identified data\
        \ should be classified using standard categories such as:\n    \xB7 Public\n\
        \    \xB7 Internal\n    \xB7 Confidential\n    \xB7 Restricted\n\xB7 Data-to-Asset\
        \ Mapping\n    Data should be linked to the assets that store or process it,\
        \ including physical devices, systems, software, and applications listed in\
        \ the inventories from ID.AM-01 and ID.AM-02.\n\xB7 Documentation and Maintenance\n\
        \    Data types, classifications, and associated assets should be documented\
        \ and regularly updated to reflect changes in the environment."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-07.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-07
      ref_id: ID.AM-07.2
      description: Inventories of data and associated metadata shall be maintained
        for designated data types.
      annotation: "The goal of this control is to ensure that inventories of data\
        \ and associated metadata are maintained for designated data types to support\
        \ secure data management, regulatory compliance, and operational integrity\
        \ across ICT and OT environments.\n\nTo achieve this goal:\n\xB7 Define a\
        \ Data Classification Scheme\n    A classification scheme should be established\
        \ to categorise data types based on sensitivity and usage. This scheme should\
        \ guide how data is handled, protected, and retained.\n\xB7 Apply Security\
        \ Measures by Classification Level\n    Appropriate security controls should\
        \ be implemented for each classification level. These may include encryption,\
        \ role-based access controls, and tailored data retention policies.\n\xB7\
        \ Identify and Protect Sensitive Data Types\n    Inventories should include\
        \ sensitive data such as:\n    \xB7 Personally identifiable information (PII)\n\
        \    \xB7 Financial and health information\n    \xB7 Confidential business\
        \ data\n    \xB7 Intellectual property\n    \xB7 Government and personnel\
        \ records\n    OT environments should also include operational data critical\
        \ to safety and reliability.\n\xB7 Track Metadata for Each Data Instance\n\
        \    Metadata should be maintained to support data governance. This includes:\n\
        \    \xB7 Descriptive metadata (e.g. title, author, keywords)\n    \xB7 Structural\
        \ metadata (e.g. format, schema)\n    \xB7 Administrative metadata (e.g. access\
        \ rights, retention policy)\n    \xB7 Technical metadata (e.g. encoding, checksum)\n\
        \xB7 Monitor Data Provenance and Location\n    The origin, ownership, and\
        \ geolocation of each data instance should be documented. This helps to understand\
        \ where and how data is stored and processed, especially in distributed or\
        \ OT systems.\n\xB7 Continuously Discover and Analyse Ad Hoc Data\n    Processes\
        \ should be in place to identify new instances of sensitive data not captured\
        \ by initial inventories. This helps address gaps in data flow mapping and\
        \ supports ongoing data protection.\n\xB7 Consider Using the Traffic Light\
        \ Protocol (TLP)\n    TLP should be considered as a method to classify and\
        \ share cybersecurity-related data, especially in incident response and threat\
        \ intelligence contexts."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am
      ref_id: ID.AM-08
      description: Systems, hardware, software, services, and data are managed throughout
        their life cycles.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.2
      description: Patches and security updates for operating systems and critical
        system components shall be installed.
      annotation: "The goal of this control is to ensure that operating systems and\
        \ critical system components are kept secure and up-to-date by installing\
        \ patches and security updates in a timely and controlled manner.\n\nTo achieve\
        \ this goal, the following should be considered:\n\xB7 Timely Updates\n  \
        \  Patches and security updates should be installed as soon as possible, especially\
        \ for critical systems.\n\xB7 Industrial Systems\n    Firmware updates for\
        \ industrial assets (e.g. PLCs, HMIs) should be included in the patching process.\n\
        \xB7 Centralised Management\n    A Centralised patch management system should\
        \ be used to automate and streamline patch deployment.\n\xB7 Testing Before\
        \ Deployment\n\xB7     Patches should be tested in a controlled environment\
        \ to avoid disruptions.\n    \xB7 A test environment should closely mirror\
        \ the production setup.\n\xB7 Phased Rollouts\n    \xB7 Where appropriate,\
        \ test groups, pilot users, and phased rollouts should be used.\n    \xB7\
        \ A rollback procedure should be in place in case issues arise.\n\xB7 Trusted\
        \ Sources Only\n    \xB7 Patches should only be downloaded from verified,\
        \ trusted sources.\n    \xB7 Links in emails or advertisements should be avoided.\n\
        \xB7 Minimal Software Footprint\n    Only essential applications should be\
        \ installed. These should be regularly patched and updated.\n\xB7 Safe Update\
        \ Practices\n    \xB7 Automatic updates should be enabled when connected to\
        \ trusted networks.\n    \xB7 Updates should not be performed over untrusted\
        \ networks (e.g. public Wi-Fi).\n\xB7 Supported Software Only\n    \xB7 Only\
        \ vendor-supported and up-to-date software versions should be used.\n    \xB7\
        \ End-of-life (EOL) software should be decommissioned as soon as possible.\n\
        \xB7 Regular Checks\n    If automatic updates are not possible, a regular\
        \ schedule (e.g. monthly) should be set to manually check for and install\
        \ updates.\n\xB7 Update Monitoring Tools\n    Tools that notify about available\
        \ updates should be configured to monitor all installed applications."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.3
      description: The organisation shall enforce accountability for all its business-critical
        assets throughout the system lifecycle, including removal, transfers, and
        disposal.
      annotation: "The goal of this control is to ensure accountability for all business-critical\
        \ assets throughout their lifecycle, including deployment, movement, and disposal,\
        \ to reduce the risk of unauthorised access, data leakage, or operational\
        \ disruption across ICT and OT environments.\n\nTo achieve this goal:\n\xB7\
        \ Secure Assets Before Deployment\n    Systems, hardware, software, and services\
        \ should be properly configured and secured before being introduced into production\
        \ environments.\n\xB7 Identify and Remove Redundant Assets\n    Redundant\
        \ or unused systems, software, and services that increase the attack surface\
        \ should be periodically identified and removed.\n\xB7 Monitor and Document\
        \ Asset Movements\n    Movements of business-critical assets should be tracked,\
        \ and documentation should be maintained to ensure traceability and accountability.\n\
        \xB7 Authorise Asset Transfers\n    Business-critical assets should only be\
        \ allowed to enter or leave facilities with proper Authorisation, especially\
        \ in OT environments where physical asset control is critical.\n\xB7 Dispose\
        \ of Assets Securely\n    Disposal of business-critical assets should be conducted\
        \ in a secure, responsible, and auditable manner to prevent data leakage or\
        \ unauthorised reuse.\n\xB7 Update Inventories Promptly\n    Asset inventories\
        \ should be updated whenever systems, hardware, software, or services are\
        \ moved, transferred, removed, or decommissioned."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.4
      description: The organisation shall ensure that the necessary measures are taken
        to deal with loss, misuse, damage, or theft of assets.
      annotation: "The goal of this control is to ensure that appropriate measures\
        \ are in place to prevent and respond to the loss, misuse, damage, or theft\
        \ of assets, in order to protect business operations and reduce security risks\
        \ across ICT and OT environments.\n\nTo achieve this goal:\n\xB7 Apply Physical\
        \ Security Measures\n    Physical protections such as locks, surveillance\
        \ cameras, and alarms should be used to secure facilities and critical assets,\
        \ including those in OT environments.\n\xB7 Implement Technical Safeguards\n\
        \    Technical controls such as encryption, secure data erasure, and regular\
        \ backups should be applied to protect data and systems from unauthorised\
        \ access or loss.\n\xB7 Establish Organisational Controls\n    Policies, procedures,\
        \ and user agreements should be in place to define responsibilities and expectations.\
        \ Mobile Device Management (MDM) and other administrative tools should be\
        \ used to manage asset usage.\n\xB7 Conduct Regular Audits and Inventory Checks\n\
        \    Periodic audits and asset inventories should be performed to verify that\
        \ all assets are accounted for and properly managed.\n\xB7 Restrict Access\
        \ to Sensitive Assets\n    Access to critical systems, data, and physical\
        \ areas should be limited to authorised personnel only, especially in environments\
        \ where operational continuity is essential.\n\xB7 Provide Employee Awareness\
        \ and Training\n    Staff should be trained on asset protection practices\
        \ and encouraged to report suspicious activity or incidents involving asset\
        \ misuse or loss.\n\xB7 Maintain Appropriate Insurance Coverage\n    Insurance\
        \ policies should be in place to help mitigate financial losses resulting\
        \ from asset theft, damage, or other incidents."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.5
      description: The organisation shall ensure that disposal actions are approved,
        tracked, documented, and verified.
      annotation: "The goal of this control is to ensure that all disposal actions\
        \ involving information systems, data, or physical assets are properly authorised,\
        \ traceable, and verifiable to reduce risks, maintain compliance, and protect\
        \ sensitive information, especially in operational technology (OT) environments.\n\
        \nTo achieve this goal, the following steps should be considered:\n\xB7 Approval:\
        \ Disposal actions should be reviewed and approved by authorised personnel\
        \ before execution.\n    This ensures alignment with internal policies and\
        \ external regulations.\n\xB7 Tracking: Each disposal action should be logged\
        \ with key details, including the asset or media type, disposal method, date,\
        \ and individuals involved.\n\xB7 Documentation: All steps, from approval\
        \ to verification, should be clearly documented. This includes approval records,\
        \ tracking logs, and any supporting evidence.\n\xB7 Verification: Disposal\
        \ should be verified to confirm it was completed correctly. This may involve\
        \ checking that data was securely wiped or that physical destruction was effective.\n\
        \nThis structured approach helps maintain accountability and security, particularly\
        \ in OT environments where improper disposal can lead to operational disruptions\
        \ or safety risks."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.6
      description: The organisation shall plan, perform and document preventive maintenance
        and repairs on its critical system components according to approved processes
        and tools.
      annotation: "The goal of this control is to ensure that preventive maintenance\
        \ and repairs on critical system components are planned, performed, and documented\
        \ in a secure and consistent manner to maintain system reliability and reduce\
        \ operational risks across ICT and OT environments.\n\nTo achieve this goal:\n\
        \xB7 Document Maintenance Procedures\n    Maintenance policies and procedures\
        \ should be clearly defined and included in the organisation\u2019s cybersecurity\
        \ and operational plans. Oversight of these procedures should be part of management\
        \ responsibilities.\n\xB7 Authorise Maintenance Personnel\n    A process should\
        \ be established to authorise individuals or external providers who perform\
        \ maintenance. A list of approved personnel or organisations should be maintained\
        \ and reviewed regularly.\n\xB7 Schedule and Record Maintenance Activities\n\
        \    Preventive maintenance and repairs should be scheduled, performed, and\
        \ documented according to organisational requirements and vendor specifications.\
        \ Records should be reviewed to ensure completeness and accuracy.\n\xB7 Monitor\
        \ All Maintenance Activities\n    All maintenance, whether performed on-site\
        \ or remotely, should be approved in advance and monitored during execution.\
        \ This includes servicing of components removed from the facility.\n\xB7 Ensure\
        \ Safe and Reliable OT Maintenance\n    Maintenance of OT systems should be\
        \ planned and carried out in a way that keeps operations safe, avoids unnecessary\
        \ downtime, and follows any specific instructions or requirements from equipment\
        \ vendors."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.7
      description: The organisation should prevent unauthorised removal of maintenance
        equipment containing critical system information of the organisation.
      annotation: "The goal of this control is to prevent unauthorised removal of\
        \ maintenance equipment that may contain critical system information, reducing\
        \ the risk of data leakage or theft, especially in operational technology\
        \ (OT) environments.\n\nTo achieve this goal, the following measures should\
        \ be applied:\n\xB7 Verify: Maintenance equipment should be checked to confirm\
        \ it does not contain organisational information before removal\n\xB7 Sanitise\
        \ or Destroy: If sensitive data is present, the equipment should be sanitised\
        \ or securely destroyed according to approved procedures.\n\xB7 Retain Within\
        \ Facility: Equipment should remain within the facility unless removal is\
        \ strictly necessary.\n\xB7 Obtain Exemption: If removal is required, explicit\
        \ authorisation should be obtained from designated personnel or roles.\n\n\
        Maintenance equipment in this context refers to hardware temporarily used\
        \ for servicing or diagnostics, such as external drives, temporary servers,\
        \ or specialised OT/ICS tools, not regular maintenance tools covered under\
        \ control ID.AM-08.9."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.8
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.8
      description: The organisation should pre-approve, monitor and enforce maintenance
        tools for use on its critical systems.
      annotation: "The goal of this control is to ensure that maintenance tools used\
        \ on critical systems are pre-approved, monitored, and enforced to protect\
        \ system integrity, safety, and operational continuity. In OT environments,\
        \ improper tool use can interfere with physical processes, making control\
        \ over tool approval and usage essential for operational safety and reliability.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Identify Critical Systems:\
        \ Systems that impact safety, quality, regulatory compliance, or operational\
        \ throughput should be classified as critical. Metrics such as Mean Time to\
        \ Repair (MTTR) and Mean Time Between Failures (MTBF) should support this\
        \ classification.\n\xB7 Pre-Approve Tools: Only maintenance tools that have\
        \ been reviewed and approved should be allowed for use on critical systems.\
        \ This includes both hardware and software tools such as diagnostic devices,\
        \ packet sniffers, and laptops.\n\xB7 Monitor Usage: The use of maintenance\
        \ tools on critical systems should be actively monitored to detect unauthorised\
        \ or unsafe activity.\n\xB7 Enforce Controls: Policies and technical controls\
        \ should be in place to prevent the use of unapproved tools and to ensure\
        \ conformance with internal procedures and compliance with applicable laws\
        \ and regulations."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.9
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.9
      description: Maintenance tools and portable storage devices shall be inspected
        as they enter the facility and shall be protected by anti-malware solutions
        that scan them for malicious code before they are used on the organisation's
        systems.
      annotation: "The goal of this control is to prevent the introduction of malicious\
        \ code into organisational systems, by ensuring\nthat all maintenance tools\
        \ and portable storage devices are inspected and scanned before use. In OT\
        \ environments, introducing unverified tools or storage devices can compromise\
        \ system integrity and disrupt critical physical operations.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Inspect on Entry: Maintenance\
        \ tools and portable storage devices should be inspected when entering the\
        \ facility, to detect unauthorised or suspicious items.\n\xB7 Scan for Malware:\
        \ All devices should be scanned using up-to-date anti-malware solutions before\
        \ being connected to organisational systems.\n\xB7 Apply to All Tool Types:\
        \ This includes software tools (e.g. diagnostic software, firmware updaters,\
        \ configuration tools, remote access tools), portable storage (e.g. USB drives,\
        \ external hard drives, SD cards), and hardware tools (e.g. laptops, tablets,\
        \ portable diagnostic devices).\n\xB7 Use Non-Destructive Clean-Up: When devices\
        \ are newly acquired or lack a trusted chain of custody, non-destructive sanitisation\
        \ techniques should be applied before first use.\n\xB7 Ensure Conformance\
        \ and Compliance: All actions should conform to internal procedures and comply\
        \ with applicable cybersecurity regulations and industry standards."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:d.am-08.10
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: D.AM-08.10
      description: The organisation shall verify security controls following maintenance
        or repairs/patching, and take action as appropriate.
      annotation: "The goal of this control is to ensure that security controls remain\
        \ effective after maintenance, repairs, or patching activities. In OT environments,\
        \ even small configuration changes can have significant safety or operational\
        \ consequences, making post-maintenance verification critical.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Verify Security Controls: After\
        \ maintenance, systems should be assessed to confirm that no changes have\
        \ weakened security. This includes checking configurations, access permissions,\
        \ and other security-relevant settings.\n\xB7 Update Records: Any changes\
        \ made during maintenance should be documented, including updates to security\
        \ controls or the implementation of new measures.\n\xB7 Report Issues: If\
        \ security concerns are identified during verification, findings should be\
        \ communicated to relevant stakeholders, to ensure awareness and coordinated\
        \ response.\n\xB7 Take Corrective Action: If controls are found to be inadequate\
        \ or compromised, corrective actions should be taken. This may include reconfiguring\
        \ settings, applying additional patches, or strengthening existing controls.\n\
        \xB7 Ensure Conformance and Compliance: All verification and corrective actions\
        \ should conform to internal procedures and comply with applicable laws, regulations,\
        \ and industry standards."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.11
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.11
      description: Remote maintenance and diagnostic activities of organisational
        assets shall be pre-approved and the performance logged.
      annotation: "The goal of this control is to ensure that remote maintenance and\
        \ diagnostic activities are authorised, traceable, and secure. In OT environments,\
        \ remote maintenance must be tightly controlled, as unauthorised changes can\
        \ directly affect the safety and stability of physical systems.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Pre-Approve Activities: All remote\
        \ maintenance and diagnostic activities should be reviewed and approved before\
        \ execution.\n\xB7 Log Performance: Each remote session should be logged in\
        \ detail, including time, duration, personnel involved, and actions taken.\n\
        \xB7 Establish Logging Procedures: Logging and monitoring procedures should\
        \ be documented, approved, communicated, applied, and regularly reviewed,\
        \ ideally on an annual basis.\n\xB7 Prevent Unauthorised Changes: Technical\
        \ and procedural measures should be implemented to detect or prevent unauthorised\
        \ changes to systems, configurations, applications, or infrastructure during\
        \ remote access.\n\xB7 Ensure Conformance and Compliance: All activities should\
        \ conform to internal policies and comply with applicable laws, regulations,\
        \ and industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.12
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.12
      description: Setting up non-local maintenance and diagnostic sessions over remote
        network connections shall require strong authenticators and these connections
        shall be terminated when non-local maintenance is completed.
      annotation: "The goal of this control is to ensure that non-local maintenance\
        \ and diagnostic sessions are securely established and properly terminated\
        \ to prevent unauthorised access or lingering connections. In OT environments,\
        \ secure session setup and termination are essential to prevent persistent\
        \ access paths that could be exploited to disrupt physical operations.\n\n\
        To achieve this goal, the organisation should:\n\xB7 Use Strong Authentication:\
        \ Remote sessions should be protected by strong authenticators that resist\
        \ replay attacks. Multi-factor authentication should be used where possible.\n\
        \xB7 Protect Communications: Cryptographic mechanisms should be implemented\
        \ to ensure the confidentiality and integrity of remote maintenance communications.\n\
        \xB7 Terminate Sessions: Remote connections should be terminated immediately\
        \ after maintenance is completed to reduce exposure to potential threats.\n\
        \xB7 Verify Disconnection: Remote disconnect verification should be used to\
        \ confirm that sessions have been fully closed and are no longer accessible.\n\
        \xB7 Ensure Conformance and Compliance: All remote access activities should\
        \ conform to internal security procedures and comply with applicable laws,\
        \ regulations, and industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08.13
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.am-08
      ref_id: ID.AM-08.13
      description: The organisation shall require remote maintenance diagnostic services
        to be performed from a system that implements security features similar to
        the security features implemented on the equivalent organisation's critical
        system.
      annotation: "The goal of this control is to ensure that remote maintenance and\
        \ diagnostic services are performed from systems that implement security features\
        \ equivalent to those of the organisation\u2019s critical systems. In Operational\
        \ Technology (OT) environments, this alignment is essential to maintain a\
        \ consistent security posture, prevent the introduction of vulnerabilities,\
        \ and protect the safety, reliability, and continuity of physical operations.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Use Strong Authentication:\
        \ Remote systems should implement multi-factor authentication to ensure access\
        \ is restricted to authorised personnel.\n\xB7 Maintain Activity Records:\
        \ Detailed logs of all remote maintenance activities should be maintained\
        \ and reviewed regularly to detect anomalies or unauthorised actions.\n\xB7\
        \ Align Tools and Procedures: All tools and procedures used during remote\
        \ maintenance should align with organisational policies and be documented\
        \ in the relevant cybersecurity or information security plans.\n\xB7 Terminate\
        \ Sessions: Remote sessions should be properly terminated once maintenance\
        \ is complete, to prevent lingering access.\n\xB7 Ensure Conformance and Compliance:\
        \ Remote systems and activities should conform to internal security requirements\
        \ and comply with applicable laws, regulations, and industry standards."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id
      ref_id: ID.RA
      name: Risk Assessment
      description: The cybersecurity risk to the organisation, assets, and individuals
        is understood by the organisation.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      ref_id: ID.RA-01
      description: Vulnerabilities in assets are identified, validated, and recorded
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      ref_id: ID.RA-01.1
      description: Threats and vulnerabilities shall be identified in all relevant
        assets, including software, network and system architectures, and facilities
        that house critical computing assets.
      annotation: "The goal of this control is to help organisations mitigate cybersecurity\
        \ risks by identifying threats and vulnerabilities in their critical assets.\
        \ This includes software, networks, systems, and physical locations that support\
        \ essential computing operations.\n\nTo support this objective, organisations\
        \ should:\n\xB7 Understand Key Concepts\n    \xB7 A vulnerability is a weakness\
        \ in hardware, software, or procedures that could be exploited.\n    \xB7\
        \ A threat is an event or actor that may try to exploit a vulnerability.\n\
        \    \xB7 A risk is the possible impact if a threat successfully exploits\
        \ a vulnerability.\n\xB7 Identify Relevant Assets\n    All critical systems,\
        \ applications, networks, and facilities should be listed and documented.\n\
        \xB7 Respond to Vulnerabilities\n    \xB7 Organisations should act on vulnerabilities\
        \ that are reported by trusted sources (e.g., vendors, service providers,\
        \ government advisories).\n    \xB7 At the basic level, active scanning is\
        \ not required, but known vulnerabilities should be addressed promptly.\n\xB7\
        \ Be Aware of Threats\n    Organisations should stay informed about common\
        \ threats relevant to their sector (e.g., phishing, ransomware"
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      ref_id: ID.RA-01.2
      description: A process shall be established to continuously monitor, identify,
        and document vulnerabilities of the organisation's business critical systems.
      annotation: "The goal of this control is to ensure that vulnerabilities in business-critical\
        \ systems are continuously identified, monitored, and documented to support\
        \ timely risk mitigation and maintain operational resilience.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Use Vulnerability Scanning Where\
        \ Safe\n    Vulnerability scanning should be applied to IT and OT systems\
        \ where it does not disrupt operations or compromise safety. Passive or non-intrusive\
        \ methods should be preferred in OT environments.\n\xB7 Deploy Vulnerability\
        \ Management Tools\n    Tools should be used to detect unpatched software,\
        \ misconfigurations, and outdated firmware across both IT and OT assets.\n\
        \xB7 Assess Architectures for Weaknesses\n    Network and system architectures,\
        \ including segmentation, remote access paths, and legacy components, should\
        \ be reviewed for design flaws that could expose OT systems to cyber threats.\n\
        \xB7 Monitor Threat Intelligence Sources\n    Public and private sources of\
        \ cyber threat intelligence should be monitored for vulnerabilities affecting\
        \ OT products, industrial control systems (ICS), and vendor-specific technologies.\n\
        \xB7 Review Organisation-Developed Software\n    Custom applications, including\
        \ those used in OT environments (e.g. HMIs, PLC logic), should be analysed\
        \ and tested for insecure coding practices and default configurations.\n\xB7\
        \ Evaluate Operational Procedures\n    Processes and procedures, especially\
        \ those involving remote access, maintenance, and emergency operations, should\
        \ be reviewed for exploitable weaknesses that could impact OT system integrity."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      ref_id: ID.RA-01.3
      description: The organisation shall establish and maintain a documented process
        that enables continuous review, analysis and remediation of vulnerabilities
        and provides for information sharing where applicable.
      annotation: "The goal of this control is to ensure that vulnerabilities are\
        \ continuously reviewed, analysed, and remediated through a documented process\
        \ that also supports information sharing where applicable.\n\nTo achieve this\
        \ goal, the organisation should:\n\xB7 Incorporate Lessons Learned and Emerging\
        \ Threats\n    The process should be updated based on incidents, changes in\
        \ technology, and evolving threats, including those targeting OT systems and\
        \ industrial protocols.\n\xB7 Use Internal Feedback and Metrics\n    Audit\
        \ results, performance indicators, and operator feedback should be used to\
        \ refine the vulnerability management process, especially where manual processes\
        \ are common.\n\xB7 Leverage Software Bills of Materials (SBOMs)\n    SBOMs\
        \ should be used to identify vulnerable components in both IT and OT software\
        \ stacks, including embedded systems and firmware.\n\xB7 Monitor Threat Intelligence\
        \ Sources\n    Trusted sources such as vendor advisories, ICS-CERT, and ENISA\
        \ should be monitored for vulnerabilities affecting OT products, control systems,\
        \ and field devices.\n\xB7 Review Processes and Procedures\n    Operational\
        \ procedures, especially those involving remote access, maintenance, and safety-critical\
        \ functions, should be reviewed for exploitable weaknesses.\n\xB7 Coordinate\
        \ with Engineering and Operations\n    Remediation efforts should be planned\
        \ in coordination with OT and engineering teams to avoid unplanned downtime\
        \ or safety risks."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      ref_id: ID.RA-01.4
      description: "To ensure that organisation's operations are not adversely affected\
        \ by the testing process, performance/load testing and penetration testing\
        \ on the organisation\u2019s systems shall be carried out with care."
      annotation: "The goal of this control is to ensure that performance/load testing\
        \ and penetration testing are conducted carefully to avoid disrupting operations\
        \ or compromising system stability, especially in environments with business-critical\
        \ or safety-critical systems.\n\nTo achieve this goal, the organisation should:\n\
        \xB7 Establish and Maintain Test Programs\n    Test programs for performance/load\
        \ testing and penetration testing should be tailored to the organisation\u2019\
        s size, complexity, and maturity, including OT-specific constraints.\n\xB7\
        \ Use Controlled Testing Environments\n    Penetration testing should be conducted\
        \ in isolated or controlled environments where possible to prevent unintended\
        \ impacts on live OT systems.\n\xB7 Engage Qualified Ethical Hackers\n   \
        \ Experienced ethical hackers should be used to perform penetration testing,\
        \ particularly in complex or sensitive OT environments.\n\xB7 Validate Security\
        \ Measures Post-Test\n    After testing, security controls should be revalidated\
        \ to confirm that defences remain effective and no unintended changes have\
        \ occurred.\n\nDistinction from ID.RA-01.5 (CyFun\xAE Important)\nWhile ID.RA-01.4\
        \ focuses on testing activities such as penetration and load testing, which\
        \ are typically planned, infrequent, and often conducted in controlled environments,\
        \ ID.RA-01.5 addresses the safe execution of vulnerability scanning, which\
        \ is more frequent, often automated, and must be carefully managed to avoid\
        \ unintended disruptions in live OT systems."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      ref_id: ID.RA-01.5
      description: Vulnerability scanning shall not adversely impact system functions.
      annotation: "The goal of this control is to ensure that vulnerability scanning\
        \ does not disrupt or degrade the performance of business-critical systems,\
        \ particularly in Operational Technology (OT) environments where system stability\
        \ and availability are critical.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Schedule Scans During Low-Usage Periods\n    Scans should\
        \ be performed during off-peak hours or planned maintenance windows to minimise\
        \ operational impact.\n\xB7 Use Non-Intrusive Scanning Tools\n    Tools should\
        \ be selected based on their ability to scan without overloading system resources\
        \ or interfering with real-time operations.\n\xB7 Test in Staging Environments\
        \ First\n    Scans should be trialled in non-production environments to identify\
        \ potential issues before deployment in live systems.\n\xB7 Apply Incremental\
        \ Scanning\n    Scanning should be broken down into smaller, manageable segments\
        \ to reduce system load and avoid overwhelming critical components.\n\xB7\
        \ Monitor System Performance During Scans\n    System behaviour should be\
        \ actively monitored during scanning to detect and respond to any performance\
        \ degradation or anomalies.\n\nDistinction from ID.RA-01.4 (CyFun\xAE Essential)\n\
        While ID.RA-01.4 focuses on testing activities such as penetration and load\
        \ testing, which are typically planned, infrequent, and often conducted in\
        \ controlled environments, ID.RA-01.5 addresses the safe execution of vulnerability\
        \ scanning, which is more frequent, often automated, and must be carefully\
        \ managed to avoid unintended disruptions in live OT systems."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01.6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-01
      ref_id: ID.RA-01.6
      description: Vulnerabilities shall be identified and managed in all relevant
        assets, including software, network and system architectures, and facilities.
      annotation: "The goal of this control is to ensure that vulnerabilities are\
        \ systematically identified and managed across all relevant assets, including\
        \ software, network and system architectures, and physical facilities. This\
        \ builds on control ID.RA-01.1, which focuses on identifying both threats\
        \ and vulnerabilities to support risk reduction.\n\nTo achieve this goal,\
        \ the organisation should:\n\xB7 Extend the Scope of Vulnerability Management\n\
        \    Vulnerability identification and remediation should cover all relevant\
        \ assets, including IT and OT systems, applications, network designs, and\
        \ facilities that support critical operations.\n\xB7 Maintain a Dedicated\
        \ Vulnerability Management Process\n    A structured process should be in\
        \ place to continuously track, assess, and mitigate vulnerabilities, distinct\
        \ from threat intelligence activities.\n\xB7 Differentiate Between Threat\
        \ Intelligence and Vulnerability Management\n    Separate processes or evidence\
        \ should be maintained to distinguish between identifying external threats\
        \ (e.g. threat actors, campaigns) and managing internal weaknesses (e.g. unpatched\
        \ systems, misconfigurations).\n\xB7 Integrate with Broader Risk Management\n\
        \    The vulnerability management process should align with the organisation\u2019\
        s overall risk management framework and support timely decision-making.\n\xB7\
        \ Ensure OT-Specific Considerations\n    In OT environments, vulnerability\
        \ management should account for legacy systems, vendor dependencies, and operational\
        \ constraints that may limit patching or scanning options."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      ref_id: ID.RA-02
      description: Cyber threat intelligence is received from information sharing
        forums and sources.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-02
      ref_id: ID.RA-02.1
      description: A threat and vulnerability awareness programme that includes a
        cross-organisation information-sharing capability shall be implemented.
      annotation: "The goal of this control is to strengthen the organisation\u2019\
        s ability to anticipate and respond to cyber threats by implementing a threat\
        \ and vulnerability awareness program that includes cross-organisational information\
        \ sharing.\n\nTo achieve this goal, the organisation should:\n\xB7 Monitor\
        \ Threat Actor Tactics and Emerging Vulnerabilities\n    Cyber threat intelligence\
        \ should include up-to-date information on threat actors, their tactics, techniques,\
        \ and procedures (TTPs), as well as vulnerabilities in emerging technologies\
        \ (e.g. AI-enabled attacks, data poisoning in machine learning).\n\xB7 Establish\
        \ Ongoing External Engagement\n    The organisation should maintain active\
        \ participation in security groups, forums, and professional associations\
        \ to receive alerts, advisories, and peer insights relevant to both IT and\
        \ OT environments.\n\xB7 Enable Information Sharing\n    The program should\
        \ support the sharing of unclassified and, where appropriate, classified information\
        \ about vulnerabilities and incidents across departments and with trusted\
        \ external partners.\n\xB7 Support OT-Specific Awareness\n    Threat intelligence\
        \ should include OT-specific sources (e.g. ICS-CERT, vendor advisories) to\
        \ address vulnerabilities in industrial control systems, legacy devices, and\
        \ sector-specific technologies.\n\xB7 Differentiate Threat Intelligence from\
        \ Vulnerability Management\n    The awareness program should complement, but\
        \ remain distinct from, vulnerability management processes by focusing on\
        \ external threat developments and strategic insights."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-02
      ref_id: ID.RA-02.2
      description: Automated mechanisms shall be implemented to disseminate security
        alerts and advisories to relevant organisation stakeholders.
      annotation: "The goal of this control is to ensure that security alerts and\
        \ advisories are delivered promptly and reliably to relevant stakeholders\
        \ through automated mechanisms, enabling timely awareness and response across\
        \ the organisation.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Implement Centralised Security Platforms\n    Solutions such as SIEM (Security\
        \ Information and Event Management), XDR (Extended Detection and Response),\
        \ SOAR (Security Orchestration, Automation, and Response), or UEBA (User and\
        \ Entity Behaviour Analytics) should be used to collect, analyse, and correlate\
        \ alerts from multiple sources, including OT and IT systems.\n\xB7 Automate\
        \ Alert Distribution\n    Alerts should be configured to automatically notify\
        \ stakeholders via email, messaging platforms, or other channels to ensure\
        \ rapid dissemination of critical information.\n\xB7 Use Real-Time Dashboards\n\
        \    Dashboards should be implemented to provide continuous visibility into\
        \ security alerts and advisories, supporting situational awareness and decision-making.\n\
        \xB7 Integrate with Incident Response Platforms\n    Automated mechanisms\
        \ should support the distribution of alerts to incident response teams, ensuring\
        \ they have the latest information to act effectively.\n\xB7 Pull from External\
        \ Threat Intelligence Sources\n    Automated tools should retrieve data from\
        \ trusted external sources to enrich internal alerts with broader threat context,\
        \ including OT-specific advisories."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      ref_id: ID.RA-03
      description: Internal and external threats to the organisation are identified
        and recorded.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-03
      ref_id: ID.RA-03.1
      description: Threats shall be identified and assessed in relation to all relevant
        assets, including software, network and system architectures, and facilities.
      annotation: "The goal of this control is to ensure that threats are systematically\
        \ identified and assessed in relation to all relevant assets, including software,\
        \ network and system architectures, and facilities. This builds on ID.RA-01.1,\
        \ which establishes the foundation for identifying both threats and vulnerabilities\
        \ across critical assets.\n\nTo achieve this goal, the organisation should:\n\
        \xB7 Extend Threat Identification Across All Assets\n    Threats should be\
        \ assessed in relation to all relevant assets, including IT and OT systems,\
        \ applications, network designs, and physical facilities that support critical\
        \ operations.\n\xB7 Maintain a Dedicated Threat Intelligence Process\n   \
        \ A structured process should be in place to gather, analyse, and assess threat\
        \ intelligence from internal and external sources, including sector-specific\
        \ advisories and OT-focused threat feeds.\n\xB7 Differentiate Threat Intelligence\
        \ from Vulnerability Management\n    Threat intelligence should be managed\
        \ separately from vulnerability management, with distinct processes and evidence\
        \ to ensure clarity and focus. Threats refer to potential actors or events,\
        \ while vulnerabilities refer to weaknesses that could be exploited.\n\xB7\
        \ Integrate with Risk Analysis\n    Identified threats should be linked to\
        \ known vulnerabilities and recorded in a central risk register to support\
        \ prioritisation and mitigation planning, as outlined in ID.RA-01.1.\n\xB7\
        \ Include OT-Specific Threats\n    Threat assessments should consider OT-specific\
        \ risks such as supply chain compromise, unauthorised remote access, and exploitation\
        \ of legacy systems or proprietary protocols."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      ref_id: ID.RA-05
      description: Threats, vulnerabilities, likelihoods, and impacts are used to
        understand inherent risk and inform risk response prioritisation.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05
      ref_id: ID.RA-05.1
      description: The organisation shall conduct risk assessments in which risk is
        determined by threats, vulnerabilities and the impact on business processes
        and assets.
      annotation: "The goal of this control is to ensure that risk assessments are\
        \ conducted by evaluating threats, vulnerabilities, and their potential impact\
        \ on business processes and assets. This supports informed decision-making\
        \ and effective risk mitigation.\n\nTo achieve this goal, the following should\
        \ be considered:\n\xB7 Identify Threats and Vulnerabilities\n    Assessments\
        \ should include threats and vulnerabilities across software, network and\
        \ system architectures, and facilities housing critical computing assets.\n\
        \xB7 Evaluate Business Impact\n    The potential impact on business operations,\
        \ services, and assets should be analysed to determine the severity of each\
        \ risk.\n\xB7 Include Human Factors\n    Human behaviour should be considered\
        \ when designing and applying security policies, especially in operational\
        \ technology (OT) environments.\n\xB7 Document and Review\n    Risk assessments\
        \ should be documented, regularly reviewed, and updated to reflect changes\
        \ in systems, operations, or the threat landscape."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05
      ref_id: ID.RA-05.2
      description: The organisation shall conduct and document risk assessments in
        which risk is determined by threats, vulnerabilities, impact on business processes
        and assets, and likelihood of their occurrence.
      annotation: "The goal of this control is to ensure that risk assessments are\
        \ conducted and documented using a structured approach that considers threats,\
        \ vulnerabilities, business impact, and likelihood. This supports informed\
        \ decision-\xAD making and prioritisation of cybersecurity efforts across\
        \ both IT and OT environments.\n\nTo achieve this goal, the organisation should:\n\
        \xB7 Include Internal and External Threats\n    Risk assessments should consider\
        \ threats originating from within the organisation as well as from external\
        \ actors.\n\xB7 Apply Recognised Risk Analysis Methods\n    Qualitative and/or\
        \ quantitative methods \u2014 such as the MAPGOOD model, ISO/IEC 27005, or\
        \ the CIS Risk Assessment Method \u2014 should be used. These methods may\
        \ be supported by risk management software tools.\n\xB7 Prioritise Based on\
        \ Likelihood and Impact\n    Cybersecurity resources and investments should\
        \ be allocated based on the estimated likelihood of threats and the potential\
        \ impact on business processes and critical assets.\n\xB7 Ensure OT-Specific\
        \ Risk Considerations\n    Risk assessments should account for OT-specific\
        \ factors such as safety implications, system availability, legacy technologies,\
        \ and operational constraints."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-05
      ref_id: ID.RA-05.3
      description: Risk assessment results shall be disseminated to relevant stakeholders.
      annotation: "The goal of this control is to ensure that risk assessment results\
        \ are communicated effectively to relevant stakeholders, enabling informed\
        \ decisions and coordinated responses across the organisation.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Define a Communication Plan or\
        \ Procedure\n    A documented process should specify how, when, and to whom\
        \ risk-related information is communicated. This should include both internal\
        \ and external stakeholders.\n\xB7 Ensure Timely and Clear Communication\n\
        \    Risk information should be shared promptly and in a format that is easy\
        \ to understand, especially for non-technical stakeholders involved in operational\
        \ or strategic decision-making.\n\xB7 Verify Stakeholder Contact Information\n\
        \    Stakeholder contact details should be reviewed at least annually to ensure\
        \ accuracy and reliability of communications.\n\xB7 Support OT-Specific Communication\
        \ Needs\n    Communication procedures should account for OT-specific roles,\
        \ such as engineering, maintenance, and operations teams, ensuring they receive\
        \ relevant risk information tied to system availability, safety, and continuity."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      ref_id: ID.RA-06
      description: Risk responses are chosen, prioritised, planned, tracked, and communicated.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-06
      ref_id: ID.RA-06.1
      description: Risk responses shall be identified, prioritised, planned, tracked
        and communicated.
      annotation: "The goal of this control is to ensure that risk responses are clearly\
        \ identified, prioritised, planned, tracked, and communicated to support effective\
        \ risk mitigation and informed decision-making across the organisation.\n\n\
        To achieve this goal, the organisation should:\n\xB7 Apply Risk Response Criteria\n\
        \    Decisions to accept, transfer, mitigate, or avoid risk should follow\
        \ the organisation\u2019s vulnerability management criteria, as referenced\
        \ in ID.RA-08.1.\n\xB7 Select Compensating Controls Thoughtfully\n    Where\
        \ direct mitigation is not feasible, compensating controls should be selected\
        \ based on the same criteria to ensure consistent risk reduction.\n\xB7 Base\
        \ Actions on Risk Assessment Findings\n    All risk response decisions should\
        \ be grounded in the results of documented risk assessments, ensuring alignment\
        \ with actual threats, vulnerabilities, and business impact.\n\xB7 Track Implementation\
        \ Progress\n    Risk response actions should be tracked using structured tools\
        \ such as a risk register, plan of action and milestones, or risk detail reports.\n\
        \xB7 Communicate in Priority Order\n    Planned risk responses should be communicated\
        \ to affected stakeholders in order of priority, ensuring timely awareness\
        \ and coordination.\n\xB7 Include OT-Specific Considerations\n    Risk responses\
        \ in OT environments should account for operational constraints, safety requirements,\
        \ and system availability, especially when planning mitigation or compensating\
        \ controls."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-08
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra
      ref_id: ID.RA-08
      description: Processes for receiving, analysing, and responding to vulnerability
        disclosures are established .
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-08.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-08
      ref_id: ID.RA-08.1
      description: The organisation shall establish and implement a vulnerability
        management plan to identify, analyse, assess, mitigate and communicate all
        types of vulnerabilities including in the form of a Coordinated Vulnerability
        Disclosure (CVD) according to applicable legal modalities."
      annotation: "The goal of this control is to ensure that all types of vulnerabilities\
        \ are systematically identified, analysed, assessed, mitigated, and communicated\
        \ through a documented vulnerability management plan. This includes handling\
        \ disclosures in line with Coordinated Vulnerability Disclosure (CVD) practices\
        \ and applicable legal requirements.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Establish a Comprehensive Vulnerability Management Plan\n\
        \    The plan should cover vulnerabilities from internal testing, external\
        \ sources such as security bulletins, and disclosures from researchers, vendors,\
        \ partners, or government cybersecurity bodies.\n\xB7 Assign Responsibilities\
        \ and Monitor Implementation\n    Clear roles should be defined for processing,\
        \ analysing, and responding to disclosed vulnerabilities. Implementation of\
        \ procedures should be monitored to ensure timely and effective handling.\n\
        \xB7 Support Coordinated Vulnerability Disclosure (CVD)\n    The plan should\
        \ include procedures for receiving and responding to vulnerability reports\
        \ from external parties. CVD practices should align with guidance provided\
        \ by ENISA\u2019s CVD framework, which outlines legal, technical, and communication\
        \ considerations.\n\xB7 Ensure OT-Specific Coverage\n    The plan should address\
        \ vulnerabilities in OT environments, including legacy systems, vendor-managed\
        \ components, and embedded firmware, where patching or mitigation may require\
        \ coordination with engineering teams."
      implementation_groups:
      - I
      - IK
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-08.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.ra-08
      ref_id: ID.RA-08.2
      description: The organisation shall implement automated mechanisms for disseminating
        and tracking remedial measures related to vulnerability information that automatically
        handles vulnerability data collection, disseminates information, tracks remedial
        measures, includes reporting and accountability, and enables continuous monitoring.
      annotation: "The goal of this control is to ensure that vulnerability-related\
        \ information is automatically collected, disseminated, tracked, and acted\
        \ upon through a documented and automated vulnerability management process.\
        \ This includes enabling continuous monitoring, reporting, and accountability\
        \ to support timely and effective remediation.\n\nTo achieve this goal, the\
        \ organisation should:\n\xB7 Automate Vulnerability Data Collection and Distribution\n\
        \    Vulnerability information should be gathered from internal sources (e.g.\
        \ audits, OT/IT scans) and external sources (e.g. ENISA advisories, threat\
        \ intelligence feeds, vendor bulletins). This information should be automatically\
        \ distributed to relevant stakeholders using dashboards, alerts, or integrated\
        \ communication tools.\n\xB7 Track Remediation Actions and Monitor Progress\n\
        \    Automated systems should track the implementation of remediation measures\
        \ such as patching, configuration changes, or compensating controls. Progress\
        \ should be monitored to ensure timely resolution.\n\xB7 Generate Reports\
        \ and Ensure Accountability\n    Regular reports should be generated to provide\
        \ visibility into vulnerability status, assigned responsibilities, and remediation\
        \ progress. These reports should support transparency and management oversight.\n\
        \xB7 Enable Continuous Monitoring Through Automation\n    Automated mechanisms\
        \ should be in place to continuously monitor for new vulnerabilities and ensure\
        \ that remediation workflows are updated accordingly.\n\xB7 Evaluate Automation\
        \ Effectiveness\n    The effectiveness of automation should be assessed regularly\
        \ to determine improvements in response time, efficiency, and stakeholder\
        \ awareness. Adjustments should be made if objectives are not met.\n\xB7 Ensure\
        \ OT-Specific Coverage\n    The automation process should include OT environments,\
        \ addressing legacy systems, vendor-managed components, and embedded firmware.\
        \ Coordination with engineering teams may be required for remediation in these\
        \ environments."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id
      ref_id: ID.IM
      name: Improvement
      description: "Improvements to organisational  cybersecurity risk management\
        \ processes, procedures and activities are identified across all CyFun\xAE\
        \  functions."
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im
      ref_id: ID.IM-02
      description: Improvements are identified from security tests and exercises,
        including those made in coordination with suppliers and relevant third parties.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-02
      ref_id: ID.IM-02.1
      description: Security tests and exercises, including those conducted with suppliers
        and relevant third parties, shall be used to identify areas for improvement.
      annotation: "The goal of this control is to identify opportunities for improving\
        \ security, incident response, and resilience by conducting security tests\
        \ and exercises \u2014 internally and in collaboration with suppliers and\
        \ third parties. In Operational Technology (OT) environments, these activities\
        \ are essential to ensure preparedness for incidents that could impact physical\
        \ operations, safety, or service continuity.\n\nTo achieve this goal, the\
        \ organisation should:\n\xB7 Assess Incident Response Readiness: Security\
        \ tests such as tabletop exercises, simulations, internal reviews, and audits\
        \ should be used to identify improvements in incident response procedures.\n\
        \xB7 Coordinate with External Parties: Exercises involving critical service\
        \ providers and product suppliers should be conducted to strengthen business\
        \ continuity, disaster recovery, and incident response capabilities.\n\xB7\
        \ Engage Internal Stakeholders: Relevant internal roles, including senior\
        \ executives, legal, and HR, should be involved in exercises to ensure broad\
        \ organisational awareness and alignment.\n\xB7 Conduct Penetration Testing:\
        \ High-risk systems should undergo penetration testing to identify vulnerabilities.\
        \ These tests should be pre-approved by leadership.\n\xB7 Test Contingency\
        \ Plans: Plans for responding to unauthorised or tampered products or services\
        \ should be tested and refined to ensure effective recovery.\n\xB7 Ensure\
        \ Conformance and Compliance: All testing activities should conform to internal\
        \ procedures and comply with applicable laws, regulations, and industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im
      ref_id: ID.IM-03
      description: Improvements are identified from execution of operational processes,
        procedures, and activities.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.1
      description: The organisation shall conduct post-incident evaluations to analyse
        lessons learned from incident response and recovery, and consequently improve
        processes / procedures / technologies to enhance its cyber resilience.
      annotation: "The goal of this control is to enhance cyber resilience by learning\
        \ from incidents. After each incident, the organisation should analyse what\
        \ happened, how it was handled, and what can be improved in processes, procedures,\
        \ or technologies.\n\nTo achieve this goal, the following should be considered:\n\
        \xB7 Conduct Post-Incident Reviews\n    A structured evaluation should be\
        \ held after each incident, involving all relevant participants.\n\xB7 Reflect\
        \ on Key Questions\n    The review should explore:\n    \xB7 What happened\
        \ and why\n    \xB7 How the response was managed\n    \xB7 What worked well\
        \ and what didn\u2019t\n    \xB7 What actions should be taken to prevent recurrence\n\
        \xB7 Document Lessons Learned\n    Findings from the review should be documented\
        \ and shared with relevant teams.\n\xB7 Update Policies and Procedures\n \
        \   Cybersecurity policies, processes, and procedures should be reviewed and\
        \ updated regularly, at least annually, to reflect lessons learned.\n\xB7\
        \ Improve Tools and Capabilities\n    Where applicable, technologies and response\
        \ tools should be adapted or upgraded based on insights from the incident."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.2
      description: The organisation shall incorporate lessons learned from incident
        handling activities into updated or new incident handling processes and/or
        procedures that are framed by appropriate training after review, approval
        and testing.
      annotation: "The goal of this control is to improve the organisation\u2019s\
        \ incident handling capabilities by incorporating lessons learned from past\
        \ incidents into updated or new processes and procedures. In Operational Technology\
        \ (OT) environments, where incidents can directly affect physical systems\
        \ and operational continuity, applying real-world insights helps strengthen\
        \ response effectiveness and reduce the likelihood of repeated failures.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Cover the Full Incident\
        \ Lifecycle: Lessons should be drawn from all phases of incident handling,\
        \ including identification, categorisation, prioritisation, investigation,\
        \ resolution, recovery, closure, and post-incident review.\n\xB7 Demonstrate\
        \ Process Optimisation: Updates to incident handling procedures should reflect\
        \ insights gained from previous incidents and be clearly documented.\n\xB7\
        \ Collaborate with Suppliers: Lessons learned sessions should be conducted\
        \ jointly with key suppliers to improve coordination and response across the\
        \ supply chain.\n\xB7 Use Performance Metrics: Metrics should be used to track\
        \ and assess the effectiveness of incident handling over time and guide improvements.\n\
        \xB7 Ensure Conformance and Compliance: All updates to processes and procedures\
        \ should conform to internal governance requirements and comply with applicable\
        \ laws, regulations, and industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.3
      description: The organisation shall identify improvements derived from the monitoring,
        measurements, assessments, and lessons learned and consequently translate
        this into improved processes / procedures / technologies to enhance its cyber
        resilience (continuous improvement).
      annotation: "The goal of this control is to enhance the organisation\u2019s\
        \ cyber resilience by identifying improvements from monitoring, measurements,\
        \ assessments, and lessons learned, and translating them into updated processes,\
        \ procedures, or technologies. In Operational Technology (OT) environments,\
        \ where system reliability and safety are tightly linked to cyber performance,\
        \ continuous improvement helps maintain operational integrity and adapt to\
        \ evolving threats.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Use Cyber Resilience Metrics: Metrics should be used to assess the organisation\u2019\
        s ability to withstand and recover from cyber incidents, supporting informed\
        \ risk management and decision-making.\n\xB7 Apply Measures of Effectiveness\
        \ (MOEs): MOEs should be used to evaluate and compare the effectiveness of\
        \ different cyber resilience strategies and guide investment or design decisions.\n\
        \xB7 Implement Objective-Driven Metrics: Metrics should cover preparedness,\
        \ operational continuity during attacks, damage limitation, and recovery and\
        \ restoration capabilities.\n\xB7 Conduct Independent Assessments: Independent\
        \ teams should be engaged to perform assessments and provide objective insights\
        \ into areas for improvement.\n\xB7 Use Structured Scoring Systems: Scoring\
        \ methodologies such as MITRE\u2019s SSM-CR (Situated Scoring Methodology\
        \ for Cyber Resiliency) should be considered to support structured evaluation\
        \ and prioritisation of improvements.\n\xB7 Ensure Conformance and Compliance:\
        \ All improvements should align with internal governance requirements and\
        \ comply with applicable laws, regulations, and industry standards."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.4
      description: The organisation shall collaborate and share information about
        its critical system's related security incidents and mitigation measures with
        designated partners.
      annotation: "The goal of this control is to strengthen cyber resilience by sharing\
        \ information about security incidents and mitigation measures related to\
        \ critical systems with designated partners. In Operational Technology (OT)\
        \ environments, timely and coordinated information exchange helps prevent\
        \ the spread of threats, supports faster recovery, and enhances collective\
        \ defence across interconnected systems.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Define Roles and Authorities: The incident response plan should\
        \ clearly outline roles, responsibilities, and authorisation for sharing incident-related\
        \ information with designated partners.\n\xB7 Train the Response Team: Incident\
        \ response personnel should be regularly trained on procedures for communicating\
        \ with external partners during and after incidents.\n\xB7 Coordinate with\
        \ Partners: Information sharing should include details on incidents, mitigation\
        \ actions, and lessons learned, especially with suppliers and service providers\
        \ involved in critical system operations.\n\xB7 Reference Trusted Guidance:\
        \ Relevant practices should be informed by trusted sources such as ENISA/CERT-EU\
        \ Security Guidance 22-001, which provides recommended mitigation measures\
        \ against critical threats.\n\xB7 Ensure Conformance and Compliance: All collaboration\
        \ and sharing activities should conform to internal policies and comply with\
        \ applicable laws, regulations, and industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.5
      description: Communication of effectiveness of protection technologies shall
        be shared with relevant stakeholders.
      annotation: "The goal of this control is to ensure that the effectiveness of\
        \ protection technologies is clearly communicated to relevant stakeholders.\
        \ In Operational Technology (OT) environments, where protection tools safeguard\
        \ critical physical systems, meaningful communication supports informed decisions,\
        \ risk awareness, and alignment across technical and non-technical teams.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Tailor Communication\
        \ to Stakeholders: Information should be adapted to the needs of different\
        \ audiences; Technical teams may require detailed logs, while executives may\
        \ need high-level summaries linked to business risk.\n\xB7 Go Beyond Technical\
        \ Metrics: Communication should include not only data (e.g. threats blocked,\
        \ incidents detected) but also insights into risk posture, emerging trends,\
        \ and recommended actions.\n\xB7 Include All Relevant Roles: Stakeholders\
        \ such as CISOs, IT security teams, compliance officers, internal auditors,\
        \ and executive leadership should receive the information necessary to support\
        \ their responsibilities.\n\xB7 Monitor and Report Performance: The performance\
        \ of protection technologies (e.g. antivirus, firewalls, intrusion prevention,\
        \ endpoint detection, data loss prevention) should be continuously monitored\
        \ and reported.\n\xB7 Support Continuous Improvement: Communication should\
        \ help identify gaps, inform strategic decisions, and promote a culture of\
        \ transparency and resilience.\n\xB7 Ensure Conformance and Compliance: All\
        \ communication practices should align with internal policies and comply with\
        \ applicable laws, regulations, and industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.6
      description: The organisation shall implement, where feasible, automated mechanisms
        to facilitate the process of information sharing and collaboration.
      annotation: "The goal of this control is to improve the efficiency, accuracy,\
        \ and security of information sharing and collaboration by implementing automated\
        \ mechanisms where feasible. In Operational Technology (OT) environments,\
        \ automation helps reduce manual errors, enforce access controls, and support\
        \ timely decision-making across interconnected systems.\n\nTo achieve this\
        \ goal, the organisation should:\n\xB7 Match Access Authorisations: Automated\
        \ tools should verify that the access rights of information-sharing partners\
        \ align with the sensitivity of the information. Mismatches should be flagged\
        \ before sharing occurs.\n\xB7 Automate Policy Enforcement: Systems should\
        \ automatically evaluate whether information can be shared based on its classification\
        \ and the recipient\u2019s access rights. These checks should be integrated\
        \ with identity and access management (IAM) systems to ensure up-to-date authorisation\
        \ data.\n\xB7 Control Search and Retrieval: Search and retrieval tools should\
        \ enforce access restrictions using metadata tagging and classification, ensuring\
        \ users can only access authorised information.\n\xB7 Monitor and Audit Activities:\
        \ Automated logging and monitoring should track all information-sharing actions.\
        \ Logs should be reviewed regularly to detect unauthorised access or policy\
        \ violations.\n\xB7 Promote Usability and Training: Automated tools should\
        \ be user-friendly to encourage correct usage. Training should be provided\
        \ to ensure users understand how to use these tools effectively and responsibly.\n\
        \xB7 Ensure Conformance and Compliance: All automated mechanisms should align\
        \ with internal policies and comply with applicable laws, regulations, and\
        \ industry standards."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.7
      description: The organisation shall implement independent teams to assess its
        processes, best practices, and technology solutions to safeguard critical
        systems and assets.
      annotation: "The goal of this control is to strengthen the protection of critical\
        \ systems and assets by ensuring objective assessments of organisational processes,\
        \ practices, and technologies. In Operational Technology (OT) environments,\
        \ independent evaluations help identify vulnerabilities, reduce bias, and\
        \ support continuous improvement in system resilience and safety.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Engage Independent Teams\n   \
        \ Independent assessors should include internal personnel not involved in\
        \ the system\u2019s development or operation, and external experts with no\
        \ financial or operational ties to the system.\n\xB7 Ensure Impartiality\n\
        \    Assessors should be free from conflicts of interest. Assessment roles\
        \ should be rotated to avoid familiarity bias. Independence and qualifications\
        \ should be documented.\n\xB7 Define Scope and Criteria Clearly\n    Assessment\
        \ objectives, scope, and evaluation criteria should be agreed upon in advance\
        \ to prevent undue influence from stakeholders.\n\xB7 Establish Independent\
        \ Reporting Lines\n    Assessment results should be reported directly to senior\
        \ management or an oversight body, bypassing the teams responsible for the\
        \ systems under review.\n\xB7 Review Assessment Effectiveness Regularly\n\
        \    The independence and performance of assessment teams should be periodically\
        \ reviewed to maintain objectivity and relevance."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.8
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.8
      description: The organisation shall ensure that the security plan for its critical
        systems facilitates the review, testing, and continual improvement of the
        security protection processes.
      annotation: "The goal of this control is to ensure that the organisation\u2019\
        s security plan for critical systems supports regular review, testing, and\
        \ continuous improvement of protection measures. In Operational Technology\
        \ (OT) environments, this helps maintain system integrity, adapt to evolving\
        \ threats, and align with broader risk management efforts.\n\nTo achieve this\
        \ goal, the organisation should:\n\xB7 Develop and Maintain a Security Plan\n\
        \    A documented plan should describe how critical systems are protected\
        \ from security threats. It should be distinct from, but aligned with, the\
        \ Risk Treatment Plan.\n\xB7 Focus on Operational and Technical Controls\n\
        \    The plan should include defined security objectives, assigned responsibilities,\
        \ security architecture, control measures, and procedures for monitoring,\
        \ testing, and reviewing controls.\n\xB7 Enable Regular Review and Testing\n\
        \    The plan should support scheduled reviews, vulnerability assessments,\
        \ and penetration testing to evaluate the effectiveness of security measures.\n\
        \xB7 Support Continuous Improvement\n    Updates should be based on lessons\
        \ learned, threat intelligence, audit results, and changes in the threat landscape.\n\
        \xB7 Integrate with Risk Management\n    The plan should align with the organisation\u2019\
        s risk treatment and governance processes to ensure consistency and accountability.\n\
        \xB7 Keep the Plan Up to Date\n    The plan should be reviewed and updated\
        \ regularly to reflect system changes, new threats, and evolving operational\
        \ needs."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03.9
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-03
      ref_id: ID.IM-03.9
      description: The organisation shall conduct specialised assessments including
        in-depth monitoring, vulnerability scanning, malicious user testing, insider
        threat assessment, performance/load testing, and verification and validation
        testing on the organisation's critical systems.
      annotation: "The goal of this control is to strengthen the security posture\
        \ of critical systems by conducting specialised assessments that uncover vulnerabilities,\
        \ evaluate performance, and test defences against insider and external threats.\
        \ In Operational Technology (OT) environments, these assessments help validate\
        \ protections and support continuous improvement.\n\nTo achieve this goal,\
        \ the organisation should:\n\xB7 Conduct Specialised Assessments\n    Assessments\
        \ should include in-depth monitoring, vulnerability scanning, malicious user\
        \ testing, insider threat assessments, performance/load testing, and verification\
        \ and validation testing.\n\xB7 Outsource to Accredited Providers\n    Specialised\
        \ assessments may be outsourced, preferably to accredited organisations. Accreditation\
        \ should follow recognised standards such as:\n    \xB7 CREST for penetration\
        \ testing and vulnerability assessments\n    \xB7 ISO/IEC 17025 for testing\
        \ laboratories\n    Accreditation should be granted by recognised bodies such\
        \ as CREST, national accreditation authorities (e.g. BELAC), or industry-specific\
        \ bodies (e.g. PCI Security Standards Council). This ensures assessments are\
        \ conducted with technical competence, impartiality, and in line with best\
        \ practices.\n\xB7 Integrate Findings into Remediation\n    Vulnerabilities\
        \ identified during assessments should be addressed through established remediation\
        \ processes, as outlined in control ID.IM-03.3.\n\xB7 Support Readiness and\
        \ Maturity Evaluation\n    Assessment results should inform organisational\
        \ readiness and performance levels (e.g. CyFun\xAE maturity), guiding targeted\
        \ improvements."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im
      ref_id: ID.IM-04
      description: Incident response plans and other cybersecurity plans that affect
        operations are established, communicated, maintained, and improved.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-04
      ref_id: ID.IM-04.1
      description: Contingency and continuity plans shall be established, communicated,
        maintained, tested, validated, and improved.
      annotation: "The goal of this control is to ensure organisational resilience\
        \ by establishing, maintaining, and improving contingency and continuity plans\
        \ that enable effective response and recovery from disruptions.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Establish Comprehensive Plans\n\
        \    Plans should include:\n    \xB7 Incident Response Plan (IRP)\n    \xB7\
        \ Business Continuity Plan (BCP)\n    \xB7 Disaster Recovery Plan (DRP) _x0008_\n\
        \    These should address operational disruptions, data breaches, and mission-critical\
        \ failures.\n\xB7 Define Clear Plan Content\n    Plans should include:\n \
        \   \xB7 Contact and communication details\n    \xB7 Roles, responsibilities,\
        \ and authorities (aligned with GV.RR-02.1)\n    \xB7 Procedures for common\
        \ scenarios\n    \xB7 Criteria for prioritisation, escalation, and decision-making\
        \ IRPs should cover detection, containment, response, and recovery from cyber\
        \ incidents.\n\xB7 Communicate and Train\n    Plans should be communicated\
        \ to all relevant personnel. A Crisis Management Team should be established\
        \ with representatives from key departments (e.g. IT, legal, HR, PR) and trained\
        \ to act during crises.\n\xB7 Maintain and Review Plans\n    Plans should\
        \ be reviewed at least annually or after major changes or incidents. Updates\
        \ should reflect lessons learned and evolving risks.\n\xB7 Test and Validate\
        \ Regularly\n    Plans should be tested through realistic scenarios. Validation\
        \ should confirm that procedures work as intended and meet operational needs.\
        \ Results should be documented.\n\xB7 Continuously Improve\n    Feedback from\
        \ tests, incidents, and reviews should drive improvements. Enhancements should\
        \ be prioritised based on risk and impact to ensure continuity of essential\
        \ functions.\n\xB7 See also: Policy templates available on www.cyfun.eu"
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-04.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:id.im-04
      ref_id: ID.IM-04.2
      description: The organisation shall coordinate the development and the testing
        of Incident Response Plans and other cybersecurity plans that affect operations
        with stakeholders to ensure that these plans align with overall organisational
        goals and enhance resilience.
      annotation: "The goal of this control is to ensure that Incident Response Plans\
        \ and other cybersecurity plans affecting operations are aligned with organisational\
        \ goals and enhance resilience through coordinated development and testing\
        \ with relevant stakeholders.\n\nTo achieve this goal, the organisation should:\n\
        \xB7 Review and Update Plans Regularly\n    Plans should be reviewed and updated\
        \ to reflect evolving threats, organisational changes, and operational needs.\n\
        \xB7 Engage Stakeholders Early Stakeholders, including internal teams, suppliers,\
        \ and relevant third parties, should be involved early in the planning process\
        \ to ensure alignment and relevance.\n\xB7 Maintain Ongoing Communication\n\
        \    Stakeholders should be kept informed of plan progress, updates, and changes\
        \ to maintain shared understanding and readiness.\n\xB7 Coordinate Testing\
        \ Activities\n    Testing of plans should be coordinated with stakeholders\
        \ to validate effectiveness, clarify roles, and strengthen collaborative response\
        \ capabilities."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr
      assessable: false
      depth: 1
      ref_id: PR
      name: PROTECT
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr
      ref_id: PR.AA
      name: Identity Management, Authentication, and Access Control
      description: Access to physical and logical assets is limited to authorised
        users, services, and hardware and managed commensurate with the assessed risk
        of unauthorised access
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      ref_id: PR.AA-01
      description: Identities and credentials for authorised users, services, and
        hardware are managed by the organisation
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01
      ref_id: PR.AA-01.1
      description: Identities and credentials for authorised users, services, and
        hardware shall be managed.
      annotation: "The goal of this control is to ensure that identities and credentials\
        \ for authorised users, services, and hardware are properly managed to prevent\
        \ unauthorised access and support secure operations in both ICT and OT environments.\
        \ \n\nTo achieve this goal, the following should be considered:\n\xB7 Access\
        \ Requests and Authorisation\n    \xB7 Access should be formally requested,\
        \ documented, and approved by system or data owners.\n    \xB7 Access rights\
        \ should follow the principle of least privilege.\n\xB7 Identity and Credential\
        \ Management\n    \xB7 Individual user accounts should be used; sharing passwords\
        \ should be avoided.\n    \xB7 Default passwords should be changed before\
        \ systems are activated.\n    \xB7 Unused accounts should be disabled immediately.\n\
        \    \xB7 Administrator accounts should be limited, reviewed regularly, and\
        \ not used for daily tasks.\n\xB7 Password Policy\n    \xB7 Strong password\
        \ rules should be enforced.\n    \xB7 Passwords should be changed regularly\
        \ or immediately after suspected compromise.\n    \xB7 A formal password policy\
        \ should be in place (See also: CyFun\xAE Toolbox on www.cyfun.eu).\n    \xB7\
        \ Rights and privileges should be assigned through user groups.\n\xB7 Device\
        \ and Hardware Identity\n    \xB7 Each authorised device should have a unique\
        \ identifier (e.g. MAC address, serial number).\n    \xB7 Devices should be\
        \ physically labelled to support inventory and maintenance.\n\xB7 Shared Access\
        \ to PLCs/HMIs (OT-Specific Measures)\n    \xB7 If individual accounts are\
        \ not feasible, the principle of least privilege should still apply.\n   \
        \ \xB7 A secure jump server or HMI front-end should be used to control access,\
        \ log activity, and add authentication layers.\n\xB7 Secure Remote Access\n\
        \    \xB7 Technical requirements for remote access should be clearly defined\
        \ and documented.\n    \xB7 Secure methods such as VPNs, encrypted protocols\
        \ (e.g. SSH, TLS), and multi-factor authentication (MFA \u2013 see also PR.AA-03.2)\
        \ should be used.\n    \xB7 Remote access should be monitored and logged."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01
      ref_id: PR.AA-01.2
      description: Identities and credentials for authorised users, services and hardware
        shall be managed through automated mechanisms whenever feasible.
      annotation: "The goal of this control is to reduce the risk of credential misuse\
        \ and unauthorised access by automating identity and credential management\
        \ processes, ensuring consistency, scalability, and security across IT and\
        \ OT environments.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Automate Credential Management\n\xB7 Automated systems should be used to\
        \ issue, verify, revoke, and audit credentials for users, services, and hardware.\
        \ This reduces manual errors and improves operational efficiency.\n\xB7 Implement\
        \ Strong Authentication Mechanisms\n\xB7 In alignment with control PR.AA-03.2,\
        \ MFA shall be required for all remote access to the organisation\u2019s networks.\
        \ Multifactor authentication (MFA) should use at least two independent factors:\n\
        \xB7 Knowledge (e.g. password or PIN)\n\xB7 Possession (e.g. token or smartphone)\n\
        \xB7 Inherence (e.g. fingerprint or facial recognition)\n\xB7 These factors\
        \ should be independent to ensure that compromise of one does not affect the\
        \ others.\n\xB7 Use Cryptographic and Token-Based Solutions\n\xB7 Digital\
        \ certificates and identity tokens should be used to authenticate users, devices,\
        \ and services, especially in OT environments where manual credential handling\
        \ may be impractical.\n\xB7 Ensure OT-Specific Integration\n\xB7 Identity\
        \ and access management solutions should support OT systems, including legacy\
        \ devices and vendor-managed components, with minimal disruption to operations.\n\
        \xB7 Where individual user accounts are not feasible (e.g. shared access to\
        \ PLCs or HMIs), access should be routed through secure jump servers with\
        \ logging and additional authentication layers.\n\xB7 Remote access to OT\
        \ systems should use secure protocols (e.g. VPN, SSH, TLS), be time-limited\
        \ (Just-In-Time), and be fully monitored."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01
      ref_id: PR.AA-01.3
      description: System credentials shall be deactivated after a specified period
        of inactivity unless it would compromise the safe operation of (critical)
        processes.
      annotation: "The goal of this control is to ensure that system credentials are\
        \ deactivated after a defined period of inactivity, unless doing so would\
        \ compromise the safe operation of critical processes. This helps reduce the\
        \ risk of unauthorised access while maintaining operational continuity.\n\n\
        To achieve this goal, the organisation should:\n\xB7 Use Service Accounts\
        \ for Automated Operations\n    Service accounts should be used to run applications,\
        \ services, or automated tasks. These accounts should be configured with minimal\
        \ permissions, isolated from user accounts, and monitored separately to support\
        \ auditability and secure automation.\n\xB7 Apply the Principle of Least Privilege\n\
        \    Service accounts should only have the permissions necessary for their\
        \ function. This limits potential misuse and supports secure operations in\
        \ both IT and OT environments.\n\xB7 Monitor and Audit Service Account Activity\n\
        \    Actions performed by service accounts should be logged and reviewed regularly.\
        \ This improves traceability and helps detect anomalies or misuse.\n\xB7 Implement\
        \ Credential Inactivity Policies\n    System credentials, including those\
        \ of service and user accounts, should be automatically deactivated after\
        \ a defined period of inactivity. Exceptions should be documented and justified,\
        \ especially in OT environments where continuous operation is critical.\n\xB7\
        \ Establish Formal Access Procedures for External Parties\n    External access\
        \ should follow a defined process, including role-based access levels, authorisation\
        \ steps, identity verification, and awareness training. Monitoring and revocation\
        \ mechanisms should be in place to manage access violations.\n\xB7 Ensure\
        \ OT-Specific Considerations\n    In OT environments, credential deactivation\
        \ policies should account for system uptime requirements, vendor-managed components,\
        \ and legacy systems. Coordination with engineering teams may be necessary\
        \ to avoid operational disruptions."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01
      ref_id: PR.AA-01.4
      description: 'For transactions within the organisation''s critical systems,
        the organisation shall

        implement Multi Factor Authentication (MFA), cryptographic certificates, identity
        tokens, cryptographic keys and other credentials as appropriate and where
        feasible.'
      annotation: "The goal of this control is to ensure that strong authentication\
        \ mechanisms are applied to transactions within critical systems. This includes\
        \ using Multi-Factor Authentication (MFA \u2013 PR.AA-03.2), cryptographic\
        \ credentials, and other secure methods to protect sensitive operations and\
        \ data exchanges.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Apply Strong Authentication to Critical Transactions\n    Transactions involving\
        \ access to sensitive data, system configuration changes, command execution,\
        \ user/device authentication, or data transmission between systems should\
        \ be protected using MFA, identity tokens, cryptographic keys, or certificates,\
        \ where feasible.\n\xB7 Use Context-Aware and Behaviour-Based Authentication\n\
        \    Strong authentication should include context-based checks (e.g. location,\
        \ time, device) and behavioural biometrics (e.g. typing patterns) to detect\
        \ anomalies and enhance security.\n\xB7 Combine MFA with Single Sign-On (SSO)\n\
        \    MFA should be integrated with SSO solutions to streamline access while\
        \ maintaining robust protection for internal and external critical systems.\n\
        \xB7 Manage Cryptographic Credentials Securely\n    Cryptographic certificates,\
        \ identity tokens, and keys should be issued, stored, rotated, and revoked\
        \ securely. This supports the secure implementation of strong authentication\
        \ mechanisms required by this control and complements PR.AA-03.2, which mandates\
        \ MFA for remote access.\n\xB7 Ensure OT-Specific Feasibility\n    In OT environments,\
        \ authentication methods should be adapted to system constraints, legacy equipment,\
        \ and operational continuity requirements. Coordination with engineering teams\
        \ may be necessary to implement feasible solutions."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-01
      ref_id: PR.AA-01.5
      description: "The organisation\u2019s critical systems shall be monitored for\
        \ atypical use of system credentials. Credentials associated with significant\
        \ risk shall be disabled."
      annotation: "The goal of this control is to detect and respond to abnormal or\
        \ high-risk use of system credentials in critical systems, helping to prevent\
        \ unauthorised access, insider threats, and credential-based attacks.\n\n\
        To achieve this goal, the organisation should:\n\xB7 Detect Atypical Credential\
        \ Use\n    Systems should be monitored for deviations from normal credential\
        \ usage patterns, such as unusual login times, access from unfamiliar locations,\
        \ use of unfamiliar systems, simultaneous logins from distant locations, or\
        \ sudden access to sensitive data.\n\xB7 Limit and Respond to Failed Login\
        \ Attempts\n    A threshold for failed login attempts should be enforced.\
        \ Accounts should be locked automatically after repeated failures and remain\
        \ inaccessible until a defined lockout period expires or an authorised administrator\
        \ resets them.\n\xB7 Manage Credential Lifecycles\n    Credential issuance,\
        \ usage, and revocation should be automated where possible. An up-to-date\
        \ inventory of active credentials should be maintained, and unused or orphaned\
        \ accounts should be regularly reviewed and disabled.\n\xB7 Monitor and Correlate\
        \ Events\n    Security Information and Event Management (SIEM) tools or equivalent\
        \ solutions should be considered to detect anomalies and correlate events\
        \ across systems. Behavioural baselining should be implemented to identify\
        \ deviations from typical usage.\n\xB7 Disable High-Risk Credentials Automatically\n\
        \    Credentials associated with confirmed or high-risk anomalous activity\
        \ should be disabled immediately. Security teams should be notified for investigation\
        \ and response. All actions should be logged for audit and forensic purposes.\n\
        \xB7 Raise User Awareness\n    Users should be trained on secure credential\
        \ practices and encouraged to report suspicious activity or anomalies in access\
        \ behaviour."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      ref_id: PR.AA-02
      description: Identities are proofed and bound to credentials based on the context
        of interactions.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-02
      ref_id: PR.AA-02.1
      description: The organisation shall implement documented procedures for verifying
        the identity of individuals before issuing credentials that provide access
        to the organisation's systems.
      annotation: "The goal of this control, which builds further on GV.RR-04.1, is\
        \ to ensure that only verified individuals are granted access credentials,\
        \ thereby reducing the risk of identity fraud, unauthorised access, and insider\
        \ threats.\n\nTo achieve this goal, the organisation should:\n\xB7 Establish\
        \ Documented Identity Verification Procedures\n    A formal process should\
        \ be developed and approved to verify identities before issuing credentials.\
        \ This process should ensure accountability, traceability, and auditability.\n\
        \xB7 Verify Identity Using Trusted Sources\n    Identity verification should\
        \ rely on official documents such as government-issued ID cards, passports,\
        \ or driver\u2019s licences. For remote or digital onboarding, practices should\
        \ align with ENISA\u2019s Remote Identity Proofing Good Practices.\n\xB7 Prevent\
        \ Identity Fraud and Misuse\n    Procedures should include controls to detect\
        \ and prevent identity theft or impersonation. This helps reduce the risk\
        \ of financial loss, reputational damage, and unauthorised access.\n\xB7 Ensure\
        \ OT-Relevant Adaptation\n    Identity verification processes should be adapted\
        \ for OT environments, especially where third-party technicians or vendor\
        \ personnel require access to critical systems."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-02
      ref_id: PR.AA-02.2
      description: The organisation shall ensure that unique credentials are used
        for each authenticated user, device, and process interacting with the organisation's
        critical systems. These credentials shall be verified, and the unique identifiers
        shall be captured during system interactions. Exceptions may be made for emergency
        access ("break-glass" procedures), provided such access is strictly controlled,
        logged, and reviewed.
      annotation: "The goal of this control is to ensure that each user, device, and\
        \ process interacting with critical systems is uniquely identifiable and authenticated.\
        \ This supports accountability, traceability, and secure access, while allowing\
        \ for controlled exceptions in emergencies.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Assign Unique Credentials\n    Each user, device, and automated\
        \ process should have its own unique credentials. Shared accounts should be\
        \ avoided. All credentials should be verified before access is granted.\n\xB7\
        \ Implement Strong Authentication\n    Multi-Factor Authentication (MFA \u2013\
        \ PR.AA-03.2) has to be used wherever feasible. Authentication mechanisms\
        \ should be resistant to replay attacks and credential reuse. These practices\
        \ align with ENISA\u2019s Secure User Authentication Guidelines, which recommend\
        \ layered and context-aware authentication for critical systems.\n\xB7 Enforce\
        \ Credential Management Practices\n    Password policies and credential rotation\
        \ should be enforced. Credentials should be reviewed and updated regularly,\
        \ especially after role changes or offboarding. This supports the principles\
        \ outlined in ENISA\u2019s NIS2 Technical Implementation Guidance, which emphasise\
        \ secure identity lifecycle management.\n\xB7 Apply Access Control and Monitoring\n\
        \    Access should follow the Principle of Least Privilege. Logs and audit\
        \ trails should be continuously monitored to detect anomalies. Suspicious\
        \ activity should be investigated promptly.\n\xB7 Control Emergency Access\
        \ (\"Break-Glass\")\n    Emergency access should be granted only through designated\
        \ break-glass accounts. These accounts should be tightly controlled, time-limited,\
        \ fully logged, and reviewed after use. Justification and approval should\
        \ be required for each instance.\n\xB7 Promote User Awareness and Training\n\
        \    Personnel should be trained on the importance of using individual credentials\
        \ and reporting suspicious access. Awareness should include the risks of credential\
        \ sharing and misuse.\n\xB7 Ensure OT-Specific Feasibility\n    In OT environments,\
        \ unique credentials should be implemented in a way that respects operational\
        \ constraints and system limitations. Coordination with engineering teams\
        \ may be required."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      ref_id: PR.AA-03
      description: Users, services, and hardware are authenticated.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03
      ref_id: PR.AA-03.1
      description: All wireless access points used by the organisation, including
        those providing guest access, shall be securely configured, managed, and monitored
        to prevent unauthorised  access and ensure network integrity.
      annotation: "The goal of this control is to ensure that all wireless access\
        \ points, including those for guest use, are securely configured, managed,\
        \ and monitored to prevent unauthorised access and protect network integrity.\n\
        To achieve this goal, the following should be considered:\n\xB7 General Wireless\
        \ Security\n    \xB7 Default administrative credentials should be changed\
        \ immediately after installation.\n    \xB7 SSID broadcasting should be disabled\
        \ unless operationally necessary.\n    \xB7 Strong encryption protocols (e.g.\
        \ WPA2 or WPA3 with AES) should be used.\n    \xB7 Physical access to wireless\
        \ access points should be restricted.\n    \xB7 Firmware should be updated\
        \ regularly to address known vulnerabilities.\n    \xB7 Wireless networks\
        \ should be monitored for unauthorised access points and suspicious activity.\n\
        \xB7 Guest Wi-Fi Security\n    \xB7 Guest networks should be isolated from\
        \ internal systems using VLANs or separate SSIDs.\n    \xB7 Bandwidth and\
        \ access restrictions should be applied to guest networks.\n    \xB7 Captive\
        \ portals should be used to display terms of use and optionally log guest\
        \ access.\n    \xB7 Sensitive data should not be stored or transmitted over\
        \ guest networks.\n    \xB7 Guest Wi-Fi should be disabled when not in use\
        \ or outside business hours, if feasible.\n\xB7 Endpoint and User Practices\n\
        \    \xB7 Devices connecting to wireless networks should comply with endpoint\
        \ security policies.\n    \xB7 VPNs should be used when connecting to unknown\
        \ or unsecured networks.\n    \xB7 Wi-Fi credentials should follow password\
        \ policies that enforce complexity and regular updates."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03
      ref_id: PR.AA-03.2
      description: Multi-Factor Authentication (MFA) shall be required to access the
        organisation's networks remotely.
      annotation: "The goal of this control is to protect the organisation\u2019s\
        \ networks by requiring multi-factor authentication (MFA)\nfor all remote\
        \ access, thereby reducing the risk of unauthorised access and credential-based\
        \ attacks.\n\nTo achieve this goal, the following should be considered:\n\xB7\
        \ General MFA Enforcement\n    \xB7 MFA should be enforced on all internet-facing\
        \ systems, including email, VPNs, RDP, cloud services, and\nweb portals.\n\
        \    \xB7 All remote access, including access by third-party vendors and contractors,\
        \ should require MFA.\n\xB7 MFA Technology Selection\n    \xB7 MFA methods\
        \ should be selected based on security strength, phishing resistance, and\
        \ operational fit.\n    \xB7 Common options include:\n        \xB7 Hardware\
        \ TOTP (Time-based One-Time Password) tokens \u2014 secure, limited phishing\
        \ resistance\n        \xB7 Authenticator apps (software TOTP) \u2014 widely\
        \ used, moderate security\n        \xB7 Passkeys \u2014 passwordless, user-friendly,\
        \ cryptographically secure\n        \xB7 FIDO2 (platform or hardware-based\
        \ \u2013 Fast Identity Online 2) \u2014 strong cryptographic authentication\n\
        \        \xB7 Push-based apps \u2014 convenient, but may be vulnerable to\
        \ push fatigue\n        \xB7 SMS and email-based MFA should be avoided due\
        \ to security weaknesses.\n\xB7 Supporting Security Measures\n    \xB7 Strong\
        \ password policies should be enforced alongside MFA.\n    \xB7 Users should\
        \ be trained to log out of sessions explicitly.\n    \xB7 Anti-malware tools\
        \ and platforms should be kept up-to-date.\n    \xB7 Regular phishing awareness\
        \ training should be conducted.\n\xB7 OT-Specific MFA Considerations (see\
        \ also PR.AA-01.1)\n    \xB7 Shared Access to PLCs/HMIs\n    \xB7 If individual\
        \ accounts are not feasible, the principle of least privilege should be applied.\n\
        \    \xB7 A secure jump server or HMI front-end should be used to control\
        \ access, log activity, and add an authentication layer.\n\xB7 Secure Remote\
        \ Access to OT Systems\n    \xB7 Technical and procedural requirements for\
        \ remote access should be clearly defined.\n    \xB7 Secure protocols (e.g.\
        \ VPN, SSH, TLS) should be used.\n    \xB7 MFA should be enforced for all\
        \ remote OT access, especially for third-party suppliers.\n    \xB7 Just-In-Time\
        \ (JIT) access controls should be used to grant temporary, time-limited access.\n\
        \    \xB7 All remote access should be logged and monitored.\n\xB7 Integration\
        \ and Compatibility\n    \xB7 The MFA solution should be compatible with both\
        \ IT and OT systems.\n    \xB7 Integration should be tested in OT environments\
        \ to avoid disruptions.\n    \xB7 Where direct integration is not possible,\
        \ secure intermediary platforms (e.g. jump servers) should be used."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03
      ref_id: PR.AA-03.3
      description: The organisation shall define, document, and implement usage restrictions,
        connection requirements, and authorisation procedures for remote access to
        its critical systems. These controls shall ensure that only approved users
        can connect, using secure methods, with access limited to what is necessary
        for their role.
      annotation: "The goal of this control is to ensure that remote access to critical\
        \ systems is tightly controlled through defined usage restrictions, secure\
        \ connection methods, and formal authorisation procedures. This helps prevent\
        \ unauthorised access and limits exposure to cyber threats.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Define Usage Restrictions\n  \
        \  Identify which systems are critical (e.g. OT systems, production servers,\
        \ financial databases). Define who may access them remotely (e.g. specific\
        \ roles, third-party vendors). Limit access to approved timeframes and restrict\
        \ it to only the systems and functions necessary for the user\u2019s role.\n\
        \xB7 Set Secure Connection Requirements\n    Remote access should be established\
        \ using secure methods such as VPNs with strong encryption, TLS/SSH, or jump\
        \ servers for OT environments. All remote access should be protected by Multi-Factor\
        \ Authentication (MFA), in line with PR.AA-03.2. Devices used for remote access\
        \ should meet endpoint security requirements (e.g. antivirus, patching).\n\
        \xB7 Document and Approve Access\n    A remote access policy should define\
        \ request and approval procedures, roles, and technical requirements. A register\
        \ of remote users should be maintained, including access scope, approval dates,\
        \ and review timelines.\n\xB7 Monitor and Review Access\n    All remote sessions\
        \ should be logged, capturing user identity, time, duration, and systems accessed.\
        \ Logs should be reviewed regularly for anomalies. Remote access permissions\
        \ and configurations should be audited periodically.\n\xB7 Apply OT-Specific\
        \ Controls\n    For OT systems, access should be routed through secure front-end\
        \ interfaces or jump servers. If shared accounts are required (e.g. for PLCs\
        \ or HMIs), access should be logged, time-limited, protected by MFA at the\
        \ jump server level, and follow the principle of least privilege.\n\xB7 Align\
        \ with ENISA Guidance\n    These practices align with ENISA\u2019s NIS2 Technical\
        \ Implementation Guidance, which recommends secure remote access policies,\
        \ strong authentication, and continuous monitoring as part of cybersecurity\
        \ risk management for critical systems."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03
      ref_id: PR.AA-03.4
      description: "Remote access to the organisation\u2019s critical systems shall\
        \ be monitored and cryptographic mechanisms shall be implemented where determined\
        \ necessary."
      annotation: "The goal of this control is to ensure that remote access to critical\
        \ systems is not only restricted and approved (as defined in PR.AA-03.3),\
        \ but also actively monitored and protected using cryptographic mechanisms\
        \ to prevent unauthorised access and data compromise.\n\nTo achieve this goal,\
        \ the organisation should:\n\xB7 Monitor Remote Access Activities\n    All\
        \ remote access sessions should be logged, capturing user identity, time,\
        \ duration, and systems accessed. Monitoring tools should detect unusual or\
        \ unauthorised access patterns and alert security teams in real time. Logs\
        \ should be reviewed regularly and retained according to policy.\n\xB7 Apply\
        \ Cryptographic Protections\n    Remote connections should use strong encryption\
        \ protocols such as TLS (Transport Layer Security), SSH (Secure Shell), or\
        \ IPsec. Data transmitted during remote sessions should be encrypted in transit.\
        \ Where sensitive data is accessed, end-to-end encryption should be considered.\n\
        \xB7 Enforce Access Rules from PR.AA-03.3\n    Monitoring and encryption settings\
        \ should reflect the access restrictions defined in PR.AA-03.3. For example,\
        \ alerts should trigger on out-of-hours access or attempts to reach unauthorised\
        \ systems. All access should be verified against documented approvals.\n\xB7\
        \ Support Continuous Improvement\n    Monitoring data should be used to refine\
        \ access policies, identify enforcement gaps, and support incident response.\
        \ Cryptographic standards should be reviewed periodically to ensure alignment\
        \ with current best practices.\n\xB7 Ensure OT-Specific Feasibility\n    In\
        \ OT environments, monitoring and encryption should be implemented in a way\
        \ that respects system constraints and operational continuity. Jump servers\
        \ or secure gateways should be used to centralise control and logging.\n\xB7\
        \ Align with ENISA Guidance\n    These practices align with ENISA\u2019s NIS2\
        \ Technical Implementation Guidance, which recommends secure remote access,\
        \ encryption of communications, and continuous monitoring as part of effective\
        \ cybersecurity risk management for critical systems."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-03
      ref_id: PR.AA-03.5
      description: The security for connections with external systems shall be verified
        and framed by documented agreements.
      annotation: "The goal of this control is to ensure that all connections with\
        \ external systems are secured through verified security controls and governed\
        \ by documented agreements. This reduces the risk of unauthorised access,\
        \ data leakage, and supply chain compromise.\n\nTo achieve this goal, the\
        \ organisation should:\n\xB7 Control and Document All External Interactions\n\
        \    All interactions between internal systems and external parties (e.g.\
        \ vendors, partners, cloud services) should be identified, controlled, and\
        \ documented to ensure traceability and accountability.\n\xB7 Verify Security\
        \ Controls of External Parties\n    Before establishing any connection, the\
        \ external party\u2019s security posture should be verified through third-party\
        \ assessments, audits, certifications (e.g. CyFun\xAE), or technical documentation\
        \ such as M154. These documents should describe security architecture, access\
        \ controls, encryption, and monitoring.\n\xB7 Establish Documented Agreements\n\
        \    Formal agreements (e.g. contracts, SLAs, DPAs) should define security\
        \ requirements, roles and responsibilities, data exchange protocols, incident\
        \ response procedures, and termination conditions.\n\xB7 Specify Access Control\
        \ Requirements\n    Agreements should include technical restrictions such\
        \ as IP whitelisting, role-based access control, data handling rules, and\
        \ encryption requirements for data in transit and at rest.\n\xB7 Monitor and\
        \ Review External Connections\n    All external connections should be continuously\
        \ monitored for anomalies or policy violations. Agreements and technical documentation\
        \ (e.g. M154) should be reviewed periodically and updated as needed. Any changes\
        \ in the external system\u2019s security posture should trigger a reassessment.\n\
        \xB7 Ensure OT-Specific Considerations\n    In OT environments, external access\
        \ should be routed through secure gateways or jump servers. Shared access\
        \ (e.g. for vendor-managed PLCs) should be logged, time-limited, and protected\
        \ by strong authentication.\n\xB7 Align with ENISA Guidance\n    These practices\
        \ align with ENISA\u2019s Technical Implementation Guidance on Cybersecurity\
        \ Risk Management Measures, which recommends verifying third-party security,\
        \ formalising responsibilities through contracts, and continuously monitoring\
        \ external dependencies."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      ref_id: PR.AA-04
      description: Identity assertions are protected, conveyed, and verified
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-04
      ref_id: PR.AA-04.1
      description: Identity assertions are protected, conveyed, and verified
      annotation: "The goal of this control is to ensure that identity assertions\
        \ \u2014 claims about the identity of a user, device, or process \u2014 are\
        \ protected against tampering, securely transmitted, and reliably verified\
        \ before granting access to critical systems or data.\n\nDefinition: An identity\
        \ assertion is a digital statement used during authentication that confirms\
        \ the identity of a user, device, or process. It typically includes information\
        \ such as the identity provider, authentication method, and validity period,\
        \ and is used to grant access to systems or services.\n\nTo achieve this goal,\
        \ the organisation should:\n\xB7 Protect Identity Assertions\n    Identity\
        \ assertions should be protected from tampering, theft, or misuse. Strong\
        \ encryption (e.g. TLS 1.2 or higher) and digital signatures should be applied.\
        \ Identity providers should comply with the eIDAS Regulation (e.g. itsme\xAE\
        , SPID, FranceConnect). These practices align with ENISA\u2019s Digital Identity\
        \ and Trust Services guidance.\n\xB7 Convey Identity Assertions Securely\n\
        \    Identity data should be transmitted using secure protocols such as SAML\
        \ 2.0 or OpenID Connect. Token exposure in URLs should be avoided; HTTP headers\
        \ or POST methods should be used. For cross-border identity federation, eIDAS\
        \ nodes should be used to ensure secure interoperability between EU member\
        \ states.\n\xB7 Verify Identity Assertions\n    All assertions should be validated\
        \ before access is granted. This includes verifying digital signatures using\
        \ trusted certificate authorities listed in the EU Trusted List (EUTL), checking\
        \ token claims (issuer, audience, expiration), and validating against eIDAS\
        \ metadata. Qualified Trust Service Providers (QTSPs) should be used for issuing\
        \ and verifying identity credentials.\n\xB7 Ensure OT-Specific Feasibility\n\
        \    In OT environments, identity assertions should be integrated into secure\
        \ access gateways or jump servers. Where direct integration is not feasible,\
        \ identity verification should occur at the interface layer, with logging\
        \ and monitoring in place.\n\xB7 Align with ENISA Guidance\n    These practices\
        \ are supported by ENISA\u2019s NIS2 Technical Implementation Guidance and\
        \ its work on secure digital identity frameworks under the eIDAS and European\
        \ Digital Identity regulations."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      ref_id: PR.AA-05
      description: Access permissions, entitlements, and authorisations are defined
        in a policy, managed, enforced, and reviewed, and incorporate the principles
        of least privilege and separation of duties.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.1
      description: Access permissions, rights, and authorisations shall be defined,
        managed, enforced and reviewed.
      annotation: "The goal of this control is to ensure that access permissions,\
        \ rights, and authorisations are clearly defined, properly managed, consistently\
        \ enforced, and regularly reviewed to protect systems and data from unauthorised\
        \ access.\n\nTo achieve this goal, the following should be considered:\n\xB7\
        \ Access Definition and Management\n    \xB7 Access lists for systems (e.g.\
        \ files, servers, software, databases) should be created and reviewed regularly.\n\
        \    \xB7 Reviews should be supported by tools such as Active Directory analysis.\n\
        \xB7     Permission management procedures should be documented and updated\
        \ as needed.\n\xB7 Access Review and Revocation\n    \xB7 Logical and physical\
        \ access rights should be reviewed periodically and whenever roles change\
        \ or individuals leave the organisation.\n    \xB7 Unnecessary privileges\
        \ should be revoked immediately.\n\xB7 User Account Practices\n    \xB7 Each\
        \ user, including contractors, should have a separate account to ensure accountability.\n\
        \    \xB7 Where technically feasible, appropriate authentication measures\
        \ should be applied.\n    \xB7 Guest accounts should be restricted to minimum\
        \ required privileges (e.g. internet access only).\n    \xB7 Single Sign-On\
        \ (SSO) should be used where appropriate.\n\xB7 Authorisation Criteria\n \
        \   Authorisation decisions should consider characteristics such as geolocation,\
        \ time of access, and the security posture of the requesting device.\n\xB7\
        \ OT-Specific Considerations\n    \xB7 In environments where individual accounts\
        \ are not technically feasible \u2014 such as shared access to PLCs or HMIs,\
        \ access should be limited to essential functions only, and enforced through\
        \ secure methods like a jump server or HMI front-end that logs activity, restricts\
        \ access by role or time, and adds an extra authentication layer (e.g. badge\
        \ or PIN).\n    \xB7 Authentication methods should align with the capabilities\
        \ of OT systems.\n    \xB7 Access to OT systems should be logged and monitored\
        \ where possible."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.2
      description: It shall be determined who needs access to the organisation's business-critical
        information and technology and the means to gain access.
      annotation: "The goal of this control is to determine who requires access to\
        \ the organisation\u2019s business-critical information and technology, and\
        \ to define the secure means by which this access is granted.\n\nTo achieve\
        \ this goal, the following should be considered:\n\xB7 Access Determination\
        \ and Restriction\n    \xB7 Access rights should be limited to only those\
        \ individuals who need them to perform their roles.\n    \xB7 A zero trust\
        \ model should be considered for both IT and OT environments, requiring verification\
        \ before granting access.\n\xB7 Means of Access\n    \xB7 Access methods should\
        \ include secure mechanisms such as keys, passwords, codes, or administrative\
        \ privileges.\n    \xB7 These methods should be managed and monitored to prevent\
        \ misuse.\n\xB7 Cyber Health of Endpoints\n    \xB7 Devices such as laptops,\
        \ smartphones, and tablets should meet security standards before connecting\
        \ to the production network.\n    \xB7 Endpoint health should be verified\
        \ by checking for:\n        \xB7 Up-to-date antivirus software\n        \xB7\
        \ Absence of malware\n        \xB7 Installation of the latest security patches\n\
        \    \xB7 Only compliant devices should be allowed to access critical systems\
        \ and data.\n\xB7 OT-Specific Considerations\n    \xB7 In OT environments,\
        \ access to control systems should be limited to essential personnel.\n  \
        \  \xB7 Secure access methods (e.g. jump servers, role-based restrictions)\
        \ should be used where individual accounts are not feasible.\n\xB7 Reference\n\
        \    For practical tools and templates, refer to the Access Policy template\
        \ in the CyFun\xAE Toolbox on www.cyfun.eu"
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.3
      description: Access rights, privileges and authorisations shall be restricted
        to the systems and specific information needed to perform the tasks (the principle
        of Least Privilege).
      annotation: "The goal of this control is to ensure that access rights, privileges,\
        \ and authorisations are restricted to only the systems and specific information\
        \ needed to perform assigned tasks, following the principle of least privilege.\n\
        \nTo achieve this goal, the following should be considered:\n\xB7 Apply Least\
        \ Privilege\n    \xB7 Access rights should be limited to the minimum necessary\
        \ for users, systems, and services.\n    \xB7 Accounts should start with low\
        \ privileges, and be elevated only when justified.\n    \xB7 Just-in-time\
        \ access should be used to limit the duration of elevated privileges.\n\xB7\
        \ Define and Manage Permissions\n    \xB7 Access rights should be clearly\
        \ defined based on roles and responsibilities.\n    \xB7 An inventory of accounts\
        \ and their permissions should be maintained and kept up to date.\n    \xB7\
        \ Separate accounts should be used for contractors and third parties to ensure\
        \ traceability.\n\xB7 Enforce Access Controls\n    \xB7 Role-based or attribute-based\
        \ access control models should be implemented where feasible.\n    \xB7 Internet\
        \ access points and external connections should be limited to what is strictly\
        \ necessary.\n\xB7 Harden Systems\n    Systems should be hardened to support\
        \ access control by:\n    \xB7 Disabling unused ports and services\n    \xB7\
        \ Restricting Bluetooth where not needed\n    \xB7 Limiting legacy protocols\
        \ such as FTP unless securely configured\n\xB7 Review and Adapt Access\n \
        \   \xB7 Access rights should be reviewed regularly and adjusted based on\
        \ role changes, project completion, or security assessments.\n    \xB7 Access\
        \ should be revoked immediately when no longer needed.\n\xB7 OT-Specific Considerations\n\
        \    In OT environments, access control should still follow the principle\
        \ of least privilege. Where technical limitations exist, previously defined\
        \ OT access control measures (see PR.AA-01.1 and PR.AA-05.1) should be applied\
        \ to ensure secure and traceable access."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.4
      description: No-one shall have administrative privileges for routine day-to-day
        tasks.
      annotation: "The goal of this control is to prevent the use of administrative\
        \ privileges for routine, day-to-day tasks, thereby reducing the risk of misuse\
        \ or exploitation by attackers.\n\nTo ensure this goal is met, the organisation\
        \ should consider the following:\n\xB7 Account Separation and Privilege Management\n\
        \    \xB7 Administrative and general user accounts should be strictly separated.\n\
        \    \xB7 Dedicated administrator accounts should be used only for system\
        \ management and administrative tasks.\n    \xB7 User accounts should not\
        \ have administrative privileges.\n\xB7 Access Restrictions and Security Measures\n\
        \    \xB7 Unique local administrator passwords should be created for each\
        \ system.\n    \xB7 Unused accounts should be promptly disabled.\n    \xB7\
        \ Internet browsing from administrative accounts should be prohibited to reduce\
        \ exposure to web-based threats.\n\xB7 OT-Specific Considerations\n    \xB7\
        \ In OT environments, administrative access should be limited to essential\
        \ personnel and functions.\n    \xB7 Where shared access is necessary, secure\
        \ access methods (e.g. jump servers, session logging) should be used to enforce\
        \ accountability and reduce risk."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.5
      description: "Where technically, operationally, and economically feasible\u2014\
        without compromising system integrity, safety, or compliance\u2014automated\
        \ mechanisms shall be implemented to manage user accounts on critical ICT\
        \ and OT systems. Feasibility shall be determined based on system capabilities,\
        \ integration potential, risk assessment, and business impact."
      annotation: "The goal of this control is to ensure that user accounts on critical\
        \ ICT and OT systems are managed securely, efficiently, and consistently through\
        \ automated mechanisms \u2014 where technically, operationally, and economically\
        \ feasible \u2014 without compromising system integrity, safety, or compliance.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Assess Feasibility\
        \ of Automation\n    Feasibility should be based on system capabilities, integration\
        \ potential, risk assessment, and business impact.\n    \xB7 For ICT systems,\
        \ feasibility depends on the availability of automation tools, APIs, or integration\
        \ options, and the absence of major technical or financial barriers.\n   \
        \ \xB7 For OT systems, feasibility depends on system age, vendor limitations,\
        \ safety requirements, and the risk of disrupting critical operations.\n \
        \   \xB7 General feasibility should consider technical capability, operational\
        \ safety, cost-effectiveness, and compliance with security and regulatory\
        \ standards.\n\xB7 Automate Account Lifecycle Management\n    Automated mechanisms\
        \ should manage account creation, modification, and deletion based on predefined\
        \ rules. This ensures that only authorised users have access and that accounts\
        \ are promptly removed when no longer needed.\n\xB7 Disable Inactive or Unauthorised\
        \ Accounts\n    Accounts should be automatically disabled when users leave\
        \ the organisation or no longer require access. This reduces the risk of unauthorised\
        \ access to critical systems.\n\xB7 Monitor and Report Account Activity\n\
        \    Automated tools should continuously monitor account usage and generate\
        \ reports to detect unusual or unauthorised activity. Alerts should be triggered\
        \ for suspicious behaviour.\n\xB7 Send Notifications for Key Events\n    Automated\
        \ notifications should inform administrators of important events such as account\
        \ creation, modification, or deletion, enabling timely oversight.\n\xB7 Maintain\
        \ Audit Trails for Compliance\n    All account-related activities should be\
        \ logged automatically to support compliance with internal policies and external\
        \ regulations.\n\xB7 Ensure OT-Specific Feasibility\n    In OT environments,\
        \ automation should be implemented only where it does not compromise safety\
        \ or operational continuity. Where direct automation is not feasible, account\
        \ management should be handled through secure interface layers or jump servers.\n\
        \xB7 Align with ENISA Guidance\n    These practices are supported by ENISA\u2019\
        s NIS2 Technical Implementation Guidance and its work on secure access management\
        \ in critical infrastructure environments."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.6
      description: Separation of duties (SoD) shall be ensured in the management of
        access rights.
      annotation: "The goal of this control is to ensure that no single individual\
        \ has full control over critical systems or processes by enforcing Separation\
        \ of Duties (SoD). This should reduce the risk of errors, fraud, and misuse\
        \ of access rights.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Define Separation of Duties\n    Responsibilities should be divided so that\
        \ key tasks are performed by different individuals.\nSoD should include:\n\
        \    \xB7 Operational and system support roles should be assigned to different\
        \ individuals.\n    \xB7 System support tasks should require oversight or\
        \ dual control.\n    \xB7 A single person should not initiate and approve\
        \ the same transaction.\n    \xB7 Access control and audit functions should\
        \ be handled by separate roles.\n\xB7 Manage Access Rights Appropriately\n\
        \    \xB7 Role-Based Access Control (RBAC) should be used to assign permissions\
        \ based on job roles.\n    \xB7 The principle of least privilege should be\
        \ applied to limit access to what is strictly necessary.\n    \xB7 Access\
        \ rights should be reviewed regularly, especially for critical systems and\
        \ high-risk roles.\n    \xB7 Separate tools or accounts should be used for\
        \ administrative and audit functions where feasible.\n\xB7 Apply Controls\
        \ for System Administrators\n    \xB7 Administrative responsibilities should\
        \ be split to prevent full control by a single individual.\n    \xB7 Administrators\
        \ should use separate accounts for regular and privileged tasks.\n    \xB7\
        \ All administrative actions should be logged and reviewed by an independent\
        \ party.\n    \xB7 Administrators managing access should not be responsible\
        \ for auditing that access.\n\xB7 Ensure Feasibility in OT Environments\n\
        \    \xB7 In OT systems, SoD should be adapted to operational and safety constraints.\n\
        \    \xB7 Where full separation is not feasible, compensating controls such\
        \ as dual approval, logging, and external review should be implemented.\n\xB7\
        \ Align with ENISA Guidance\n    These practices align with ENISA\u2019s Security\
        \ Measures for Operators of Essential Services, which highlight the importance\
        \ of Separation of Duties (SoD) and Role-Based Access Control (RBAC) in reducing\
        \ access-related risks across ICT and OT environments."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.7
      description: Privileged users shall be managed and monitored.
      annotation: "The goal of this control is to reduce the risk of unauthorised\
        \ access, data breaches, and operational disruption by ensuring that privileged\
        \ users, who have elevated access to critical systems, are subject to strict\
        \ management and continuous oversight.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Monitor Privileged Activities\n    Activities of privileged\
        \ users should be logged and reviewed routinely or continuously, even if performed\
        \ by individuals not independent of the process.\n\xB7 Protect Sensitive Data\n\
        \    Monitoring should help prevent privileged users from exposing or misusing\
        \ sensitive information and system configurations.\n\xB7 Prevent Abuse of\
        \ Privileges\n    Privileged accounts should be managed to avoid unauthorised\
        \ changes, privilege escalation, or bypassing of security controls.\n\xB7\
        \ Detect Suspicious Behaviour\n    Behavioural anomalies and unauthorised\
        \ actions should be identified through automated logging and alerting mechanisms.\n\
        \xB7 Support Incident Response\n    Monitoring data should be used to investigate\
        \ and respond to security incidents involving privileged accounts.\n\xB7 Manage\
        \ Access Rights Proactively\n    Access rights should be clearly defined,\
        \ regularly reviewed, and adjusted based on role changes, operational needs,\
        \ or risk assessments.\n\xB7 Ensure OT-Specific Feasibility\n    In OT environments,\
        \ privileged access should be managed with consideration for system stability\
        \ and safety. Where full monitoring is not feasible, compensating controls\
        \ such as interface-level logging1 or external review should be implemented.\n\
        \xB7 Align with ENISA Guidance\n    These practices align with ENISA\u2019\
        s NIS2 Technical Implementation Guidance, which emphasises the importance\
        \ of privileged access control and monitoring in securing essential services\
        \ and critical infrastructure."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.8
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.8
      description: 'Account usage restrictions for specific time periods and locations
        shall be taken

        into account in the organisation''s security access policy and applied accordingly.'
      annotation: "The goal of this control is to reduce the risk of unauthorised\
        \ access by ensuring that account usage is restricted based on time, location,\
        \ device, and user context. These restrictions should be defined in the organisation\u2019\
        s security access policy and applied consistently across ICT and OT environments.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Apply Time-Based Restrictions\n\
        \    \xB7 Access to systems should be limited to defined working hours to\
        \ reduce exposure during off-hours.\n    \xB7 Usage durations for certain\
        \ accounts should be capped to prevent excessive or unattended sessions.\n\
        \xB7 Apply Location-Based Restrictions\n    \xB7 Geofencing should be used\
        \ to allow access only from trusted geographic locations.\n    \xB7 IP address\
        \ filtering should restrict access to known and approved network ranges.\n\
        \xB7 Apply Device-Based Restrictions\n    \xB7 Access should be allowed only\
        \ from managed devices that comply with the organisation\u2019s security policies.\n\
        \    \xB7 Unmanaged devices should be restricted or granted limited access\
        \ (e.g. read-only or no access to sensitive data).\n\xB7 Apply User-Based\
        \ Restrictions\n    \xB7 Role-Based Access Control (RBAC) should ensure users\
        \ only access systems and data relevant to their job.\n    \xB7 Conditional\
        \ access policies should require additional verification (e.g. Multi-Factor\
        \ Authentication) in high-risk scenarios.\n    \xB7 Continuous Adaptive Risk\
        \ and Trust Assessment (CARTA) should be considered to evaluate user and device\
        \ trust dynamically. This approach aligns with the Zero Trust principle, which\
        \ assumes no implicit trust for any user or device, even inside the network.\n\
        \xB7 Ensure OT-Specific Feasibility\n    In OT environments, restrictions\
        \ should be adapted to operational and safety requirements. Where technical\
        \ limitations exist, compensating controls such as physical access restrictions\
        \ or monitored jump servers should be implemented.\n\xB7 Align with ENISA\
        \ Guidance\n    These practices align with ENISA\u2019s NIS2 Technical Implementation\
        \ Guidance, which supports contextual access control as part of effective\
        \ cybersecurity risk management."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05.9
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-05
      ref_id: PR.AA-05.9
      description: Privileged users shall be managed, monitored and audited.
      annotation: "The goal of this control is to ensure that privileged user accounts,\
        \ those with elevated access to critical systems, are tightly controlled,\
        \ continuously monitored, and independently audited. This should reduce the\
        \ risk of misuse, ensure accountability, and protect critical Information\
        \ Technology (IT), Operational Technology (OT), and Internet of Things (IoT)\
        \ environments.\n\nTo achieve this goal, the organisation should:\n\xB7 Enforce\
        \ Strong Privileged Access Management\n    Privileged accounts should have\
        \ clearly defined roles, limited access scopes, and be subject to regular\
        \ access reviews.\n\xB7 Implement Continuous Monitoring\n    All privileged\
        \ user activities should be logged and monitored continuously, using automated\
        \ tools where possible, to support traceability and incident response.\n\xB7\
        \ Conduct Independent Audits\n    \xB7 Audits should be performed periodically\
        \ by individuals who are independent of the access management process.\n \
        \   \xB7 Audits should:\n        \xB7 Verify that privileged access is granted\
        \ in line with policy.\n        \xB7 Confirm that monitoring and logging mechanisms\
        \ function correctly.\n        \xB7 Identify misuse, policy violations, or\
        \ deviations.\n        \xB7 Produce documented outcomes such as audit reports\
        \ or corrective action plans.\n\xB7 Apply the Four-Eyes Principle\n    No\
        \ single individual should be able to grant, modify, or revoke privileged\
        \ access without oversight or approval from another authorised person.\n\xB7\
        \ Differentiate Between Monitoring and Auditing\n    \xB7 Daily compliance\
        \ monitoring should focus on operational issues (e.g. alerts, anomalies).\n\
        \    \xB7 Periodic audits should assess the overall effectiveness and integrity\
        \ of the privileged access management process.\n\xB7 Ensure OT-Specific Feasibility\n\
        \    In OT environments, privileged access controls should be adapted to operational\
        \ and safety constraints. Where full auditing is not feasible, compensating\
        \ controls such as interface-level logging or external review should be implemented.\n\
        \xB7 Align with ENISA Guidance\n    These practices should align with ENISA\u2019\
        s NIS2 Technical Implementation Guidance, which highlights the importance\
        \ of privileged access control, monitoring, and auditing in securing essential\
        \ services and critical infrastructure."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa
      ref_id: PR.AA-06
      description: Physical access to assets is managed, monitored, and enforced commensurate
        with risk.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06
      ref_id: PR.AA-06.1
      description: Physical access to all organisational assets, including critical
        zones, should be managed, monitored, and enforced based on risk.
      annotation: "The goal of this control is to ensure that physical access to all\
        \ organisational assets, especially in critical zones, is managed, monitored,\
        \ and enforced based on risk to prevent unauthorised entry and protect sensitive\
        \ systems.\n\nTo support this goal, the following actions should be taken:\n\
        \xB7 Access Control Measures\n    \xB7 Keys, badges, and alarm codes should\
        \ be strictly managed.\n    \xB7 Employee access credentials should be collected\
        \ immediately upon departure.\n    \xB7 Alarm codes should be changed regularly.\n\
        \    \xB7 External service providers (e.g. cleaners) should only receive access\
        \ when necessary, and it should be:\n    \xB7 Time-limited using technical\
        \ controls\n    \xB7 Logged electronically for traceability\n\xB7 Physical\
        \ Security Enhancements\n    \xB7 Critical zones should be protected with\
        \ physical controls such as:\n        \xB7 Surveillance cameras\n        \xB7\
        \ Security guards\n        \xB7 Locked doors and gates\n        \xB7 Alarm\
        \ systems\n    \xB7 These controls should be placed strategically to monitor\
        \ and restrict access.\n\xB7 Network Access Protection\n    Internal network\
        \ ports (e.g. Ethernet) should not be exposed in unsecured areas such as waiting\
        \ rooms, corridors, or reception zones.\n\xB7 OT-Specific Considerations\n\
        \    \xB7 Physical access to OT environments (e.g. control rooms, cabinets,\
        \ field devices) should be limited to authorised personnel only.\n    \xB7\
        \ Access should be logged and monitored, and physical barriers should be used\
        \ where feasible.\n\xB7 Reference\n    For practical tools and templates,\
        \ refer to the Access Policy in the CyFun\xAE Toolbox on www.cyfun.eu."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06
      ref_id: PR.AA-06.2
      description: Physical access controls should include specific procedures for
        emergency situations, ensuring continued protection of critical and non-critical
        assets during such events.
      annotation: "The goal of this control is to ensure that physical access controls\
        \ remain effective and adaptable during emergency situations. This includes\
        \ maintaining security over critical and non-critical assets while enabling\
        \ safe, authorised, and traceable access for emergency response, recovery,\
        \ or containment actions \u2014 especially in environments where physical\
        \ and operational safety are tightly linked, such as Operational Technology\
        \ (OT) and Internet of Things (IoT) systems.\n\nTo achieve this goal, the\
        \ organisation should:\n\xB7 Define Emergency Scenarios\n    Emergency procedures\
        \ should cover a range of events, including:\n    \xB7 Environmental and safety\
        \ incidents (e.g. fire, flood, medical emergencies, evacuations)\n    \xB7\
        \ Infrastructure failures (e.g. power outages, system malfunctions)\n    \xB7\
        \ Security incidents (e.g. intrusions, access control failures)\n    \xB7\
        \ Cybersecurity events (e.g. ransomware, data breaches, insider threats)\n\
        \xB7 Maintain Emergency Access Procedures\n    Emergency access should be:\n\
        \    \xB7 Logged: Record who accessed what, when, and why.\n    \xB7 Monitored:\
        \ Use surveillance or access control systems to track activity.\n    \xB7\
        \ Reviewed: Conduct post-event reviews to verify appropriate use and detect\
        \ misuse.\n\xB7 Support Emergency Readiness with Physical Controls\n    \xB7\
        \ Up-to-date lists of authorised individuals with emergency access rights\
        \ should be maintained.\n    \xB7 Identity credentials (e.g. access badges)\
        \ should be used and security zones defined.\n    \xB7 Escort requirements\
        \ should be applied for visitors or temporary personnel.\n    \xB7 Physical\
        \ barriers should be implemented such as fences, locks, turnstiles, and staffed\
        \ checkpoints.\n    \xB7 Surveillance systems should be used to monitor entry\
        \ and exit points.\n\xB7 Apply Additional Safeguards\n    \xB7 Badge systems\
        \ with differentiated access levels for various zones should be considered.\n\
        \    \xB7 Physical access to servers and network components should be restricted\
        \ to authorised personnel only.\n    \xB7 All access to critical infrastructure\
        \ should be logged and reviewed regularly.\n    \xB7 Maintain and review \u2014\
        \ Visitor access records should be maintained and reviewed. Corrective action\
        \ should be taken when necessary.\n\xB7 Ensure OT-Specific Feasibility\n \
        \   In OT environments, physical access procedures should be adapted to avoid\
        \ disrupting safety or operational continuity. Emergency access should be\
        \ designed to support both rapid response and asset protection.\n\xB7 Align\
        \ with ENISA Guidance\n    These practices align with ENISA\u2019s NIS2 Technical\
        \ Implementation Guidance, which highlights the importance of physical and\
        \ logical access controls in maintaining resilience during emergencies."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06
      ref_id: PR.AA-06.3
      description: Critical zones should have additional physical access controls
        beyond those applied to general facilities.
      annotation: "The goal of this control is to reduce the risk of unauthorised\
        \ physical access to areas essential for operational continuity, data integrity,\
        \ and personnel and equipment safety by applying stricter access measures\
        \ than those used in general facility areas.\n\nTo achieve this goal, the\
        \ following actions should be taken:\n\xB7 Critical zones should be identified\
        \ during asset classification. These typically include:\n    \xB7 Production\
        \ and Operational Technology (OT) environments\n    \xB7 Server rooms and\
        \ data centres\n    \xB7 Finance and Human Resources offices\n    \xB7 Control\
        \ rooms\n    \xB7 Locations storing sensitive or classified information\n\xB7\
        \ The following enhanced physical access controls should be considered:\n\
        \    \xB7 Dual-factor authentication (e.g. badge + biometrics)\n    \xB7 Continuous\
        \ surveillance (e.g. CCTV, motion sensors)\n    \xB7 Access logging with regular\
        \ review\n    \xB7 On-site or patrolling security personnel\n    \xB7 Alarm\
        \ systems with real-time alerts\n    \xB7 Visitor management procedures:\n\
        \    \xB7 Pre-approval and escorting\n    \xB7 Time-limited access\n    \xB7\
        \ Visitor logs\n\xB7 Ensure consistency with broader physical access policies,\
        \ including:\n    \xB7 PR.AA-06.1 \u2013 Risk-based access control\n    \xB7\
        \ PR.AA-06.2 \u2013 Emergency access procedures\n    \xB7 PR.AA-06.4 \u2013\
        \ Physical protection of assets\n\xB7 Adapt controls to the criticality of\
        \ each zone and integrate them into the overall physical security strategy."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.aa-06
      ref_id: PR.AA-06.4
      description: Assets located within critical zones should be physically protected
        against unauthorised access, damage, or interference.
      annotation: "The goal of this control is to safeguard essential assets located\
        \ in critical zones from unauthorised access, damage, or interference, whether\
        \ intentional or accidental, by applying tailored physical protection measures.\n\
        \nTo achieve this goal, the following measures should be considered:\n\xB7\
        \ Assets within critical zones should be physically protected based on their\
        \ criticality and risk profile. These assets may include:\n    \xB7 Servers\
        \ and control systems\n    \xB7 Power infrastructure and cabling\n    \xB7\
        \ Sensitive data repositories\n    \xB7 Operational Technology (OT) components\n\
        \xB7 Protection measures should include:\n    \xB7 Physical barriers and containment:\n\
        \        \xB7 Locked enclosures, secure cabinets, or cages for sensitive equipment\n\
        \        \xB7 Tamper-evident seals to detect unauthorised access\n       \
        \ \xB7 Environmental safeguards (e.g. fire suppression, temperature control)\n\
        \    \xB7 Infrastructure protection:\n        \xB7 Securing power and network\
        \ cabling, access interfaces, and equipment\n        \xB7 Redundant and physically\
        \ separated power systems for critical operations\n    \xB7 Access control\
        \ and supervision:\n        \xB7 Escorting guests, vendors, and third parties\
        \ at all times\n        \xB7 Maintaining and regularly reviewing access logs\n\
        \xB7 Controls should be aligned with related requirements, including:\n  \
        \  \xB7 PR.AA-06.1 \u2013 Risk-based access control\n    \xB7 PR.AA-06.2 \u2013\
        \ Emergency access procedures\n    \xB7 PR.AA-06.3 \u2013 Enhanced access\
        \ controls for critical zones\n\xB7 Protection should be proactive, initiated\
        \ during asset classification and facility design, and integrated into the\
        \ broader physical security strategy."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr
      ref_id: PR.AT
      name: Awareness and Training
      description: The organisation's personnel are provided with cybersecurity awareness
        and training so that they can perform their cybersecurity-related tasks.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at
      ref_id: PR.AT-01
      description: Personnel are provided with awareness and training so that they
        possess the knowledge and skills to perform general tasks with cybersecurity
        risks in mind.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01
      ref_id: PR.AT-01.1
      description: The organisation shall establish and maintain a cybersecurity awareness
        and training programme to ensure that all personnel understand how to perform
        their tasks securely and responsibly.
      annotation: "The goal of control PR.AT-01.1 is to ensure everyone in the organisation\
        \ understands how to work securely by providing regular, clear, and practical\
        \ cybersecurity training that reduces human risk and supports safe behaviour\
        \ in both IT and OT environments.\n\nTo achieve this goal, the following should\
        \ be considered:\n\xB7 Basic Training Should Be Provided to All\n    Cybersecurity\
        \ awareness training should be given to all employees, contractors, partners,\
        \ and suppliers, including those in Operational Technology (OT) environments.\n\
        \xB7 Training Should Cover Common Threats\n    Topics such as phishing, weak\
        \ passwords, social engineering, and OT-specific risks (e.g. USB misuse, remote\
        \ access threats) should be included.\n\xB7 Training Should Start Early and\
        \ Be Repeated Regularly\n    Training should be provided during onboarding\
        \ and refreshed at least annually. Ongoing updates and reminders should reinforce\
        \ key messages.\n\xB7 Multiple Channels Should Be Used\n    Awareness should\
        \ be raised through structured sessions, campaigns, posters, newsletters,\
        \ and interactive tools.\n\xB7 Consequences of Non-Compliance Should Be Explained\n\
        \    The impact of violating cybersecurity policies should be clearly communicated,\
        \ both for individuals and the organisation.\n\xB7 Training Should Align with\
        \ Policies and Best Practices\n    Content should reflect internal cybersecurity\
        \ policies, expected behaviours, and protection measures. Recognised frameworks\
        \ like ENISA\u2019s AR-in-a-Box should guide programme design.\n\xB7 OT-Specific\
        \ Risks Should Be Addressed\n    Training should be tailored to include the\
        \ unique responsibilities and risks faced by personnel working with industrial\
        \ control systems and other OT assets.\n\xB7 Content Should Be Kept Up to\
        \ Date\n    Training materials should be regularly reviewed and updated to\
        \ reflect new threats and lessons learned from incidents."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01
      ref_id: PR.AT-01.2
      description: The organisation shall include insider threat awareness and reporting
        in its cybersecurity training to help personnel recognise and respond to potential
        internal risks.
      annotation: "The goal of this control is to ensure that all personnel are trained\
        \ to recognise and report potential insider threats, thereby reducing the\
        \ risk of internal cybersecurity incidents.\nThis control builds on the general\
        \ awareness from PR.AT-01.1 by introducing specific threat scenarios and response\
        \ actions.\n\nThe implementation should consider:\n\xB7 Training should include\
        \ how to recognise behavioural signs of insider threats, such as unusual access\
        \ patterns, data hoarding, or sudden changes in behaviour.\n\xB7 The organisation\
        \ should define insider threats clearly (e.g. malicious, negligent, or compromised\
        \ insiders, including employees and contractors).\n\xB7 Staff should be trained\
        \ on how and where to report suspicious activity, and why timely reporting\
        \ matters.\n\xB7 Real-life case studies or simulations should be used to show\
        \ the impact of insider threats and reinforce learning.\n\xB7 Insider threat\
        \ awareness should be part of regular security training and onboarding for\
        \ all staff.\n\xB7 Specialised training should be provided to staff with access\
        \ to sensitive data or systems, focusing on their specific responsibilities.\n\
        \xB7 Cross-functional teams-training should be developed with both IT security\
        \ and OT operational expertise (Cross-Training).\n\xB7 Annual refresher training\
        \ should be used to reinforce key messages and introduce updates.\n\xB7 The\
        \ organisation should promote a culture of security where employees feel safe\
        \ to report concerns without fear of retaliation."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01
      ref_id: PR.AT-01.3
      description: Personnel shall receive training to understand their specific roles,
        responsibilities, and priorities during a cybersecurity or information security
        incident, including the steps they need to follow to respond effectively.
      annotation: "The goal of this control is to ensure that all personnel understand\
        \ their specific roles, responsibilities, and priorities during a cybersecurity\
        \ or information security incident, enabling them to respond effectively and\
        \ in coordination with the organisation\u2019s incident response and contingency\
        \ plans. This control builds on the threat-specific awareness from PR.AT-01.2\
        \ by introducing role-based training and incident response readiness.\nThe\
        \ implementation should consider the following:\n\xB7 Training should be tailored\
        \ to different roles (e.g., IT, HR, executives) so that each group understands\
        \ its specific responsibilities during an incident.\n\xB7 Personnel should\
        \ be familiar with their objectives, recovery priorities, and the correct\
        \ order of actions to take during an incident.\n\xB7 Tabletop exercises or\
        \ simulated drills should be used to practice incident response in a realistic\
        \ but controlled environment.\n\xB7 Clear documentation should be provided\
        \ outlining each role\u2019s tasks and responsibilities during an incident.\n\
        \xB7 Training should explain how incident response connects to contingency\
        \ planning, ensuring that staff understand when and how to activate contingency\
        \ measures (see also ID.IM-04.1).\n\xB7 Regular refresher sessions should\
        \ be held to keep knowledge up to date and reinforce readiness."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-01
      ref_id: PR.AT-01.4
      description: The organisation shall evaluate whether its cybersecurity awareness
        training is effective in improving knowledge, behaviour, and readiness across
        the organisation.
      annotation: "The goal of this control is to ensure that cybersecurity awareness\
        \ training leads to measurable improvements in personnel knowledge, secure\
        \ behaviour, and readiness to respond to cyber threats across all levels of\
        \ the organisation. This control builds on the threat-specific awareness from\
        \ PR.AT-01.2 and the role-based training\nfrom PR.AT-01.3 by introducing a\
        \ structured approach to measure the impact of awareness efforts.\n\nThe implementation\
        \ should consider the following:\n\xB7 The organisation should assess whether\
        \ awareness training is accessible to all relevant personnel and whether it\
        \ effectively influences their cybersecurity behaviour, awareness, and attitudes.\n\
        \xB7 If the organisation lacks experience in evaluation, it should consider\
        \ using existing evaluated frameworks or tools, such as ENISA\u2019s AR-in-a-Box,\
        \ which includes guidance on setting goals, selecting KPIs, and measuring\
        \ impact.\n\xB7 If developing an evaluation method internally, the organisation\
        \ should look into good practices and evidence-based approaches for evaluating\
        \ awareness programmes.\n\xB7 Evaluation methods should include a mix of:\n\
        \    \xB7 Pre- and post-training assessments or quizzes.\n    \xB7 Simulated\
        \ phishing or social engineering tests.\n    \xB7 Surveys to measure changes\
        \ in awareness, confidence, and behaviour.\n    \xB7 Feedback from participants\
        \ and trainers.\n\xB7 The organisation should document lessons learned and\
        \ use the results to improve future training efforts."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at
      ref_id: PR.AT-02
      description: Individuals in specialised roles are provided with awareness and
        training so that they possess the knowledge and skills to perform relevant
        tasks with cybersecurity risks in mind.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02
      ref_id: PR.AT-02.1
      description: Members of management bodies shall be able to demonstrate that
        they have completed training that gives them a solid understanding of information
        and cybersecurity and risk management so that they can assess information
        and cyber security risks and their consequences and propose the necessary
        risk mitigation, considering their roles, responsibilities and authorities.
      annotation: "The goal of this control is to ensure that members of management\
        \ bodies are equipped to make informed decisions on cybersecurity risks and\
        \ mitigation strategies by developing a foundational understanding of information\
        \ security, cyber threats, and risk management principles relevant to their\
        \ leadership roles.\n\nTo achieve this goal, the following practices should\
        \ be considered:\n\xB7 Training should provide management with the ability\
        \ to assess cybersecurity risks, understand their potential impact, and propose\
        \ appropriate mitigation measures aligned with their responsibilities and\
        \ authority.\n\xB7 Training content should consider:\n    \xB7 Core concepts\
        \ of information and cybersecurity\n    \xB7 Risk identification, assessment,\
        \ and mitigation\n    \xB7 Strategic decision-making in the context of cyber\
        \ threats\n    \xB7 Recognition of potential security gaps and governance\
        \ responsibilities\n\xB7 Training should be tailored to leadership roles,\
        \ using guidance from the European Union Agency for Cybersecurity (ENISA)\
        \ on role profiles, including titles, missions, tasks, skills, and competencies\
        \ (Ref. European Cyber\xAD security Skills Framework Role Profiles).\n\xB7\
        \ Annual refresher sessions should be considered to reinforce existing practices\
        \ and introduce new developments in cybersecurity and risk management."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02
      ref_id: PR.AT-02.2
      description: Individuals in specialised roles shall be provided with awareness
        and training before privileges are granted, so that they possess the knowledge
        and skills to perform relevant tasks with cybersecurity risks in mind.
      annotation: "The goal of this control is to ensure that individuals in specialised\
        \ roles receive cybersecurity awareness and training before privileged access\
        \ is granted, enabling them to perform their tasks with a strong understanding\
        \ of cybersecurity risks.\n\nTo achieve this goal, the organisation should:\n\
        \xB7 The specialised roles within the organisation that require additional\
        \ cybersecurity training (e.g. physical and cybersecurity personnel, finance\
        \ personnel, people in management roles, and anyone with access to business-\xAD\
        \ critical data) should be formally identified.\n\xB7 Role-based cybersecurity\
        \ awareness and training should be provided to all those in specialised roles,\
        \ including contractors, partners, suppliers, and other third parties.\n\xB7\
        \ It should be ensured that the training is delivered before access is granted,\
        \ and that it is tailored to the specific risks and responsibilities of each\
        \ role.\n\xB7 Individuals should be periodically assessed and tested on their\
        \ understanding of cybersecurity practices through tests, simulations, or\
        \ practical evaluations relevant to their role.\n\xB7 Consider annual refreshers\
        \ to reinforce existing practices and introduce new practices.\n\xB7 Both\
        \ Information Technology (IT) and Operational Technology (OT) contexts should\
        \ be included, particularly for roles that interact with industrial systems\
        \ or critical infrastructure."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.at-02
      ref_id: PR.AT-02.3
      description: Privileged users shall be qualified before privileges are granted,
        and these users shall be able to demonstrate the understanding of their roles,
        responsibilities, and authorities.
      annotation: "The goal of this control is to ensure that individuals granted\
        \ privileged access, whether in IT or OT environments, are demonstrably competent\
        \ and fully aware of the cybersecurity responsibilities, risks, and authority\
        \ boundaries tied to their role. This reduces the likelihood of accidental\
        \ misuse or exploitation of elevated privileges, especially in critical systems\
        \ where operational continuity and safety are at stake.\n\nTo ensure this\
        \ goal is met, the organisation should consider the following:\n\xB7 Privileged\
        \ users should be trained in various aspects to ensure that they use their\
        \ elevated access rights in a safe and responsible manner. The following training\
        \ topics could be considered:\n    \xB7 Security awareness: It is crucial\
        \ that privileged users are aware of the security risks associated with their\
        \ elevated access rights. This includes knowledge about phishing, malware,\
        \ and other cyber threats.\n    \xB7 Access management: Users should understand\
        \ how to properly manage their access rights, including using strong passwords,\
        \ multi-factor authentication, and restricting access only to what is necessary\
        \ for their role.\n    \xB7 Compliance and regulation: It is important that\
        \ privileged users are aware of relevant laws and regulations, such as GDPR,\
        \ NIS2, DORA\u2026, and how they affect their work.\n    \xB7 Incident response:\
        \ Training on how to respond to security incidents is essential. This includes\
        \ recognising suspicious activity and knowing how and to whom to report it.\n\
        \    \xB7 Data management best practices: Users should be trained on how to\
        \ store, process and transfer sensitive data securely.\n    \xB7 Ethics and\
        \ responsibility: It is important that privileged users are aware of their\
        \ ethical responsibilities and the possible consequences of misusing their\
        \ access rights.\n\xB7 Privileged users should be periodically assessed and\
        \ tested on their understanding of cybersecurity practices for their specialised\
        \ roles.\n\xB7 Consider annual refreshers to reinforce existing practices\
        \ and introduce new practices."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr
      ref_id: PR.DS
      name: Data Security
      description: Data are managed consistent with the organisation's risk strategy
        to protect the confidentiality, integrity, and availability of information.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds
      ref_id: PR.DS-01
      description: The confidentiality, integrity, and availability of data-at-rest
        are protected.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.1
      description: The organisation shall implement software, firmware, and information
        integrity checks to detect unauthorised changes to its critical system components
        during storage, transport, start-up and when determined necessary.
      annotation: "The goal of this control is to ensure the integrity and trustworthiness\
        \ of critical system components, such as software, firmware, and configuration\
        \ data, by detecting unauthorised modifications that could compromise operational\
        \ safety, reliability, or security across all lifecycle stages, including\
        \ storage, transport, and start-up.\n\nTo effectively protect the integrity\
        \ of data-at-rest, the organisation should implement a layered set of controls\
        \ designed to detect and prevent unauthorised changes to stored data, software,\
        \ and system components.\n\nThe following practices should be considered:\n\
        \xB7 Apply Cryptographic Integrity Mechanisms\n    \xB7 Use cryptographic\
        \ hashes (e.g., SHA-256), digital signatures, or other cryptographic mechanisms\
        \ (e.g. message authentication codes (MACs)) to verify the integrity of stored\
        \ data and critical files.\n\xB7     Integrity values should be generated\
        \ at the time of storage and verified before access or execution.\n\xB7 Implement\
        \ Automated Integrity Monitoring\n    \xB7 Deploy file integrity monitoring\
        \ (FIM) tools to continuously track changes to critical system files, configurations,\
        \ and applications.\n    \xB7 Alerts should be generated for any unauthorised\
        \ or unexpected modifications, and logs should be retained for audit and investigation.\n\
        \xB7 Validate Software and Firmware Integrity\n    \xB7 Ensure that software\
        \ and firmware stored on systems are validated using signature verification\
        \ or secure boot mechanisms before execution.\n    \xB7 Integrity validation\
        \ should be part of the system start-up process and enforced through technical\
        \ controls.\n\xB7 Enforce Change Control and Access Restrictions\n    \xB7\
        \ Limit write access to critical data and system components through role-based\
        \ access controls (RBAC) and least privilege principles.\n    \xB7 All changes\
        \ to data-at-rest should be subject to formal change management procedures\
        \ and logged for traceability.\n\xB7 Protect Integrity of Backups\n    \xB7\
        \ Backups should include integrity verification mechanisms (e.g. checksums\
        \ or digital signatures) to ensure they have not been tampered with.\n   \
        \ \xB7 Regular test restorations should be performed to confirm the integrity\
        \ and usability of backup data."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.2
      description: The organisation shall implement automated tools where feasible
        to provide notification upon discovering discrepancies during integrity verification.
      annotation: "The goal of this control is to ensure that discrepancies in system\
        \ or data integrity are detected and reported automatically, enabling timely\
        \ response and reducing the risk of undetected tampering, especially in environments\
        \ where operational continuity and safety are critical.\n\nTo achieve this\
        \ goal, the organisation should:\n\xB7 Implement automated tools where feasible\
        \ to continuously verify the integrity of critical data and systems.\n\xB7\
        \ Ensure these tools promptly report integrity violations when discrepancies\
        \ are detected.\n\xB7 Configure alerts to notify relevant personnel, such\
        \ as system administrators, business owners, and information security officers,\
        \ to enable swift investigation and response.\n\xB7 Use centrally managed\
        \ integrity verification solutions to streamline monitoring and reporting\
        \ across both IT (Information Technology) and OT (Operational Technology)\
        \ environments.\n\xB7 Follow guidance from ENISA, such as the NIS2 Technical\
        \ Implementation Guidance (ENISA, 2025), which outlines best practices for\
        \ automated integrity monitoring and incident response."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.3
      description: The organisation shall define and implement automated responses
        to detected integrity violations, using predefined safeguards that are proportionate
        to the severity and impact of the violation.
      annotation: "The goal of this control is to minimise the impact of integrity\
        \ violations by enabling timely, proportionate, and automated responses that\
        \ help contain threats, preserve system stability, and support forensic analysis,\
        \ especially in environments where manual intervention may be delayed or impractical.\n\
        \nTo achieve this goal, the following guidance should be considered:\n\xB7\
        \ Severity levels and response actions should be defined, with integrity violations\
        \ being categorised (e.g. low, medium, high impact) and linked to appropriate\
        \ automated safeguards.\n\xB7 Alerts and notifications should be triggered\
        \ automatically when integrity violations are detected, and integrated with\
        \ Security Orchestration, Automation, and Response (SOAR) platforms to streamline\
        \ incident handling.\n\xB7 Affected components should be quarantined or isolated,\
        \ such as compromised files, applications, or systems, to prevent further\
        \ damage.\n\xB7 All events should be logged and auditable, including detected\
        \ violations and automated actions, to support forensic investigations and\
        \ compliance reporting.\n\xB7 Lightweight automation should be used where\
        \ possible, such as:\n    \xB7 Blocking specific processes or users\n    \xB7\
        \ Reverting to a known-good configuration\n    \xB7 Temporarily disabling\
        \ affected services\n\xB7 Response mechanisms should be tested and tuned regularly\
        \ in controlled environments to ensure effectiveness and avoid unnecessary\
        \ disruption.\n\xB7 The European Union Agency for Cybersecurity (ENISA) guidance\
        \ in the \u201CImplementation Guidance on Security Measures\u201D (For Public\
        \ Consultation, Document No. ENISA/2024/IGSM) should be consulted."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.4
      description: The organisation shall define and enforce clear policies and practical
        safeguards to manage and restrict the use of portable storage media, in order
        to reduce the risk of data leakage, unauthorised access, and malware introduction.
      annotation: "The goal of this control is to reduce the risk of data leakage,\
        \ unauthorised access, and malware introduction by defining and enforcing\
        \ clear policies and safeguards for the use of portable storage media.\n\n\
        To achieve this goal, the organisation should:\n\xB7 Define and Communicate\
        \ Policy\n    \xB7 A documented policy on acceptable use of portable storage\
        \ devices (e.g. USB drives, SD cards, external hard disks) should be established.\n\
        \    \xB7 The policy should be communicated during onboarding and reinforced\
        \ through regular security awareness training.\n\xB7 Control Device Usage\n\
        \    \xB7 Only organisation-approved portable storage devices should be permitted.\n\
        \    \xB7 An inventory of approved devices should be maintained and linked\
        \ to specific users or departments.\n\xB7 Apply Practical Safeguards\n   \
        \ \xB7 Access Control: Devices should require user authentication (e.g. password\
        \ protection).\n    \xB7 Encryption: Data on portable devices should be encrypted\
        \ using hardware-encrypted drives or software tools such as BitLocker To Go\
        \ or VeraCrypt.\n    \xB7 Read-Only Mode: Devices used for distribution (e.g.\
        \ software updates) should be configured as read-only.\n    \xB7 Malware Scanning:\
        \ Devices should be scanned for malware before and after use.\n    \xB7 Physical\
        \ Security: Devices should be stored securely (e.g. in locked drawers or cabinets)\
        \ when not in use.\n\xB7 Monitor and Log Usage\n    \xB7 On managed systems,\
        \ USB device connections and file transfers should be logged using endpoint\
        \ management tools.\n    \xB7 Logs should be reviewed periodically to detect\
        \ unauthorised use or anomalies.\n\xB7 Examples\n    \xB7 A field technician\
        \ should use a company-issued, encrypted USB drive to collect data from remote\
        \ sensors. The drive should be scanned before and after use, and data should\
        \ be uploaded to a secure server upon return.\n    \xB7 A marketing team should\
        \ use a read-only USB stick to distribute promotional materials at a trade\
        \ show, thereby preventing any data from being copied back onto the device."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.5
      description: The organisation shall only allow the use of removable media when
        absolutely necessary, and shall put technical measures in place to block automatic
        execution of files from these devices.
      annotation: "The goal of this control is to minimise the attack surface in operational\
        \ and IT environments by strictly limiting the use of removable media and\
        \ preventing automatic execution of potentially harmful files.\n\nTo reduce\
        \ the risk of malware infections and data leaks from removable media (e.g.\
        \ USB sticks, external drives), the organisation should:\n\xB7 Allow Use Only\
        \ When Necessary\n    \xB7 The organisation should state in its policy that\
        \ removable media should only be used when no safer alternative is available\
        \ (e.g., secure file transfer).\n    \xB7 Technical tools should be used to\
        \ limit access to USB ports or require approval before use.\n\xB7 Disable\
        \ Autorun and Auto-Execution\n    \xB7 All systems should be configured to\
        \ disable autorun and autoplay features so that files on removable media do\
        \ not run automatically.\n    \xB7 This should help prevent malware from executing\
        \ without user action.\n\xB7 Use Security Tools to Control Access\n    \xB7\
        \ The organisation should use endpoint protection tools to:\n        \xB7\
        \ Block or limit USB access.\n        \xB7 Allow only approved devices.\n\
        \        \xB7 Require administrator approval for new devices.\n\xB7 Monitor\
        \ and Review Usage\n    \xB7 The organisation should monitor removable media\
        \ use by logging device connections through endpoint protection tools or operating\
        \ system logs. In OT environments, manual logging or controlled access procedures\
        \ should be used. Logs should be reviewed regularly to detect unauthorised\
        \ activity.\n\xB7 Example: A finance team should use encrypted, company-approved\
        \ USB drives to transfer sensitive reports. These drives should be scanned\
        \ before use, autorun should be disabled on all systems, and access should\
        \ be logged and reviewed.\n\nClarification of the difference with PR.DS-01.4\n\
        \xB7 PR.DS-01.4 focuses on setting rules and procedures for how removable\
        \ media should be used (e.g., who can use them, encryption, physical protection).\n\
        \xB7 PR.DS-01.5 focuses on the technical enforcement of those rules \u2014\
        \ how systems should be configured to reduce risk."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.6
      description: The organisation shall protect the confidentiality of its critical
        assets while at rest.
      annotation: "The goal of this control is to ensure that sensitive operational\
        \ and business data stored on systems, servers, or devices remains protected\
        \ from unauthorised access, even if physical or logical security is compromised.\n\
        \nIn OT environments, where legacy systems and shared infrastructure are common,\
        \ protecting data-at-rest is critical to prevent exposure of configuration\
        \ files, process data, or credentials that could be exploited to disrupt operations\
        \ or gain lateral access.\nThis control builds further on PR.DS-01.1.\n\n\
        To enable the protection of the organisation' s critical assets at-rest, the\
        \ following techniques should be considered:\n\xB7 Encryption: Encrypt data-at-rest,\
        \ on hard drives, on external media, in stored files, in configuration files\
        \ and stored in the cloud, using strong encryption algorithms to prevent unauthorised\
        \ access and protect the data against tampering.\n\xB7 Access Controls: Implement\
        \ strict access controls to ensure only authorised personnel can access sensitive\
        \ information.\n\xB7 Regular Audits: Conduct regular security audits to identify\
        \ and address vulnerabilities.\n\xB7 Data Masking: Use data masking techniques\
        \ to obscure sensitive information in non-production environments (For example,\
        \ GDPR-sensitive data from the production environment may not be copied to\
        \ a test environment without randomisation to prevent unauthorised access\
        \ to data)."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01.9
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-01
      ref_id: PR.DS-01.9
      description: Enterprise assets shall be disposed of safely.
      annotation: "The goal of this control is to ensure that all enterprise assets\
        \ are disposed of in a secure and controlled manner, to prevent unauthorised\
        \ access to sensitive business, personal, or operational data.\n\nTo support\
        \ this goal, the organisation should consider to:\n\xB7 Sanitise Data Before\
        \ Disposal\n    Sensitive data should be securely removed (\u201Cwiped\u201D\
        ) from all assets, such as computers, servers, hard drives, USB drives, mobile\
        \ devices, and paper documents, before retirement, reassignment, repair, or\
        \ replacement.\n\xB7 Use Appropriate Destruction Methods\n    Suitable methods\
        \ should be available for destroying paper records, digital storage media,\
        \ and other physical data carriers.\n\xB7 Enable Remote Wiping for Mobile\
        \ Devices\n    Remote wiping capabilities should be enabled on laptops, tablets,\
        \ phones, and other mobile devices to protect data if lost or stolen.\n\xB7\
        \ Manage Expired Domain Names Carefully\n    Expired domains should be protected,\
        \ as they are often targeted by cyber-criminals. The following practices should\
        \ be considered:\n    \xB7 Enable auto-renewal or renew domains for at least\
        \ ten years.\n    \xB7 Communicate domain changes clearly and manage transitions\
        \ internally.\n    \xB7 Set auto-replies for emails sent to old domains.\n\
        \    \xB7 Update online references and cloud service settings.\n    \xB7 Change\
        \ or delete accounts registered with old domains.\n     \xB7 Keep login email\
        \ addresses current and enable MFA.\n    \xB7 Avoid using non-approved cloud\
        \ storage for sensitive data.\n\xB7 Follow Asset Management Best Practices\n\
        \    Guidance from trusted sources, such as the Asset Management policy template\
        \ in the CyFun\xAE Toolbox on www.cyfun.eu, should be used to support secure\
        \ disposal.\n\xB7 Include OT Assets in Disposal Planning\n    OT systems and\
        \ devices should be included in disposal procedures, ensuring operational\
        \ data and configurations are securely removed before decommissioning."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds
      ref_id: PR.DS-02
      description: The confidentiality, integrity, and availability of data-in-transit
        are protected
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-02
      ref_id: PR.DS-02.1
      description: Portable storage devices containing system data shall be controlled
        and protected while in transit and in storage.
      annotation: "The goal of this control is to prevent unauthorised access, tampering,\
        \ or loss of critical system data when portable storage devices are moved\
        \ between locations or stored outside secure environments.\n\nIn OT environments,\
        \ where data may be transferred between isolated systems or remote sites using\
        \ physical media, protecting these devices is essential to maintain system\
        \ integrity and confidentiality.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Scan all portable storage devices for malicious code before\
        \ use on organisational systems.\n\xB7 Encrypt data to ensure confidentiality\
        \ if a device is lost or stolen.\n\xB7 Use tamper-evident seals and locked\
        \ containers during transport.\n\xB7 Rely on trusted couriers or secure transport\
        \ services, and avoid leaving devices unattended.\n\xB7 Limit access to stored\
        \ devices to authorised personnel, supported by documented access control\
        \ policies.\n\xB7 Store devices in secure, climate-controlled environments\
        \ to prevent physical damage.\n\xB7 Conduct regular audits and inventory checks\
        \ to ensure devices are accounted for and properly secured."
      implementation_groups:
      - E
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-02
      ref_id: PR.DS-02.2
      description: The organisation shall protect its critical and sensitive information
        while in transit.
      annotation: "The goal of this control is to ensure that critical and sensitive\
        \ information remains confidential and unaltered while being transmitted across\
        \ networks or between systems, especially in environments where data flows\
        \ between IT and OT layers or across remote sites.\nIn OT contexts, where\
        \ data may traverse less secure or legacy communication channels (e.g. between\
        \ control systems, field devices, or remote monitoring stations), protection\
        \ in transit is essential to prevent interception, manipulation, or leakage.\
        \ This control builds further on PR.DS-01.1.\n\nTo enable the protection of\
        \ the organisation's critical and sensitive information while in transit,\
        \ the following techniques should be considered:\n\xB7 Encryption: Use strong\
        \ encryption protocols like Transport Layer Security (TLS) or Secure Sockets\
        \ Layer (SSL) to encrypt data during transmission. This ensures that even\
        \ if data is intercepted, it remains unreadable to unauthorised parties.\n\
        \xB7 End-to-End Encryption (E2EE): Implement E2EE, which encrypts data on\
        \ the sender\u2019s device and only decrypts it on the recipient\u2019s device.\n\
        \xB7 Multi-Factor Authentication (MFA): Require MFA for accessing sensitive\
        \ information.\n\xB7 Strong Password Policies: Enforce strong password policies,\
        \ including the use of complex passwords and regular updates.\n\xB7 Virtual\
        \ Private Networks (VPNs): Use VPNs \u2014 either site-to-site or remote access\
        \ \u2014 to establish secure tunnels for data transmission, in particular\
        \ when connecting over untrusted networks such as public Wi-Fi.\n\xB7 Regular\
        \ Security Audits: Conduct regular security audits to identify and address\
        \ vulnerabilities in your data transmission processes."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-10
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds
      ref_id: PR.DS-10
      description: The confidentiality, integrity, and availability of data-in-use
        are protected
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-10.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-10
      ref_id: PR.DS-10.1
      description: "The organisation\u2019s critical systems shall be protected against\
        \ denial-of-service attacks or at least the effect of such attacks shall be\
        \ limited."
      annotation: "The goal of this control is to ensure that critical systems remain\
        \ available and operational even when targeted by denial-of-service (DoS)\
        \ attacks, which aim to overload or disrupt services.\n\nTo achieve this goal,\
        \ the organisation should:\n\xB7 Limit the impact of DoS attacks by:\n   \
        \ \xB7 Deploying boundary protection devices or services that filter malicious\
        \ traffic.\n    \xB7 Ensuring sufficient network capacity and redundancy to\
        \ absorb traffic spikes.\n\xB7 Restrict the ability to launch DoS attacks\
        \ by:\n    \xB7 Limiting connectivity options to prevent unauthorised transmission\
        \ over wired, wireless, or satellite links.\n    \xB7 Enforcing resource usage\
        \ limits to prevent system overload.\n    \xB7 Applying strong authentication\
        \ and authorisation to control access to critical functions.\n\xB7 Strengthen\
        \ system resilience by:\n    \xB7 Conducting regular security testing and\
        \ audits to identify and address vulnerabilities.\n    \xB7 Monitoring network\
        \ traffic for anomalies that may indicate early signs of a DoS attempt.\n\xB7\
        \ OT-Specific Considerations\n    In OT environments, where availability directly\
        \ affects safety and production, even short disruptions can have severe consequences.\
        \ DoS protections should be tailored to industrial protocols and legacy systems,\
        \ ensuring that defences do not interfere with real-time operations."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds
      ref_id: PR.DS-11
      description: Backups of data are created, protected, maintained, and tested.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11
      ref_id: PR.DS-11.1
      description: Backups for the organisation's business critical data shall be
        performed and stored on a different system from the device on which the original
        data resides.
      annotation: "The goal of this control is to ensure that business-critical data\
        \ is regularly backed up and securely stored on a separate system to protect\
        \ against data loss, system failure, or cyberattacks such as ransomware.\n\
        \nTo support this goal, the organisation should:\n\xB7 Back Up Critical Data\
        \ and Systems\n    Backups should include:\n    \xB7 Business-critical data\
        \ (e.g. customer records, financial and operational data).\n    \xB7 System\
        \ data such as software configurations, device settings, documentation, and\
        \ application backups.\n\xB7 Define a Backup Strategy\n    \xB7 Critical data\
        \ should be backed up continuously or in near-real time.\n    \xB7 Other important\
        \ data should be backed up at regular, agreed intervals.\n    \xB7 Backups\
        \ should be stored on a system that is physically or logically separate from\
        \ the original data source.\n    This means they must not reside on the same\
        \ device, server, or storage array as the original data. Ideally, backups\
        \ should be stored in a different security zone, network segment, or even\
        \ offsite location to ensure they remain accessible and uncompromised in the\
        \ event of system failure, ransomware, or other incidents affecting the primary\
        \ environment.\n\xB7 Ensure Network Separation\n    \xB7 Backups should not\
        \ be stored on the same network as the original systems.\n    \xB7 At least\
        \ one backup copy should be kept completely offline or air-gapped to ensure\
        \ recovery in the event of a network breach or ransomware attack.\n\xB7 Plan\
        \ for Recovery\n    Recovery Time Objective (RTO \u2013 how quickly systems\
        \ must be restored) and Recovery Point Objective (RPO \u2013 how much data\
        \ loss is acceptable) should be defined and reviewed regularly to ensure timely\
        \ and effective restoration.\n\xB7 Include OT Environments\n    Backup strategies\
        \ should cover OT systems, including control system configurations, operational\
        \ data, and device settings critical to industrial operations."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11
      ref_id: PR.DS-11.2
      description: The reliability and integrity of backups shall be verified and
        tested regularly.
      annotation: "The goal of this control is to ensure that backup data can be trusted\
        \ and successfully restored when needed, supporting operational continuity\
        \ and resilience.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Test Recovery Procedures\n    Backup recovery procedures should be tested\
        \ regularly to confirm that data can be restored accurately and completely.\n\
        \xB7 Verify Backup Integrity\n    \xB7 Backups should be checked for signs\
        \ of compromise, corruption, or tampering before use.\n    \xB7 Integrity\
        \ checks should focus on indicators of security breaches or data loss.\n\xB7\
        \ Schedule Testing\n    \xB7 All types of data sources should be included\
        \ in backup and restore tests.\n    \xB7 Testing should occur at least annually,\
        \ or more frequently on a sample basis.\n\xB7 Align with Related Controls\n\
        \    This control should be implemented in coordination with RC.RP-05.1 (Recovery\
        \ Planning), ensuring consistency in recovery strategies."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11
      ref_id: PR.DS-11.3
      description: The organisation shall maintain secure backups of business-critical
        data in a separate storage location to ensure data availability in case of
        system failure or data loss. Backup storage shall apply equivalent security
        controls as the primary environment.
      annotation: "The goal of this control is to ensure that the organisation can\
        \ reliably recover its business-critical data in two key scenarios:\n\xB7\
        \ Natural disasters or physical damage to the primary site (requiring offsite\
        \ or cloud-based backups).\n\xB7 Advanced cyberattacks, including ransomware\
        \ or insider threats, where attackers may attempt to corrupt or delete backups\
        \ (requiring isolated or tamper-proof backups).\n\nThis control helps ensure\
        \ that an organisation can recover its critical data if something goes wrong.\
        \ It focuses on keeping backups separate and just as secure as the original\
        \ data, making it especially useful for organisations that are still building\
        \ up their cybersecurity capabilities (organisations with less mature security\
        \ posture).\n\n\xB7 Backup Strategy to be considered\n    \xB7 To meet these\
        \ objectives, the organisation should implement a diversified and resilient\
        \ backup approach, such as the 3-2-1 backup rule:\n        \xB7 Maintain three\
        \ copies of business-critical data.\n        \xB7 Store these copies on at\
        \ least two different types of storage media (e.g. local disk and cloud).\n\
        \        \xB7 Ensure at least one copy is stored offsite or off-premises,\
        \ in a physically separate location.\n\xB7 To protect against both physical\
        \ and cyber threats, the organisation should consider the following backup\n\
        types:\n    \xB7 Offsite or Cloud Backups\n    These backups are stored in\
        \ a geographically separate location and help ensure recoverability in case\
        \ of natural disasters or physical damage to the primary site.\n    \xB7 Immutable\
        \ Backups \n    These are backups that cannot be altered or deleted for a\
        \ defined period. They are especially effective against ransomware and insider\
        \ threats, and can be automated to reduce manual effort.\n    \xB7 Offline\
        \ or Air-Gapped Backups _x0008_\n    These are backups stored on devices that\
        \ are completely disconnected from any network, including the internet. This\
        \ isolation ensures that even if the organisation\u2019s network is compromised,\
        \ the backup remains untouched.\n\xB7 Additional Considerations\n    \xB7\
        \ Geographic Separation: Backup locations should be in different physical\
        \ regions to reduce the risk of simultaneous impact from regional disasters.\n\
        \    \xB7 Security Parity: All backup locations should implement the same\
        \ level of security controls as the primary environment (e.g. encryption,\
        \ access control, monitoring).\n    \xB7 Regular Testing: Backup and recovery\
        \ procedures should be tested regularly to ensure data integrity and operational\
        \ readiness."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11
      ref_id: PR.DS-11.4
      description: The organisation shall regularly verify the integrity and recoverability
        of backups through coordinated testing with all relevant continuity and incident
        response functions. Backup testing shall be integrated into broader resilience
        planning, including business continuity, disaster recovery, and cyber incident
        response.
      annotation: "This control is an evolution of PR.DS-11.3 and ensures that backup\
        \ systems are not only in place but are regularly tested and aligned with\
        \ the organisation\u2019s broader recovery and continuity plans. It highlights\
        \ the importance of coordination across teams and proactive planning, helping\
        \ the organisation stay prepared to recover quickly and effectively from serious\
        \ incidents.\n\nTo ensure that backup and recovery capabilities are effective\
        \ and integrated into the organisation\u2019s overall resilience strategy,\
        \ the following practices should be implemented:\n\xB7 Coordinate Backup Testing\
        \ Across Plans\n    Backup verification should be planned and executed in\
        \ coordination with the teams responsible for the organisation\u2019s key\
        \ continuity and response plans. These include:\n    \xB7 Business Continuity\
        \ Plans (BCP)\n    \xB7 Disaster Recovery Plans (DRP)\n    \xB7 Contingency\
        \ Plans\n    \xB7 Continuity of Operations Plans (COOP)\n    \xB7 Crisis Communications\
        \ Plans\n    \xB7 Critical Infrastructure Protection Plans\n    \xB7 Cyber\
        \ Incident Response Plans\n\xB7 Include Backup Recovery in Scenario Testing\n\
        \    During exercises or simulations of incidents (e.g. cyberattacks, system\
        \ failures, or natural disasters), the recovery of backup data should be explicitly\
        \ tested. This ensures that backups are not only available but also usable\
        \ and aligned with recovery time and recovery point objectives (RTO/RPO).\n\
        \xB7 Document and Review Results\n    The outcomes of backup verification\
        \ and recovery tests should be documented and reviewed with relevant stakeholders\
        \ to identify gaps and improve procedures."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ds-11
      ref_id: PR.DS-11.5
      description: Backups of critical systems (such as operating systems, configurations,
        and applications) shall be kept separate from backups of critical information
        (such as business data, documents, and databases) to support faster and more
        reliable recovery.
      annotation: "The goal of this control is to support faster and more reliable\
        \ recovery by separating backups of critical systems (e.g. operating systems,\
        \ configurations, applications) from backups of critical information (e.g.\
        \ business data, documents, databases).\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Separate backup scopes\n    \xB7 System backups should include\
        \ operating systems, configurations, installed software, and system-level\
        \ settings.\n    \xB7 Information backups should include business-critical\
        \ data such as databases, documents, and application data.\n\xB7 Use tailored\
        \ backup methods\n    \xB7 System backups should use full images or snapshots\
        \ to capture the complete system state.\n    \xB7 Information backups should\
        \ use incremental or differential methods to efficiently capture data changes.\n\
        \xB7 Encrypt sensitive data\n    Both system and information backups should\
        \ be encrypted during storage and transmission, especially when containing\
        \ sensitive or regulated data.\n\xB7 Align with recovery objectives\n    Backup\
        \ separation should reflect different Recovery Time Objectives (RTOs) and\
        \ Recovery Point Objectives (RPOs). For example, system recovery may require\
        \ faster restoration than business data.\n\xB7 Document and automate\n   \
        \ \xB7 Backup scopes and procedures should be clearly documented.\n    \xB7\
        \ Backup processes should be automated where possible to reduce human error\
        \ and ensure consistency.\nOT-Specific Considerations\n    In OT environments,\
        \ separating system and data backups helps restore control systems quickly\
        \ without waiting for large data sets to be recovered. This supports operational\
        \ continuity and reduces downtime in critical industrial processes.\n\nRelation\
        \ with PR.DS-11.3 and PR.DS-11.4\nPR.DS-11.5 is an evolution \u2014 not a\
        \ repetition \u2014 of PR.DS-11.3 and PR.DS-11.4. While the earlier controls\
        \ focus on where and how backups are stored and verified, PR.DS-11.5 focuses\
        \ on what is being backed up and how it is logically separated to optimise\
        \ recovery:\n    \xB7 PR.DS-11.3 ensures backups are secure and stored separately.\n\
        \    \xB7 PR.DS-11.4 ensures backups are tested and integrated into recovery\
        \ planning.\n    \xB7 PR.DS-11.5 ensures functional separation between system\
        \ and data backups to enable faster, more targeted recovery."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr
      ref_id: PR.PS
      name: Platform Security
      description: The hardware, software (e.g., firmware, operating systems, applications),
        and services of physical and virtual platforms are managed consistent with
        the organisation's risk strategy to protect their confidentiality, integrity,
        and availability.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      ref_id: PR.PS-01
      description: Configuration management practices are established and applied.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01
      ref_id: PR.PS-01.1
      description: The organisation shall develop, document, and maintain a baseline
        configuration for its business-critical systems.
      annotation: "This control ensures that all business-critical systems operate\
        \ in a known, secure, and approved state. A baseline configuration defines\
        \ the standard setup for these systems, helping to detect unauthorised changes,\
        \ enforce security policies, and support consistent operations.\n\nTo implement\
        \ this control the following should be considered:\n\xB7 Definition of what\
        \ is Business-Critical\n    Business-critical systems may include IT, OT (Operational\
        \ Technology), and potentially IoT (Internet of Things) components \u2014\
        \ if they support essential business functions:\n    \xB7 IT systems are typically\
        \ managed internally.\n    \xB7 OT systems may include industrial control\
        \ systems.\n    \xB7 IoT systems (e.g. sensors, smart devices) can be business-critical\
        \ if their failure disrupts operations or introduces security risks.\n\xB7\
        \ Establish and Maintain Baseline Configurations\n    For each business-critical\
        \ system, the baseline should include:\n    \xB7 System components (e.g. approved\
        \ software, hardware)\n    \xB7 Operating system and application versions,\
        \ including patch levels\n    \xB7 Configuration settings and parameters\n\
        \    \xB7 Network topology, showing how components are connected, including:\n\
        \    \xB7 External connections\n    \xB7 Servers hosting sensitive data or\
        \ functions\n    \xB7 DNS and security services\n    \xB7 Logical placement\
        \ of components within the system architecture\n\xB7 Apply Security Principles\n\
        \    \xB7 Baselines should enforce the principle of least functionality \u2014\
        \ only necessary features and services should be enabled.\n    \xB7 Default\
        \ settings should be reviewed and adjusted to reduce security risks during\
        \ installation or upgrades.\n\xB7 Monitor and Update\n    \xB7 Continuously\
        \ monitor systems for deviations from the approved baseline.\n    \xB7 Update\
        \ baselines when systems are patched, upgraded, or reconfigured.\n\xB7 Cloud\
        \ and Supplier-Managed Systems\n    For systems managed by third parties (e.g.\
        \ cloud services), ensure that baseline expectations are defined contractually\
        \ and that suppliers provide visibility into configuration and change management."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01
      ref_id: PR.PS-01.2
      description: The organisation shall configure its business-critical systems
        to operate with only the essential functions needed for their intended purpose.
        This includes reviewing and updating baseline configurations to disable any
        non-essential capabilities.
      annotation: "The goal of this control is to reduce security risks and system\
        \ complexity by ensuring that business-critical systems are configured to\
        \ run only the functions necessary for their intended purpose.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Apply the principle of least functionality\
        \ by disabling non-essential features, services, and components.\n\xB7 Regularly\
        \ review and update baseline configurations to reflect operational needs and\
        \ evolving threats.\n\xB7 Assess and limit the following elements to what\
        \ is strictly required:\n    \xB7 Installed software\n    \xB7 Enabled services\n\
        \    \xB7 Open ports\n    \xB7 Allowed protocols\n    \xB7 System features\n\
        \xB7 Align configurations with security policies to minimise exposure to vulnerabilities\
        \ and improve system performance."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01
      ref_id: PR.PS-01.3
      description: The organisation shall identify and disable specific functions,
        ports, protocols, and services within its critical systems that are not required
        for business operations.
      annotation: "The goal of this control is to reduce the attack surface of critical\
        \ systems by disabling functions, ports, protocols, and services that are\
        \ not essential for business operations.\n\nTo achieve this goal, the organisation\
        \ should:\n\xB7 Identify system features that are not required based on the\
        \ system\u2019s role and associated risks.\n\xB7 Disable unnecessary elements\
        \ to limit potential entry points and reduce lateral movement within the network.\n\
        \xB7 Regularly assess and update configurations to reflect operational needs\
        \ and evolving threats.\n\xB7 Elements to consider disabling include:\n  \
        \   \xB7 Bluetooth\n    \xB7 File Transfer Protocol (FTP)\n    \xB7 Peer-to-peer\
        \ networking\n    \xB7 Other unused or legacy services"
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01
      ref_id: PR.PS-01.4
      description: "The organisation shall implement technical safeguards to enforce\
        \ a policy of \u2018deny-all\u2019 and \u2018permit-by-exception\u2019 so\
        \ that only authorised software programmes are executed."
      annotation: "The goal of this control is to ensure that only explicitly authorised\
        \ software is allowed to run, reducing the risk of unauthorised or malicious\
        \ programs affecting critical systems.\n\nTo achieve this goal, the organisation\
        \ should consider the following:\n\xB7 Implement application whitelisting\
        \ to allow only approved software to execute.\n\xB7 Use group policies to\
        \ enforce application control rules across systems.\n\xB7 Apply Software Restriction\
        \ Policies (SRP) or similar mechanisms to block unauthorised software based\
        \ on file path, hash, or digital signature.\n\xB7 Enforce role-based access\
        \ control (RBAC) to ensure only authorised users can run specific applications.\n\
        \xB7 Configure Java Security Manager to restrict which classes and methods\
        \ can execute in Java-based environments.\n\xB7 Use configuration management\
        \ tools to maintain consistent enforcement of authorised software across all\
        \ systems."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-01
      ref_id: PR.PS-01.5
      description: Unauthorised configuration changes to organisation's systems shall
        be monitored and addressed with the appropriate mitigation actions.
      annotation: "The goal of this control is to detect and respond to unauthorised\
        \ configuration changes that could compromise system integrity or availability.\n\
        \nTo achieve this goal, the organisation should consider to:\n\xB7 Monitor\
        \ configuration changes in line with defined policies and procedures.\n\xB7\
        \ Detect and log unauthorised modifications to system settings.\n\xB7 Alert\
        \ designated personnel when unauthorised changes occur.\n\xB7 Restore approved\
        \ configurations promptly to maintain operational stability.\n\xB7 Halt, in\
        \ critical cases, affected system processes to prevent further impact.\n\xB7\
        \ Consult the guidance in ENISA NIS2 Technical Implementation Guidance (latest\
        \ version), which recommends continuous monitoring and prompt mitigation of\
        \ unauthorised changes to preserve system resilience and compliance."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      ref_id: PR.PS-02
      description: Software is maintained, replaced, and removed commensurate with
        risk.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-02
      ref_id: PR.PS-02.1
      description: The organisation shall enforce restrictions on software usage and
        installation, and ensure that software is maintained, replaced, or removed
        based on its associated risk.
      annotation: "The goal of this control is to reduce security and operational\
        \ risks by controlling which software is used, ensuring it is properly maintained,\
        \ and removing it when no longer needed or supported.\n\nTo achieve this goal,\
        \ the organisation should consider to:\n\xB7 Allow only approved software\
        \ and restrict access based on user roles and responsibilities.\n\xB7 Replace\
        \ unsupported or end-of-life software to avoid unpatched vulnerabilities.\n\
        \xB7 Uninstall unused or unnecessary software, including outdated OS utilities,\
        \ to reduce the attack surface.\n\xB7 Apply patches based on risk:\n    \xB7\
        \ Critical vulnerabilities should be patched within hours.\n    \xB7 Routine\
        \ updates should follow a defined schedule (e.g. weekly or monthly).\n\xB7\
        \ In container environments, only trusted and up-to-date images should be\
        \ used; outdated containers should be replaced.\n\xB7 Remove or disable software\
        \ and services that pose unacceptable risk, such as FTP or peer-to-peer tools,\
        \ unless explicitly required and secured.\n\xB7 In ICS/OT environments, ensure\
        \ PLC programming is pre-approved and scheduled; avoid ad-hoc changes to protect\
        \ operational safety.\n\xB7 Maintain a software inventory with version and\
        \ support status.\n\xB7 Define procedures for software approval, patching,\
        \ replacement, and removal."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      ref_id: PR.PS-03
      description: Hardware is maintained, replaced, and removed commensurate with
        risk.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-03
      ref_id: PR.PS-03.1
      description: Hardware used in business-critical environments shall be maintained,
        replaced, or removed based on its associated security and operational risk.
      annotation: "The goal of this control is to ensure that hardware used in business-critical\
        \ environments remains secure, reliable, and fit for purpose by managing it\
        \ based on operational and security risks.\n\nTo achieve this goal, the organisation\
        \ should consider to:\n\xB7 Regularly assess whether hardware supports required\
        \ security features (e.g. encryption, secure boot, firmware updates); replace\
        \ hardware that cannot meet these needs.\n\xB7 Phase out end-of-life or unsupported\
        \ hardware in a controlled manner.\n\xB7 Define and maintain a hardware lifecycle\
        \ plan, including:\n    \xB7 Inventory tracking\n    \xB7 End-of-life timelines\n\
        \    \xB7 Replacement schedules\n    \xB7 Secure disposal procedures\n\xB7\
        \ Perform preventive maintenance and timely replacements to avoid unexpected\
        \ failures that could impact operations or security.\n\xB7 Ensure hardware\
        \ can support secure, up-to-date software; address any limitations that prevent\
        \ this."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      ref_id: PR.PS-04
      description: Log records are generated and made available for continuous monitoring.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04
      ref_id: PR.PS-04.1
      description: Logs shall be maintained, documented, and monitored.
      annotation: "The goal of this control is to ensure that logs are consistently\
        \ maintained, documented, and monitored to support visibility, accountability,\
        \ and early detection of anomalies or threats.\n\nTo support this goal, the\
        \ organisation should:\n\xB7 Enable Logging Across Systems\n    All operating\
        \ systems, applications, services (including cloud-based), and security tools\
        \ (e.g. firewalls, anti\xAD virus) should be configured to generate log records.\n\
        \xB7 Include a Variety of Log Types\n    Logs should include, where applicable:\
        \ audit logs, event logs, application logs, security logs, system logs, and\
        \ maintenance logs.\n\xB7 Protect Log Data\n    Logs should be protected from\
        \ unauthorised access using encryption and access controls.\n\xB7 Back Up\
        \ and Retain Logs\n    Log backups should be performed regularly and retained\
        \ for a predefined period, based on business needs or regulatory requirements.\n\
        \xB7 Review Logs for Anomalies\n    Logs should be reviewed to detect unusual\
        \ patterns or behaviours, such as repeated malware detections or excessive\
        \ access to non-business websites.\n\xB7 Define Retention Periods\n    Retention\
        \ periods for logs should be clearly defined. Sector-specific requirements\
        \ should be taken into account.\n\xB7 Support Monitoring and Accountability\n\
        \    Monitoring should be in place to provide visibility into system activity\
        \ and support effective auditing and incident response.\n\xB7 Include OT Systems\n\
        \    Logging practices should extend to OT environments, including industrial\
        \ control systems, where logs can help detect operational anomalies or unauthorised\
        \ access attempts."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04
      ref_id: PR.PS-04.2
      description: The organisation shall ensure that logbook records contain an authoritative
        time source or internal clock time stamp that is compared and synchronised
        with an authoritative time source.
      annotation: "The goal of this control is to ensure that logbook records across\
        \ systems use a consistent and trusted time reference, so that events can\
        \ be accurately tracked and correlated.\n\nTo achieve this goal, the organisation\
        \ should consider to:\n\xB7 Use a reliable time reference such as a GPS clock,\
        \ internal time server, or other trusted source to synchronise system clocks.\n\
        \xB7 Configure systems to update their clocks regularly to avoid time drift.\n\
        \xB7 Set up multiple time sources to ensure redundancy and accuracy.\n\xB7\
        \ Monitor synchronisation status and trigger alerts if systems fall out of\
        \ sync.\n\xB7 Document procedures for time synchronisation, including server\
        \ settings, update intervals, and monitoring processes."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04
      ref_id: PR.PS-04.3
      description: Audit data from the organisation's critical systems shall be moved
        to an alternative system.
      annotation: "The goal of this control is to protect the integrity of audit records\
        \ by transferring them from critical systems to a separate, secure location\
        \ where they cannot be changed or tampered with.\n\nTo achieve this goal,\
        \ the organisation should consider to:\n\xB7 Transfer audit data to a separate\
        \ system where records cannot be modified by users or services from the original\
        \ system.\n\xB7 Ensure the destination system keeps audit records unchanged\
        \ once stored.\n\xB7 Monitor the impact of log transfers to avoid performance\
        \ issues on the source systems.\n\xB7 Put measures in place that protect the\
        \ data without slowing down or disrupting system operations."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04
      ref_id: PR.PS-04.4
      description: The organisation shall ensure that audit processing failures on
        the organisation's systems generate alerts and trigger defined responses.
      annotation: "The goal of this control is to ensure that any failure in audit\
        \ logging, such as errors in log collection, processing, or storage, triggers\
        \ alerts and predefined responses to maintain system integrity and traceability.\n\
        \nTo achieve this goal:\n\xB7 Audit failures should include software or hardware\
        \ issues, broken logging mechanisms, or full storage.\n\xB7 Alerts should\
        \ be automatically generated when such failures occur, and predefined actions\
        \ should be triggered to address them.\n\xB7 Each audit log repository, whether\
        \ on a server, firewall, or application, should be monitored individually\
        \ and collectively.\n\xB7 System Logging Protocol (Syslog) servers or similar\
        \ centralised logging solutions should be used to support reliable log collection\
        \ and alerting.\n\xB7 Systems generating logs should be configured to capture\
        \ detailed activity, access, and behaviour data to support zero-trust principles.\n\
        \xB7 Audit logs should be continuously monitored to ensure availability, integrity,\
        \ and sufficient storage capacity."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-04
      ref_id: PR.PS-04.5
      description: The organisation shall ensure that authorised personnel can extend
        or enhance audit logging and monitoring capabilities when needed to support
        investigations or incident response.
      annotation: "The goal of this control is to ensure that audit logging can be\
        \ quickly adapted to provide deeper visibility during security incidents or\
        \ investigations, without disrupting normal operations.\n\nTo achieve this\
        \ goal:\n\xB7 Audit logging systems should allow on-demand adjustments, such\
        \ as increasing log detail, extending retention, or expanding coverage.\n\xB7\
        \ Authorised personnel and conditions for enabling extended logging should\
        \ be clearly defined.\n\xB7 Activation procedures should include approvals,\
        \ documentation, and change tracking.\n\xB7 Logbook records should be reviewed\
        \ regularly for accuracy and completeness across ICT and OT systems.\n\xB7\
        \ Policies should ensure extended logging is used only when justified and\
        \ is properly recorded.\n\xB7 Technical capacity, escalation paths, and personnel\
        \ availability should be pre-planned to support timely activation."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      ref_id: PR.PS-05
      description: Installation and execution of unauthorised software are prevented.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-05
      ref_id: PR.PS-05.1
      description: Web and e-mail filters shall be installed and used.
      annotation: "The goal of this control is to reduce the risk of malware infections,\
        \ phishing attacks, and data breaches by implementing and maintaining effective\
        \ web and email filtering solutions.\n\nTo support this goal, the organisation\
        \ should:\n\xB7 Implement Web Filtering\n    Web filters should be used to\
        \ control access to websites based on:\n    \xB7 Predefined allow/block lists\
        \ (e.g. by URL or domain)\n    \xB7 Real-time content analysis to detect malicious\
        \ or inappropriate content\n    \xB7 Techniques such as URL filtering, content\
        \ filtering, DNS filtering, and client- or server-side filtering\n\xB7 Configure\
        \ Email Filtering\n    Email filters should be configured to:\n    \xB7 Block\
        \ spam, phishing attempts, and malicious attachments or links\n    \xB7 Categorise\
        \ incoming emails (e.g. newsletters, social media alerts) to reduce clutter\
        \ and improve awareness\n    \xB7 Scan for known threats and suspicious patterns\
        \ to enhance email security\n\xB7 Keep Filters Updated\n    Filtering rules\
        \ and threat databases should be updated regularly to respond to evolving\
        \ threats.\n\xB7 Integrate with Security Policies\n    Web and email filtering\
        \ should align with the broader organisational security policies and awareness\
        \ efforts.\n\xB7 Include OT Considerations\n    In OT environments, internet\
        \ and email access should be restricted to only what is operationally necessary.\
        \ Filtering should be applied to any systems with external connectivity to\
        \ prevent exposure to threats."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-05.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-05
      ref_id: PR.PS-05.2
      description: Installation and execution of unauthorised software shall be prevented.
      annotation: "The goal of this control is to reduce the risk of compromise by\
        \ ensuring only trusted and approved software is installed and executed on\
        \ systems.\n\nTo achieve this goal:\n\xB7 Software installation and execution\
        \ should be limited to pre-approved applications and environments.\n\xB7 Platforms\
        \ should be configured to block unauthorised software and restrict execution\
        \ where the risk justifies it.\n\xB7 The source and integrity of all new software\
        \ should be verified before installation.\n\xB7 Access to harmful websites\
        \ should be blocked using trusted and approved internet filtering services\
        \ that are designed to detect and stop known online threats.\n\xB7 Where possible,\
        \ systems should be configured to allow installation of organisation-approved\
        \ software only."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps
      ref_id: PR.PS-06
      description: Secure software development practices are integrated, and their
        performance is monitored throughout the software development life cycle.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06
      ref_id: PR.PS-06.1
      description: Security shall be considered throughout the lifecycle of systems
        and applications, whether developed internally or acquired externally.
      annotation: "The goal of this control is to make sure that security is built\
        \ into systems and applications from the beginning and maintained throughout\
        \ their entire life \u2014 from design to retirement \u2014 whether they are\
        \ developed in-house or purchased.\n\nTo achieve this goal:\n\xB7 Initiation\
        \ Phase:\n    Security requirements should be defined early, risks identified,\
        \ and relevant stakeholders, including security experts, engaged from the\
        \ start.\n\xB7 Acquisition or Development Phase:\n    For acquired solutions:\
        \ vendors should follow secure development practices, provide evidence of\
        \ testing, and meet contractual security requirements.\n    \xB7 For in-house\
        \ development: secure coding practices should be applied, changes managed,\
        \ and security testing conducted.\n    \xB7 Implementation Phase: Systems\
        \ should be securely configured before deployment, with access controls and\
        \ encryption applied to protect sensitive data.\n\xB7 Operations and Maintenance\
        \ Phase:\n    Systems should be monitored for incidents, regularly updated,\
        \ and security controls reviewed and improved as needed.\n\xB7 Disposition\
        \ Phase:\n    Systems should be decommissioned securely, sensitive data removed,\
        \ and lessons learned documented to strengthen future processes."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06
      ref_id: PR.PS-06.2
      description: Changes and exceptions shall be tested and validated before being
        implemented into operational systems.
      annotation: "The goal of this control is to reduce the risk of disruptions or\
        \ vulnerabilities by ensuring that all changes and exceptions are properly\
        \ tested and validated before being applied to operational systems.\n\nTo\
        \ achieve this goal:\n\xB7 All proposed changes and exceptions should follow\
        \ a formal process that includes documentation, review, testing, and approval.\n\
        \xB7 The potential risks of applying, or not applying, a change should be\
        \ assessed and recorded.\n\xB7 Exceptions, defined as approved deviations\
        \ from standard policies or procedures, should be evaluated with a clear understanding\
        \ of the risks and a defined plan to reduce or manage them.\n\xB7 Accepted\
        \ risks should be periodically reviewed to confirm that the original decision\
        \ to accept them remains valid, especially if conditions change or if the\
        \ acceptance was based on future actions or milestones.\n\xB7 These practices\
        \ should be adapted to the operational environment to avoid unplanned downtime\
        \ or safety issues, especially in OT systems."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06
      ref_id: PR.PS-06.3
      description: Secure software development practices shall be integrated into
        all phases of the software development lifecycle, and their effectiveness
        should be regularly monitored and improved.
      annotation: "The goal of this control is to reduce security risks in software\
        \ by embedding protective measures throughout development and continuously\
        \ improving them based on performance and evolving threats.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Integrate Security into the Development\
        \ Lifecycle\n    \xB7 Secure coding standards and trusted development frameworks\
        \ should be applied.\n    \xB7 Threat modelling should be conducted early\
        \ to identify and reduce risks.\n    \xB7 All software components should be\
        \ protected from tampering and unauthorised access.\n    \xB7 Access controls\
        \ for databases and sensitive data should be enforced.\n    \xB7 Software\
        \ dependencies and libraries should be kept up to date.\n    \xB7 Outdated\
        \ or unused software should be securely removed.\n\xB7 Monitor the Effectiveness\
        \ of Security Practices\n    \xB7 Metrics should be defined and tracked, such\
        \ as:\n        \xB7 Vulnerabilities found during development vs. in production.\n\
        \        \xB7 Time taken to fix identified issues.\n        \xB7 Percentage\
        \ of code reviewed or tested for security.\n        \xB7 Developer participation\
        \ in secure coding training.\n    \xB7 These metrics should be used to identify\
        \ gaps and improve practices.\n\xB7 Build Security Awareness\n    Developers\
        \ and technical teams should receive regular training on secure coding and\
        \ design principles.\n\xB7 Maintain and Improve\n    Secure development practices\
        \ should be reviewed and updated based on:\n    \xB7 New threats or vulnerabilities.\n\
        \    \xB7 Lessons learned from incidents or audits.\n    \xB7 Industry standards\
        \ and best practices."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ps-06
      ref_id: PR.PS-06.4
      description: For planned changes to the organisation's critical systems, a security
        impact analysis shall be performed in a separate test environment before implementation
        in an operational environment.
      annotation: "The goal of this control is to prevent unintended security risks\
        \ by testing planned changes to critical systems in a controlled environment\
        \ before deployment.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Plan the Test Scenario\n    \xB7 Security threats to systems, assets, processes,\
        \ and people should be identified.\n    \xB7 Planned configuration changes\
        \ or system modifications should be analysed for their potential impact on\
        \ security.\n\xB7 Prepare the Test Environment\n    \xB7 Test data should\
        \ reflect realistic operational scenarios.\n    \xB7 Hardware, software, and\
        \ network requirements should be clearly defined.\n    \xB7 The test environment\
        \ should closely mirror the production environment in setup and configuration.\n\
        \    \xB7 Sufficient disk space should be allocated for testing activities.\n\
        \    \xB7 Software versions in the test environment should match those in\
        \ production.\n\xB7 Ensure Security and Maintainability\n    \xB7 Software\
        \ in the test environment should be regularly updated to address known vulnerabilities.\n\
        \    \xB7 Virtualisation or containerisation should be used to create consistent\
        \ and replicable environments.\n    \xB7 Isolated virtual machines (VMs) should\
        \ be used to prevent interference with operational systems.\n    \xB7 Security\
        \ controls such as firewalls and access restrictions should be implemented\
        \ in the test environment."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr
      ref_id: PR.IR
      name: Technology Infrastructure Resilience
      description: Security architectures are managed with the organisation's risk
        strategy to protect asset confidentiality, integrity, and availability, and
        organisational resilience.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir
      ref_id: PR.IR-01
      description: Networks and environments are protected from unauthorised logical
        access and usage.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.1
      description: Firewalls shall be installed, configured, and actively maintained
        on all networks used by the organisation to protect against unauthorised  access
        and cyber threats.
      annotation: "The goal of this control is to ensure that all networks used by\
        \ the organisation are protected against unauthorised access and cyber threats\
        \ through the installation, configuration, and active maintenance of firewalls.\n\
        \nThis control focuses on the installation, configuration, and maintenance\
        \ of network-based firewalls to prevent unauthorised access by monitoring\
        \ and controlling traffic entering or leaving the network (focus: control\
        \ and prevention). In contrast, control DE.CM-01.1 addresses host-based firewalls,\
        \ which help detect threats that bypass the network perimeter by monitoring\
        \ traffic to and from individual devices (focus: visibility and detection).\n\
        \nTo implement this control, the organisation should:\n\xB7 Protect the Network\
        \ Perimeter\n    \xB7 A firewall should be installed between the internal\
        \ network and the internet. This may be integrated into a wireless access\
        \ point, router, or ISP-provided device.\n    \xB7 Firewalls should be configured\
        \ based on a baseline security policy using the principle of \u201Cdeny all\
        \ by default, allow only exceptions.\u201D\n\xB7 Secure Endpoint Devices\n\
        \    \xB7 A software firewall should be installed and regularly updated on\
        \ all endpoint devices, including laptops, smartphones, and other networked\
        \ systems.\n    \xB7 Local firewalls should remain active even when using\
        \ VPNs or cloud services.\n\xB7 Secure Home and Remote Work Environments\n\
        \    \xB7 Home networks used for teleworking should use routers with built-in\
        \ firewalls, which should be enabled, securely configured, and kept up to\
        \ date.\n    \xB7 Software firewalls should be active and updated on all remote\
        \ work devices.\n    \xB7 Default administrator credentials on home routers\
        \ should be changed and updated regularly.\n\xB7 Protect Operational Technology\
        \ (OT) Environments\n    \xB7 Remote access to OT systems should be treated\
        \ as third-party access, not standard teleworking.\n    \xB7 A clear separation\
        \ between IT and OT networks should be enforced.\n    \xB7 When IT-to-OT access\
        \ is necessary, it should pass through a secure jump host located in a dedicated\
        \ DMZ.\n\xB7 Enhance Detection with IDPS\n    An Intrusion Detection and Prevention\
        \ System (IDPS) should be considered to monitor and analyse network traffic\
        \ for suspicious activity and enhance overall protection."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.2
      description: To safeguard critical systems, organisations shall implement network
        segmentation and segregation aligned with trust boundaries and asset criticality,
        thereby limiting threat propagation and enforcing strict access control.
      annotation: "The goal of this control is to limit the spread of cyber threats\
        \ and enforce strict access control by implementing network segmentation and\
        \ segregation based on trust boundaries and the criticality of systems.\n\n\
        To implement this control, the following should be considered:\n\xB7 Define\
        \ Security Zones\n    Networks should be divided into distinct zones (e.g.\
        \ office, production, guest, mobile). Traffic between zones should be monitored\
        \ and controlled, for example using firewalls.\n\xB7 Align Segmentation with\
        \ Trust and Criticality\n    Segmentation should reflect which users and systems\
        \ are trusted and how critical each asset is. Only essential communication\
        \ between zones should be allowed, following the principle of least privilege.\n\
        \xB7 Avoid Flat Networks\n    Flat networks should be avoided, as compromising\
        \ one system could expose the entire environment. Segmentation should help\
        \ contain threats within a single zone.\n\xB7 Separate IT and OT Environments\n\
        \    In environments with industrial systems (OT), office and production networks\
        \ should be separated. Guest and mobile networks should not have direct access\
        \ to internal office or production systems. Segmentation should follow the\
        \ IEC 62443 standard, in particular requirements SR 5.1 to SR 5.3.\n\xB7 Use\
        \ VLANs with Caution\n    VLANs should be used only as part of a broader defence-in-depth\
        \ strategy. They should not be relied on alone to meet Security Level 2 requirements\
        \ under IEC 62443-3-3. VLANs should be combined with firewalls, access controls,\
        \ and monitoring.\n\xB7 Enforce Segmentation with Firewalls\n    Firewalls\
        \ should be configured to block all traffic by default and allow only specific,\
        \ approved connections. Segmentation and segregation should be enforced through\
        \ well-maintained firewall rules, in line with control PR.IR-01.1.\n\xB7 Clarify\
        \ Segmentation vs. Segregation\n    \xB7 Segmentation should be used to logically\
        \ divide networks and control traffic between zones.\n    \xB7 Segregation\
        \ should be applied where systems have to be isolated, with no direct communication\
        \ unless explicitly permitted."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.3
      description: To ensure operational stability and security, the organisation
        shall, without exception, identify, document, and control connections between
        components of its critical systems.
      annotation: "The goal of this control is to maintain operational stability and\
        \ security by ensuring that all connections between components of critical\
        \ systems are known, documented, and actively managed.\n\nIn OT environments,\
        \ undocumented or uncontrolled connections \u2014 whether physical, wireless,\
        \ or logical \u2014 can introduce vulnerabilities, disrupt processes, or bypass\
        \ safety mechanisms.\n\nTo effectively manage and secure network connections\
        \ between system components, the following practices should be considered:\n\
        \xB7 Configuration Management\n    Organisations should implement configuration\
        \ management processes to ensure that all changes to network connections are\
        \ documented, reviewed, and approved. Configuration files and logs should\
        \ be kept current and securely maintained.\n\xB7 Access Controls\n    Strict\
        \ access controls should be enforced to ensure that only authorised personnel\
        \ can modify network configurations. Role-Based Access Control (RBAC) should\
        \ be used to restrict access based on job responsibilities and operational\
        \ needs.\n\xB7 Regular Audits\n    Regular audits should be conducted to verify\
        \ that all documented connections remain accurate and that no unauthorised\
        \ changes have occurred. Audit results should be used to update documentation\
        \ and strengthen controls.\n\xB7 Link to Asset Management (ID.AM)\n    Connections\
        \ between system components should be documented under ID.AM (Asset Management)\
        \ and controlled under this requirement (PR.IR-01.3) to ensure consistency,\
        \ traceability, and enforceability across the organisation\u2019s cybersecurity\
        \ architecture."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.4
      description: The organisation shall implement appropriate boundary protection
        measures to monitor and control communications at external and key internal
        boundaries of its critical systems, across both IT and OT environments, to
        ensure secure and reliable operations.
      annotation: "The goal of this control is to ensure secure and reliable operations\
        \ by actively monitoring and controlling communications at key network boundaries\
        \ \u2014 especially where critical systems interface with external networks\
        \ or less trusted internal zones.\n\nIn OT environments, where legacy systems\
        \ often lack built-in security, boundary protection is essential to prevent\
        \ unauthorised access, contain potential threats, and maintain process integrity\
        \ across IT and OT domains.\n\nTo achieve this goal, the following should\
        \ be considered:\n\xB7 Boundary Protection Devices\n    Firewalls, security\
        \ gateways, and routers should be deployed at external and internal boundaries\
        \ to enforce traffic filtering and routing policies. These devices should\
        \ operate under a \u201Cdeny by default, allow by exception\u201D model.\n\
        \xB7 Zoning and Isolation in OT Environments\n    In OT environments, boundary\
        \ protection should include strict separation between control systems and\
        \ external networks. Zones should be defined based on criticality and trust,\
        \ and communications between zones should be tightly controlled and monitored.\n\
        \xB7 Unidirectional Gateways (Data Diodes)\n    Where data must flow from\
        \ secure OT systems to external destinations (e.g. cloud services or regulators),\
        \ unidirectional gateways should be used to prevent inbound threats while\
        \ allowing outbound data transfer.\n\xB7 Encrypted Communications\n    Communications\
        \ across boundaries should be encrypted using secure protocols (e.g. VPNs,\
        \ TLS) to protect data in transit and ensure confidentiality and integrity.\n\
        \xB7 Intrusion Detection and Prevention\n    Intrusion Detection and Prevention\
        \ Systems (IDPS) should be deployed at key boundaries to monitor traffic for\
        \ anomalies, detect unauthorised access attempts, and block malicious activity.\n\
        \xB7 Access Control Enforcement\n    Access to boundary devices and communication\
        \ channels should be restricted to authorised personnel. Network Access Control\
        \ (NAC) solutions should be considered to enforce device and user authentication\
        \ at entry points.\n\xB7 Continuous Monitoring and Patching\n    Boundary\
        \ devices and communication channels should be continuously monitored for\
        \ suspicious activity. All systems exposed to external or inter-zone communication\
        \ should be regularly updated and patched to address known vulnerabilities."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.5
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.5
      description: The organisation shall implement, where feasible, authenticated
        proxy servers or firewalls with URL filtering and threat intelligence capabilities
        for defined communications traffic between its critical systems and external
        networks.
      annotation: "The goal of this control is to reduce the risk of cyber threats\
        \ entering critical systems, by filtering and inspecting outbound and inbound\
        \ communications through authenticated proxies or firewalls.\n\nTo achieve\
        \ this goal, the following should be considered:\n\xB7 Access Controls\n \
        \   Proxy servers and firewalls should enforce strict access controls, allowing\
        \ only authorised users and systems. Strong authentication methods, such as\
        \ multi-factor authentication (MFA), should be used to support zero-trust\
        \ principles.\n\xB7 Encryption\n    Communications between clients and proxy\
        \ servers should be encrypted using the most current and secure versions of\
        \ SSL/TLS to protect against eavesdropping and man-in-the-middle attacks.\n\
        \xB7 Threat Intelligence and URL Filtering\n    \xB7 To effectively monitor\
        \ and control communications across IT and OT environments, proxy servers\
        \ and firewalls should:\n    \xB7 Integrate threat intelligence feeds to detect\
        \ and block known malicious domains, IP addresses, and URLs.\n    \xB7 Apply\
        \ URL filtering to prevent access to harmful or unauthorised web content.\n\
        \    \xB7 In OT environments, where systems often lack built-in security features,\
        \ intelligent filtering at network boundaries should be used to:\n       \
        \ \xB7 Detect and block malicious traffic before it reaches critical systems.\n\
        \        \xB7 Prevent data exfiltration and unauthorised external communication.\n\
        \        \xB7 Enforce communication policies without disrupting operational\
        \ processes.\n    These measures should be part of a layered defence strategy\
        \ that supports secure and reliable operations across both IT and OT domains.\n\
        \xB7 Logging and Monitoring\n    Detailed logging and continuous monitoring\
        \ should be enabled to track access, detect anomalies, and support incident\
        \ response. Logs should be regularly reviewed for signs of compromise.\n\xB7\
        \ Firewall Configuration\n    Firewalls should be configured to allow only\
        \ explicitly authorised traffic to and from proxy servers. A \u201Cdeny by\
        \ default\u201D policy should be enforced.\n\xB7 Regular Updates and Patching\n\
        \    Proxy servers, firewalls, and their underlying systems should be regularly\
        \ updated and patched to address known vulnerabilities and maintain security\
        \ effectiveness.\n\xB7 Performance and Reliability\n    Load balancing should\
        \ be used to distribute traffic across multiple proxy servers or firewalls,\
        \ ensuring high availability and optimal performance. Resource usage should\
        \ be monitored to prevent overload and degradation."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.6
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.6
      description: The organisation shall ensure that its critical systems are designed
        to fail securely and remain protected in the event of an operational failure
        of a border protection device.
      annotation: "The goal of this control is to ensure that critical systems remain\
        \ protected and do not become exposed or vulnerable if a firewall, proxy,\
        \ or other boundary protection device fails.\n\nIn OT environments, where\
        \ availability and safety are paramount, systems should be designed to fail\
        \ securely, for example, by defaulting to a deny-all state, isolating affected\
        \ segments, or triggering alerts, so that a failure in one component does\
        \ not compromise the entire system or allow unauthorised access.\n\nTo achieve\
        \ this goal, the following should be considered:\n\xB7 Fail-Secure Configuration\n\
        \    Devices should be configured to default to a secure state (e.g. deny\
        \ all traffic) in the event of failure, preventing unauthorised access or\
        \ data leakage.\n\xB7 Redundancy and High Availability\n    Redundant systems\
        \ or failover mechanisms should be in place to ensure continuous protection.\
        \ Avoid single points of failure, especially in OT environments where uptime\
        \ is critical.\n\xB7 Regular Testing and Maintenance\n    Failover mechanisms\
        \ and secure failure configurations should be tested regularly. Maintenance\
        \ should ensure devices remain in a secure and functional state.\n\xB7 Access\
        \ Control Integrity\n    Access Control Lists (ACLs) and security policies\
        \ should remain protected and unaltered during failures to preserve the system\u2019\
        s security posture.\n\xB7 Monitoring and Alerts\n    Real-time monitoring\
        \ and alerting should be implemented to detect failures promptly and initiate\
        \ corrective actions.\n\xB7 Segmentation and Isolation\n    Network design\
        \ should include segmentation and isolation to limit the impact of a failure\
        \ and prevent cascading effects across systems.\n\nThese practices align with\
        \ recognised standards, including NIST SP 800-53 Rev. 5, NIST SP 800-53A,\
        \ and IEC 62443-3-3 SR 5.2 RE 3 \u2013 Fail Close, which emphasise secure\
        \ failure and resilience in critical infrastructure systems."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.7
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.7
      description: The organisation shall ensure that development and test environments
        are strictly separated from the production environment, particularly in ICS/OT
        systems where any crossover could compromise safety, endanger health, or disrupt
        essential operations.
      annotation: "The goal of this control is to prevent unintended disruptions,\
        \ safety risks, or security breaches by ensuring that development and testing\
        \ activities do not interfere with live operational systems.\n\nIn OT environments,\
        \ such as Industrial Control Systems (ICS), even minor crossovers between\
        \ test and production can lead to unsafe conditions, process interruptions,\
        \ or exposure of sensitive configurations. Strict separation helps maintain\
        \ system integrity, supports change control, and reduces the risk of accidental\
        \ or malicious actions affecting critical operations.\n\nTo achieve this goal,\
        \ the following should be considered:\n\xB7 Strict Environment Separation\n\
        \    Development and testing activities should be conducted in environments\
        \ that are physically or logically separated from the production environment.\
        \ This is especially critical in ICS/OT settings, where operational safety\
        \ and reliability must not be compromised.\n\xB7 Pre-Deployment Testing\n\
        \    Any change intended for the ICT or OT environment should first be tested\
        \ in a non-production environment. This allows for the evaluation of potential\
        \ impacts and necessary adjustments before deployment.\n\xB7 Realistic Test\
        \ Environments\n    Test environments should closely replicate the production\
        \ environment in terms of configuration, architecture, and data flow, to ensure\
        \ accurate testing outcomes.\n\xB7 Secure Development Practices\n    Cybersecurity\
        \ features should be integrated and tested as early as possible in the development\
        \ lifecycle, following secure development lifecycle (SDLC) principles."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.8
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.8
      description: The organisation shall define, monitor, and control the flow of
        information and data within and between its critical systems to ensure that
        only authorised and secure exchanges occur, regardless of network boundaries
        or system architecture.
      annotation: "This requirement builds on PR.IR-01.3 (control of system connections)\
        \ and PR.IR-01.4 (boundary protection), but goes further by focusing on what\
        \ data is allowed to move, where, and under what conditions \u2014 not just\
        \ how systems are connected or segmented.\n\nIt also complements ID.AM-03.2,\
        \ which requires that network communication and internal data flows be mapped,\
        \ documented, authorised, and updated. PR.IR-01.8 ensures that these documented\
        \ flows are also actively enforced and monitored.\n\nControlling information\
        \ and data flows is especially critical in ICS/OT environments, where any\
        \ unauthorised or unintended exchange of data can compromise health, safety,\
        \ and environmental protection, and must therefore be strictly governed.\n\
        \nTo implement this requirement effectively, the organisation should:\n\xB7\
        \ Define and Enforce Flow Control Policies\n    Tools and policies should\
        \ be used to control how data moves between systems and within different parts\
        \ of the network, ensuring only authorised flows occur.\n\xB7 Encrypt Data-in-Transit\
        \ and at-Rest\n    Use secure encryption protocols such as TLS/SSL for data\
        \ in transit and AES-256 for data at rest to protect confidentiality and integrity.\n\
        \xB7 Use Multi-Factor Authentication (MFA)\n    MFA should be implemented\
        \ to verify the identity of users accessing systems that handle or transmit\
        \ sensitive data.\n\xB7 Secure APIs\n    APIs used for inter-system communication\
        \ should follow secure development practices and be regularly reviewed for\
        \ vulnerabilities.\n\xB7 Implement Continuous Monitoring\n    Real-time monitoring\
        \ tools should detect unauthorised data flows or anomalies, with alerts for\
        \ immediate response.\n\xB7 Conduct Periodic Audits\n    Regular audits should\
        \ verify compliance with data flow policies and identify potential weaknesses\
        \ or unauthorised changes.\n\xB7 Apply Network Segmentation\n    Segment the\
        \ network to restrict unnecessary data flows and limit the impact of potential\
        \ breaches.\n\xB7 Secure Remote Access\n    VPNs should be used to securely\
        \ connect remote systems and users to the organisation\u2019s network.\n\xB7\
        \ Deploy Data Loss Prevention (DLP)\n    DLP solutions should monitor and\
        \ control the transfer of sensitive information, especially when leaving the\
        \ organisation.\n\xB7 Train Staff and Raise Awareness\n    Employees should\
        \ be trained on data handling policies and the importance of controlling information\
        \ flows.\n\xB7 Simulate Phishing Attacks\n    Regular phishing simulations\
        \ should be conducted to reduce the risk of social engineering attacks."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01.9
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-01
      ref_id: PR.IR-01.9
      description: The organisation shall manage interfaces with external telecommunications
        services as part of its broader network security policy, by defining how traffic
        is controlled, ensuring the confidentiality and integrity of transmitted information,
        and reviewing and documenting any exceptions to established rules.
      annotation: "This control builds on PR.IR-01.8 by focusing specifically on how\
        \ external communications are governed within the organisation\u2019s network\
        \ security policy. While firewall configurations and baseline security settings\
        \ provide technical enforcement, this requirement emphasises the policy and\
        \ oversight layer.\n\nTo implement this effectively, the organisation should:\n\
        \xB7 Integrate Traffic Flow Management into the Network Security Policy\n\
        \    The network security policy should include clear rules for how data and\
        \ voice traffic is allowed to flow between internal systems and external telecommunications\
        \ services.\n\xB7 Define Security Objectives and Scope\n    The policy should\
        \ outline the goals for protecting external communications and specify which\
        \ systems and services are covered.\n\xB7 Control and Monitor Traffic\n  \
        \  Network traffic should be continuously monitored to ensure it complies\
        \ with defined rules. Suspicious or unauthorised flows should trigger alerts\
        \ and be investigated.\n\xB7 Protect Data in Transit\n    Confidentiality\
        \ and integrity of transmitted data should be protected using encryption protocols\
        \ such as TLS/SSL.\n\xB7 Document and Review Exceptions\n    Any exceptions\
        \ to the traffic flow rules (e.g., temporary access for a third party) should\
        \ be formally documented, justified, and regularly reviewed.\n\xB7 Respond\
        \ to Incidents\n    The organisation should be prepared to isolate and respond\
        \ to abnormal or malicious traffic patterns quickly.\n\xB7 Maintain Policy\
        \ Alignment\n    The traffic flow component should align with other elements\
        \ of the network security policy, including access control, VPN usage, patch\
        \ management, and incident response."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir
      ref_id: PR.IR-02
      description: The organisation's technology assets are protected from environmental
        threats.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-02
      ref_id: PR.IR-02.1
      description: The organisation shall define, implement and maintain policies
        and procedures related to emergency and safety systems, fire protection systems
        and environmental controls for its critical systems.
      annotation: "The goal of this control is to protect critical systems from environmental\
        \ hazards and emergencies that could disrupt operations, damage equipment,\
        \ or endanger safety \u2014 especially in OT environments where physical conditions\
        \ directly impact system availability and human safety.\n\nTo achieve this\
        \ goal, the organisation should:\n\xB7 Conduct risk assessments of all locations\
        \ housing critical systems to identify environmental and emergency risks.\n\
        \xB7 Define policies and procedures for fire protection, emergency response,\
        \ and environmental controls.\n\xB7 Install monitoring systems such as temperature,\
        \ humidity, smoke, and water leak sensors, with alerts for abnormal conditions.\n\
        \xB7 Implement fire protection measures including appropriate suppression\
        \ systems (e.g. gas-based for data centres), alarms, detectors, and extinguishers.\n\
        \xB7 Inspect and maintain fire safety and environmental systems regularly,\
        \ including HVAC and emergency lighting.\n\xB7 Include environmental protection\
        \ requirements in third-party contracts, and request evidence of compliance\
        \ and maintenance.\n\xB7 Train staff on emergency procedures and conduct evacuation\
        \ and fire response drills at least annually."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-02
      ref_id: PR.IR-02.2
      description: The organisation shall implement fire detection devices that activate
        and notify key personnel automatically in the event of a fire.
      annotation: "The goal of this control is to ensure that fire incidents are detected\
        \ early and that key personnel are automatically alerted, to enable a rapid\
        \ and coordinated response \u2014 especially in environments where critical\
        \ systems support safety or essential operations.\n\nTo achieve this goal,\
        \ the organisation should:\n\xB7 Deploy automated fire detection systems using\
        \ smoke and heat detectors that activate without manual intervention.\n\xB7\
        \ Integrate fire detection with automatic suppression systems where appropriate\
        \ (e.g. sprinklers or gas-based systems).\n\xB7 Configure systems to automatically\
        \ notify designated personnel or emergency responders upon activation.\n\xB7\
        \ Define and maintain a notification list with clearly assigned roles, ensuring\
        \ that individuals have the necessary access and clearance \u2014 particularly\
        \ in sensitive or classified environments."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir
      ref_id: PR.IR-03
      description: Mechanisms are implemented to achieve resilience requirements in
        normal and adverse situations
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-03
      ref_id: PR.IR-03.1
      description: The organisation shall implement mechanisms to ensure that critical
        systems and services remain operational or can be quickly restored during
        both normal operations and adverse conditions.
      annotation: "The goal of this control is to ensure that critical systems and\
        \ services remain operational, or can be quickly restored, during both normal\
        \ operations and adverse conditions such as cyber-attacks, hardware failures,\
        \ or natural disasters.\n\nThis control supports the broader objective of\
        \ operational resilience. While redundancy (as addressed in GV.OC-04.3) helps\
        \ prevent outages by duplicating components, resilience ensures that operations\
        \ can continue or recover quickly even when failures do occur. Both are essential\
        \ for maintaining availability in complex IT and OT environments.\n\nTo achieve\
        \ this goal, the organisation should:\n\xB7 Define Resilience Objectives\n\
        \    \xB7 Identify critical systems and define acceptable Recovery Time Objectives\
        \ (RTO) and Recovery Point Objec- tives (RPO).\n    \xB7 Align resilience\
        \ goals with business continuity and disaster recovery plans.\n\xB7 Design\
        \ for Resilience\n    \xB7 Implement fault-tolerant architectures (e.g. clustering,\
        \ load balancing, geo-redundancy).\n    \xB7 Use diverse technologies and\
        \ suppliers to reduce dependency on single points of failure.\n\xB7 Ensure\
        \ Operational Readiness\n    \xB7 Test failover systems regularly through\
        \ simulations and switchovers.\n    \xB7 Keep operational procedures and recovery\
        \ instructions current and accurate.\n\xB7 Enhance Cyber Resilience\n    \xB7\
        \ Integrate resilience strategies into incident response plans (e.g. ransomware\
        \ containment, data restoration).\n    \xB7 Use immutable backups and network\
        \ segmentation to limit the impact of cyber incidents.\n\xB7 Assess Third-Party\
        \ Resilience\n    \xB7 Evaluate the resilience of critical service providers\
        \ and document findings.\n    \xB7 Include resilience and recovery requirements\
        \ in service-level agreements (SLAs).\n\xB7 Promote Continuous Improvement\n\
        \    \xB7 Review and update resilience mechanisms after incidents or major\
        \ changes.\n    \xB7 Incorporate lessons learned into future planning and\
        \ testing."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir
      ref_id: PR.IR-04
      description: Adequate resource capacity to ensure availability is maintained.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:pr.ir-04
      ref_id: PR.IR-04.1
      description: Adequate resource capacity planning shall ensure that availability
        of organisation's critical system information processing, networking, telecommunications,
        and data storage is maintained.
      annotation: "The goal of this control is to ensure that critical systems have\
        \ enough computing, storage, and network resources available at all times\
        \ by planning ahead for current and future capacity needs.\n\nTo achieve this\
        \ goal, the organisation should:\n\xB7 Forecast and Plan\n    Resource needs\
        \ should be regularly forecasted based on business growth, seasonal patterns,\
        \ and usage trends. Future demand for compute, storage, and network capacity\
        \ should be anticipated to prevent performance issues or outages.\n\xB7 Account\
        \ for Procurement Lead Times\n    Capacity planning should consider potential\
        \ delays in hardware or service delivery due to supply chain or geopolitical\
        \ disruptions. Buffer capacity should be maintained to absorb unexpected demand\
        \ or expansion delays.\n\xB7 Monitor and Set Thresholds\n    Systems should\
        \ be continuously monitored to track usage. Thresholds and alerts should be\
        \ configured to trigger timely scaling actions before performance is impacted.\n\
        \xB7 Use High-Availability Components\n    Redundant components (e.g. RAID\
        \ arrays, dual network interfaces, backup power) should be deployed to reduce\
        \ downtime from hardware failures. These should complement, not replace, capacity\
        \ planning.\n\xB7 Review and Adjust Regularly\n    Capacity plans should be\
        \ reviewed periodically and updated based on changes in business strategy,\
        \ technology, or external risk factors."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de
      assessable: false
      depth: 1
      ref_id: DE
      name: DETECT
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de
      ref_id: DE.CM
      name: Continuous Monitoring
      description: Assets are monitored to find anomalies, indicators of compromise,
        and other potentially adverse events.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm
      ref_id: DE.CM-01
      description: Networks and network services are monitored to find potentially
        adverse events.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01
      ref_id: DE.CM-01.1
      description: Firewalls shall be installed and operated at the network boundaries,
        including endpoint firewalls.
      annotation: "The goal of this control is to enhance visibility and detection\
        \ of threats at the device level, particularly those that may bypass traditional\
        \ network perimeter defences.\n\nThis control focuses on the use of host-based\
        \ firewalls to detect threats that may bypass the network perimeter, by monitoring\
        \ and controlling traffic to and from individual devices (focus: visibility\
        \ and detection). In contrast, control PR.IR-01.1 addresses network-based\
        \ firewalls, which are designed to prevent unauthorised access by managing\
        \ traffic entering or leaving the network (focus: control and prevention).\n\
        \nTo achieve this goal, the following should be considered:\n\xB7 Define Endpoints\
        \ Broadly: Include desktops, laptops, servers, smartphones, and where feasible,\
        \ OT (Operational Technology) components like PLCs and HMIs, as well as IoT\
        \ devices.\n\xB7 Deploy Host-Based Firewalls: Ensure firewalls are installed,\
        \ active, and properly configured on all endpoint devices. These firewalls\
        \ help detect and block suspicious activity directly on the device, even when\
        \ it is connected to secure networks or VPNs.\n\xB7 Segment Network Assets:\
        \ Group systems based on their criticality or function (e.g. put public-facing\
        \ services like email, web, and VPN servers in a DMZ).\n\xB7 Use Predefined\
        \ Firewall Rules: Establish rules to filter both inbound and outbound traffic,\
        \ thereby helping to detect anomalies or malicious behaviour.\n\xB7 Limit\
        \ Internet Gateways: Reduce the number of interconnection points to the internet\
        \ to minimise exposure and simplify monitoring."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01
      ref_id: DE.CM-01.2
      description: Anti-virus, -spyware, and other -malware programs shall be installed
        and updated.
      annotation: "The goal of this control is to ensure that all organisational devices\
        \ (IT and OT assets) are protected against malicious software, by deploying\
        \ and regularly updating anti-malware tools.\n\nTo achieve this goal, consider\
        \ the following:\n\xB7 Scope of Protection\n    \xB7 IT Devices: Install anti-malware\
        \ software on all user and system devices, including desktops, laptops, servers,\
        \ smartphones, and tablets.\n    \xB7 OT Devices: Extend protection to OT\
        \ assets such as PLCs, HMIs, SCADA servers, and engineering workstations,\
        \ where technically feasible.\n\xB7 Update and Scanning Practices\n    \xB7\
        \ IT: Configure anti-malware tools to update in real-time or at least daily,\
        \ followed by automated or scheduled scans.\n    \xB7 OT: Carefully plan updates\
        \ and scans to avoid operational disruption. Use maintenance windows and test\
        \ updates before deployment.\n\xB7 Tailored Solutions for OT\n    \xB7 Use\
        \ lightweight or OT-specific anti-malware tools that are compatible with real-time\
        \ systems.\n    \xB7 For legacy or resource-constrained OT devices, consider:\n\
        \        \xB7 Application whitelisting\n        \xB7 Network-based malware\
        \ detection\n        \xB7 Use specialised tools that quietly monitor industrial\
        \ systems to spot unusual or suspicious activity, without interfering with\
        \ how the systems operate (passive monitoring).\n\xB7 Remote Work and BYOD\n\
        \    Apply the same protection standards to:\n    \xB7 Home computers used\
        \ for teleworking\n    \xB7 Personal devices (BYOD) used for professional\
        \ tasks\n    \xB7 Use endpoint protection platforms to enforce policies across\
        \ all devices.\n\xB7 Centralised Management and Monitoring\n    \xB7 Use Centralised\
        \ tools to manage anti-malware configurations, updates, and alerts across\
        \ both IT and OT environments.\n    \xB7 Integrate malware alerts into the\
        \ organisation\u2019s broader security monitoring and incident response processes.\n\
        \xB7 Continuous Improvement\n    \xB7 Regularly review and test anti-malware\
        \ effectiveness.\n    \xB7 Update policies and tools based on emerging threats\
        \ and lessons learned from incidents."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01
      ref_id: DE.CM-01.3
      description: The organisation shall monitor and identify unauthorised use of
        its business-critical systems through the detection of unauthorised local
        connections, network connections and remote connections.
      annotation: "The goal of this control is to ensure that the organisation can\
        \ detect and respond to unauthorised access or misuse of its business-critical\
        \ systems. This includes identifying suspicious local, network, or remote\
        \ connections that could indicate a security breach or misuse of sensitive\
        \ systems.\n\nTo achieve this goal, consider the following:\n\xB7 Monitoring\
        \ of network communications should happen at the external boundary of the\
        \ organisation's business critical systems and at key internal boundaries\
        \ within those systems.\n\xB7 Facilities should be monitored for unauthorised\
        \ or rogue wireless networks that could allow attackers to bypass normal controls.\n\
        \xB7 Critical network services such as Domain Name System (DNS \u2013 which\
        \ translates website names to IP addresses), Border Gateway Protocol (BGP\
        \ \u2013 which helps route internet traffic), and other network services should\
        \ be monitored for signs of tampering or misuse.\n\xB7 When hosting applications\
        \ that are accessible from the internet, a Web Application Firewall (WAF)\
        \ should be considered to protect against attacks. If the application is not\
        \ web-based, it should be protected using other appropriate methods, such\
        \ as an Identity Provider (IdP) to control access."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-01
      ref_id: DE.CM-01.4
      description: The organisation shall continuously monitor its network to spot
        signs of cyber threats or unusual activity, using clearly defined rules for
        what counts as a potential security incident.
      annotation: "The aim of this control is to ensure that the organisation continuously\
        \ monitors its network and systems to detect signs of cyber threats or unusual\
        \ activity. This is done using clearly defined rules that help identify what\
        \ qualifies as a potential security incident.\n\nTo achieve this, consider\
        \ the following:\n\xB7 This control builds on DE.AE-08.1, which requires that\
        \ incidents have to be reported based on predefined criteria.\n\xB7 The organisation\
        \ should decide which types of cybersecurity events and warning signs need\
        \ to be monitored, and define what information must be recorded in audit logs.\n\
        \xB7 Automated tools should be used to detect suspicious activity, such as\
        \ unexpected network traffic, failed login attempts, or incorrect system settings.\n\
        \xB7 Monitoring should be flexible and increase during high-risk periods,\
        \ such as when threat alerts are received, during geopolitical tensions, or\
        \ after internal issues.\n\xB7 Monitoring should include not only digital\
        \ systems but also physical spaces, staff behaviour, and interactions with\
        \ service providers, where relevant.\n\xB7 Network activity should be continuously\
        \ analysed to detect changes that might indicate weakened security, following\
        \ zero-trust principles.\n\xB7 Alerts should be triggered automatically when\
        \ certain thresholds are met, and known false alarms should be filtered out\
        \ to avoid overwhelming staff."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm
      ref_id: DE.CM-02
      description: The physical environment is monitored to find potentially adverse
        events.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-02
      ref_id: DE.CM-02.1
      description: The physical environment shall be monitored to find potentially
        adverse events.
      annotation: "The purpose of this control is to ensure that the physical spaces\
        \ where critical systems and data are located are monitored for signs of suspicious\
        \ or harmful activity. This helps detect potential threats such as unauthorised\
        \ access, tampering, or other unusual events in the physical environment.\n\
        \nTo achieve this purpose, consider the following:\n\xB7 Logs from physical\
        \ access systems (such as badge readers) should be reviewed to detect unusual\
        \ patterns, like someone trying to enter at odd hours or repeated failed attempts\
        \ to access a restricted area.\n\xB7 Records of visitor access (such as sign-in\
        \ sheets or digital check-ins) should be regularly reviewed to ensure that\
        \ only authorised individuals have entered secure areas.\n\xB7 Physical security\
        \ equipment (such as locks, door latches, hinge pins, and alarms) should be\
        \ checked for signs of tampering or damage that could indicate an attempted\
        \ breach."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-02
      ref_id: DE.CM-02.2
      description: Physical access to the organisation's critical systems and devices,
        in addition to physical access monitoring to the facility, shall be supplemented
        by physical intrusion alarms, surveillance equipment, and independent monitoring
        teams.
      annotation: "The purpose of this control is to strengthen the protection of\
        \ critical systems and devices by supplementing basic physical access monitoring\
        \ with active intrusion detection, surveillance technologies, and independent\
        \ monitoring capabilities. This helps ensure timely detection and response\
        \ to physical security threats.\n\nTo achieve this purpose, consider the following:\n\
        \xB7 Intrusion detection systems should be deployed to identify unauthorised\
        \ physical entry attempts. These systems may include motion sensors, door/window\
        \ contact sensors, and glass break detectors, which trigger alerts when unusual\
        \ activity is detected.\n\xB7 Surveillance technologies such as CCTV cameras,\
        \ video recording systems, and access control systems should be used to continuously\
        \ monitor and record activity in sensitive areas. These systems help verify\
        \ incidents and support investigations.\n\xB7 Visitor tracking should be enhanced\
        \ by logging all entries, including contractors and temporary personnel, using\
        \ digital systems or manual logs.\n\xB7 Independent monitoring teams, typically\
        \ external security professionals, should be engaged to oversee surveillance\
        \ systems and respond to incidents. These teams bring specialised expertise\
        \ and operate separately from internal staff, making it important to apply\
        \ third-party cybersecurity requirements to their operations.\n\xB7 Surveillance\
        \ and intrusion detection should be integrated with broader security operations,\
        \ allowing alerts to be correlated with other physical and digital indicators\
        \ of compromise."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm
      ref_id: DE.CM-03
      description: Personnel activity and technology usage are monitored to find potentially
        adverse events.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-03-1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-03
      ref_id: DE.CM-03-1
      description: End point and network protection tools to monitor end-user behaviour
        for dangerous activity shall be implemented.
      annotation: "The goal of this control is to ensure that the organisation can\
        \ detect and respond to risky or suspicious behaviour by users on both devices\
        \ and networks. This helps identify threats such as malware infections, misuse\
        \ of systems, or attempts to bypass security controls \u2014 whether caused\
        \ by external attackers or insiders.\n\nTo achieve this goal, the following\
        \ should be considered:\n\xB7 Organisations should consider using a combination\
        \ of modern security tools that work together to provide a full picture of\
        \ user and system activity:\n\xB7 Intrusion Detection and Prevention Systems\
        \ (IDPS): These tools monitor network traffic and can block or alert on suspicious\
        \ activity, such as hacking attempts or exploitation of vulnerabilities.\n\
        \xB7 Web Application Firewalls (WAFs) and API Gateways: These help protect\
        \ online applications and services by filtering harmful traffic and preventing\
        \ unauthorised access.\n\xB7 In addition, a layered approach using advanced\
        \ detection and response tools can provide real-time visibility and faster\
        \ response:\n\xB7 Endpoint Detection and Response (EDR): Monitors activity\
        \ on individual devices (like laptops or servers) to detect threats such as\
        \ malware or unauthorised access.\n\xB7 Network Detection and Response (NDR):\
        \ Analyses network traffic to identify unusual patterns, such as lateral movement\
        \ or hidden attacks.\n\xB7 Identity Threat Detection and Response (ITDR):\
        \ Focuses on detecting misuse of user accounts, such as stolen credentials\
        \ or insider threats.\n\xB7 User and Entity Behaviour Analytics (UEBA): Uses\
        \ machine learning to understand normal behaviour and detect anomalies that\
        \ may indicate a threat.\n\xB7 These tools are part of a modern, layered security\
        \ strategy and are often referenced in industry best practices and frameworks\
        \ such as the Security Operations Centre (SOC) Visibility Triad introduced\
        \ by Gartner."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-03-2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-03
      ref_id: DE.CM-03-2
      description: End point and network protection tools that monitor end-user behaviour
        for dangerous activity shall be managed.
      annotation: "This control builds on DE.CM-03.1 by shifting the focus from implementation\
        \ to ongoing management of monitoring tools. The goal of this control is to\
        \ ensure that tools used to monitor user behaviour and detect harmful activity\
        \ on devices and networks are properly maintained and actively managed. This\
        \ supports the continued effectiveness of the tools as threats evolve, and\
        \ ensures that the alerts they produce are accurate, relevant, and helpful\
        \ for identifying real security risks.\n\nTo achieve this goal, consider the\
        \ following:\n\xB7 Tools that monitor devices such as laptops, mobile phones,\
        \ and servers should be regularly checked to confirm they are working properly,\
        \ updated with the latest threat information, and able to detect new types\
        \ of attacks.\n\xB7 A central system should be used to collect and analyse\
        \ logs from different sources. These logs should be complete, up to date,\
        \ and useful for identifying suspicious activity.\n\xB7 Logs related to system\
        \ access, such as login attempts or access outside normal hours, should be\
        \ reviewed regularly. Alerts should be set up to notify security teams of\
        \ unusual patterns.\n\xB7 Tools that analyse user behaviour should be fine-tuned\
        \ over time. Security teams should review alerts, adjust detection rules to\
        \ reduce false alarms, and improve accuracy.\n\xB7 Deception tools, such as\
        \ fake systems or files designed to attract attackers, should be monitored\
        \ closely. Alerts from these tools are often early signs of a real attack\
        \ and should be treated as high priority.\n\xB7 Security teams should regularly\
        \ assess how well all monitoring tools are performing, update detection rules,\
        \ and ensure the tools are integrated with incident response processes.\n\xB7\
        \ Roles and responsibilities for monitoring and responding to alerts should\
        \ be clearly defined. Staff should be trained to use the tools effectively\
        \ and respond appropriately to incidents."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm
      ref_id: DE.CM-06
      description: External service provider activities and services are monitored
        to find potentially adverse events.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-06
      ref_id: DE.CM-06.1
      description: External service provider activities and services shall be secured
        and monitored to find potentially adverse events.
      annotation: "The goal of this control is to ensure that activities performed\
        \ by external service providers, whether remote or onsite, are securely managed\
        \ and continuously monitored. This helps detect any unusual or harmful actions\
        \ that could affect the organisation\u2019s systems, data, or services.\n\n\
        The achieve this goal, the following should be considered:\n\xB7 External\
        \ providers may include contractors, cloud service vendors, IT support teams,\
        \ software developers, and other third parties involved in system maintenance,\
        \ development, or security.\n\xB7 Monitoring should focus on:\n\xB7 Access\
        \ and login activity, including how and when external users connect to systems.\n\
        \xB7 Data transfers and network traffic, to detect unusual or unauthorised\
        \ movement of information.\n\xB7 System changes, such as software updates\
        \ or configuration adjustments made by external parties.\n\xB7 All remote\
        \ and onsite activities by external providers should be logged and reviewed\
        \ to identify unauthorised actions or risky behaviour.\n\xB7 Cloud services\
        \ and internet providers should be monitored for unexpected behaviour or performance\
        \ issues that could indicate a security problem.\n\xB7 A centralised logging\
        \ system should be used to collect and analyse data from all external services.\n\
        \xB7 Any security incidents involving external providers \u2014 such as malware\
        \ infections, phishing attempts, or unauthorised access \u2014 should be detected\
        \ early, reported quickly, and addressed effectively."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-06.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-06
      ref_id: DE.CM-06.2
      description: External service providers' conformance with personnel security
        policies and procedures and contract security requirements shall be monitored
        relative to their cybersecurity risks.
      annotation: "The goal of this control is to ensure that external service providers\
        \ follow the organisation\u2019s personnel security policies and contract\
        \ requirements, especially when they have access to sensitive systems or data.\
        \ This helps reduce the risk of security incidents caused by third-party staff\
        \ and ensures that providers are held to the same standards as internal personnel.\n\
        \nTo achieve this goal, consider the following:\n\xB7 External providers should\
        \ have clearly defined security responsibilities, which are documented in\
        \ contracts or service-level agreements.\n\xB7 Contracts should include requirements\
        \ such as:\n    \xB7 Background checks for provider personnel\n    \xB7 Signing\
        \ of confidentiality agreements\n    \xB7 Adherence to acceptable use policies\n\
        \xB7 Compliance with these requirements should be monitored regularly, including\
        \ checks for completed security training and signed agreements.\n\xB7 Providers\
        \ should be required to notify the organisation immediately when staff with\
        \ system access are transferred or leave their role, so access rights can\
        \ be revoked without delay.\n\xB7 Periodic audits should be conducted to confirm\
        \ that providers are following security policies. These may include:\n   \
        \ \xB7 Reviewing access logs and permissions\n    \xB7 Verifying onboarding\
        \ and offboarding procedures\n    \xB7 Ensuring only authorised individuals\
        \ have access to critical systems\n\xB7 Any issues or non-compliance should\
        \ be documented, reported, and addressed through corrective actions and follow-up\
        \ reviews."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm
      ref_id: DE.CM-09
      description: Computing hardware and software, runtime environments, and their
        data are monitored to find potentially adverse events.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09
      ref_id: DE.CM-09.1
      description: The organisation shall monitor computing hardware, software, runtime
        environments, and their data to detect potentially adverse events.
      annotation: "This control aims to ensure that organisations continuously monitor\
        \ their computing systems and data to detect potentially harmful events early.\
        \ This helps maintain visibility, support timely responses, and reduce the\
        \ risk of security incidents.\n\nTo achieve the goal of this control, the\
        \ organisation should consider the following:\n\xB7 Turn on system logging\
        \ on computers and servers to record important events.\n\xB7 Use built-in\
        \ antivirus or endpoint protection to detect threats and generate alerts.\n\
        \xB7 Regularly review logs and alerts to spot unusual activity or errors.\n\
        \xB7 Store logs in a shared folder or simple log viewer to make them easier\
        \ to access and review.\n\xB7 Set a routine (e.g. weekly or monthly) to check\
        \ logs and update monitoring tools.\n\xB7 Assign someone responsible for monitoring,\
        \ even if it is a part-time role."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09
      ref_id: DE.CM-09.2
      description: "The organisation shall implement hardware integrity checks to\
        \ detect unauthorised tampering of critical system hardware. Controls shall\
        \ be proportionate to the organisation\u2019s risk profile and operational\
        \ capacity."
      annotation: "The goal of this control is to ensure that critical hardware components\
        \ are protected against unauthorised tampering. By implementing integrity\
        \ checks that match the organisation\u2019s risk level and operational capacity,\
        \ it becomes possible to detect physical or firmware-level changes that could\
        \ compromise security.\n\nConsider the following elements to achieve this\
        \ goal:\n\xB7 Define What Needs Protection\n    Identify which systems are\
        \ most critical, such as servers handling sensitive data, industrial control\
        \ systems (ICS/SCADA), or cryptographic devices, and prioritise them based\
        \ on business impact, legal requirements, and exposure to threats.\n\xB7 Choose\
        \ the Right Level of Protection\n    Select controls based on how critical\
        \ the system is and what the organisation can support:\n    \xB7 Basic controls:\
        \ Locked server rooms, tamper-evident seals, secure boot, and regular hardware\
        \ audits.\n    \xB7 Intermediate controls: Alerts when hardware is opened,\
        \ use of Trusted Platform Modules (TPMs), and firmware validation tools.\n\
        \    \xB7 Advanced controls: Remote validation of hardware state, tamper-resistant\
        \ cryptographic hardware (HSMs), and monitoring for hardware-level anomalies\
        \ using security tools.\n\xB7 Connect to Security Operations\n    Feed alerts\
        \ from hardware integrity tools into central monitoring systems (like a SIEM\
        \ or SOC) for real-time visibility. Define how to respond if tampering is\
        \ suspected.\n\xB7 Assign Clear Responsibilities\n    Designate roles for\
        \ designing, implementing, and responding to hardware integrity issues. Use\
        \ role profiles (e.g. from ENISA ECSF) to guide responsibilities:\n    \xB7\
        \ Security architects design the controls.\n    \xB7 System administrators\
        \ implement and monitor them.\n    \xB7 Incident responders investigate alerts.\n\
        \xB7 Document and Review\n    Include hardware integrity checks in security\
        \ policies, risk assessments, and audit logs. Review their effectiveness at\
        \ least once a year or after major changes or incidents.\n\xB7 Train Staff\
        \ and Raise Awareness\n    Train relevant personnel to recognise signs of\
        \ tampering, use integrity tools correctly, and follow reporting procedures."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09
      ref_id: DE.CM-09.3
      description: The organisation's incident response plan shall include measures
        to detect unauthorised tampering with the hardware of critical systems.
      annotation: "The goal of this control is to ensure that the organisation\u2019\
        s incident response plan includes steps to detect and respond to unauthorised\
        \ tampering of critical hardware. This helps the organisation react quickly\
        \ and effectively if someone tries to physically or digitally compromise important\
        \ systems. This control can be implemented in a practical and scalable manner.\n\
        \nBy considering the below measures, also small organisations can effectively\
        \ include hardware tampering detection in their incident response capabilities,\
        \ without requiring extensive resources:\n\xB7 Incident Response Plan\n  \
        \  The incident response plan should include clear instructions for what steps\
        \ to take if hardware tampering is suspected.\n\xB7 Regular Inspections\n\
        \    Have IT and OT staff or designated personnel regularly inspect critical\
        \ hardware for signs of tampering, such as broken seals, loose cables, or\
        \ unexpected changes.\n\xB7 Monitoring Tools\n    Simple tools can be used\
        \ to send alerts when something unusual happens to a device, such as the case\
        \ being opened, a new USB device being connected, or the system restarting\
        \ unexpectedly. Many of these tools are designed to be affordable and easy\
        \ to use, especially for small organisations.\n\xB7 Training and Awareness\n\
        \    Train employees to recognise signs of hardware tampering and report any\
        \ suspicious activity. Awareness is key to early detection.\n\xB7 Vendor Support\n\
        \    Use tools or services offered by hardware vendors to help detect tampering,\
        \ often included with support contracts."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09.4
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.cm-09
      ref_id: DE.CM-09.4
      description: The organisation shall establish a system to accurately distinguish
        between legitimate alerts and false positives, ensuring effective detection
        and removal of malicious code.
      annotation: "The goal of this control is to ensure that the organisation can\
        \ accurately identify real threats while avoiding unnecessary alerts caused\
        \ by false positives. This helps improve the effectiveness of detecting and\
        \ removing malicious code, while reducing wasted time and resources responding\
        \ to harmless activity.\n\nTo help detect and remove malicious code effectively\
        \ while avoiding false alarms, the following practices should be considered:\n\
        \xB7 Automatic Updates\n    Malicious code protection tools should be configured\
        \ to update automatically where possible, or manually according to a defined\
        \ schedule, in line with organisational policies and operational constraints.\n\
        \xB7 Secure Development Practices\n    Software used in IT and OT systems\
        \ should follow secure development practices, including code reviews and vulnerability\
        \ checks, to reduce the risk of introducing malicious code.\n\xB7 Layered\
        \ Protection\n    Both signature-based protection (which detects known threats)\
        \ and behaviour-based protection (which looks for unusual or suspicious activity)\
        \ should be used in places where networks connect to the internet, where staff\
        \ access control systems, and where files or data are shared between systems.\n\
        \xB7 Scanning for Threats\n    Protection tools should be set to perform regular\
        \ scans and, where feasible, real-time checks of files and data transfers,\
        \ especially those coming from external sources or removable media.\n\xB7\
        \ Blocking and Quarantine\n    Detected malicious code should be blocked and\
        \ isolated to prevent it from affecting other systems. In OT environments,\
        \ this should be done in a way that does not disrupt critical operations.\n\
        \xB7 Alerts and Notifications\n    Alerts should be sent to designated personnel\
        \ when malicious code is detected, with clear procedures for responding in\
        \ both IT and OT contexts."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de
      ref_id: DE.AE
      name: Adverse Event Analysis
      description: Anomalies, indicators of compromise, and other potentially adverse
        events are analysed to characterize the events and detect cybersecurity incidents.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae
      ref_id: DE.AE-02
      description: Potentially adverse events are analysed to better understand associated
        activities.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-02
      ref_id: DE.AE-02.1
      description: Cybersecurity and information security events must be reviewed
        and analysed to identify potential attack targets and methods, in accordance
        with applicable laws, regulations, standards, and policies.
      annotation: "The goal of this control is to ensure that cybersecurity and information\
        \ security events are reviewed and analysed to detect attack targets and methods.\
        \ This enables organisations to respond effectively to threats while maintaining\
        \ compliance with legal, regulatory, and policy requirements.\n\nTo achieve\
        \ this goal, consider the following:\n\xB7 Organisations should follow relevant\
        \ federal and regional laws, industry regulations, standards, and internal\
        \ policies when reviewing security events.\n\xB7 Log analysis tools should\
        \ be used to generate reports and identify suspicious activity.\n\xB7 System\
        \ and application logs should be regularly reviewed to detect signs of security\
        \ threats, such as repeated failed login attempts or unusual data transfers.\n\
        \xB7 Logs should be analysed for patterns that indicate attempted or ongoing\
        \ attacks.\n\xB7 Threat intelligence should be used to stay informed about\
        \ emerging threats and attack techniques, and security measures should be\
        \ adjusted accordingly.\n\xB7 Regular audits and assessments should be conducted\
        \ to evaluate the organisation\u2019s security posture.\n\xB7 The results\
        \ of these audits should be used to improve monitoring and analysis."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-02
      ref_id: DE.AE-02.2
      description: The organisation shall implement automated mechanisms where feasible
        to review and analyse detected events.
      annotation: "The goal of this control is to ensure that the organisation uses\
        \ automation, where practical, to support the efficient and consistent review\
        \ and analysis of detected cybersecurity events. This helps reduce the risk\
        \ of human error, speeds up threat detection and response, and allows limited\
        \ security resources (especially in smaller organisations) to focus on higher-value\
        \ tasks like investigating complex incidents or improving defences.\n\nTo\
        \ achieve this goal, the following should be considered:\n\xB7 Use Built-in\
        \ Capabilities\n    Enable and configure logging and alerting features in\
        \ existing platforms (e.g. Microsoft 365, Google Workspace, firewalls) to\
        \ automatically detect suspicious activity.\n\xB7 Deploy Lightweight Detection\
        \ Tools\n    Use affordable endpoint detection and response (EDR) solutions\
        \ that offer automated alerts and basic analysis, such as detecting malware\
        \ or unusual login behaviour.\n\xB7 Consider Managed Detection Services\n\
        \    For organisations with limited internal resources, a Managed Detection\
        \ and Response (MDR) service can provide outsourced monitoring, threat detection,\
        \ and incident response.\n\xB7 Automate High-Impact Areas\n    Focus automation\
        \ on common threat indicators, such as:\n    \xB7 Multiple failed login attempts\n\
        \    \xB7 Unusual access to sensitive files\n    \xB7 Unexpected outbound\
        \ traffic\n\xB7 Integrate Threat Intelligence\n    Use free or low-cost threat\
        \ intelligence feeds to enhance detection tools with known indicators of compromise\
        \ and attacker behaviours.\n\xB7 Maintain Manual Review Practices\n    Schedule\
        \ regular manual reviews of logs and alerts to identify threats that automated\
        \ tools may miss, especially those involving new or subtle attack techniques."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae
      ref_id: DE.AE-03
      description: Information is correlated from multiple sources.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03
      ref_id: DE.AE-03.1
      description: The logging functionality of protection and detection tools shall
        be enabled. Logs shall be backed up and retained for a predefined period,
        and regularly reviewed to identify unusual or potentially harmful activity.
      annotation: "The goal of this control is to make sure security tools have logging\
        \ turned on, logs are kept for a set time, and regularly checked to spot unusual\
        \ or harmful activity. This helps to detect threats early and take action.\
        \ Examples of such tools include firewalls, antivirus software, endpoint detection,\
        \ and intrusion detection systems.\n\nTo achieve this goal, the following\
        \ should be considered:\n\xB7 Logs should be stored securely and retained\
        \ according to a defined retention schedule, based on applicable legal, regulatory,\
        \ or operational needs.\n\xB7 Event detection tools and solutions should be\
        \ configured to generate automated alerts for suspicious or harmful activity.\n\
        \xB7 A documented procedure should be in place for regularly reviewing logs\
        \ and dashboards to support timely detection and response.\n\xB7 Log reviews\
        \ should include checks for patterns such as repeated malware infections,\
        \ abnormal network traffic, or excessive access to non-business-related websites.\n\
        \xB7 If such patterns are identified, follow-up actions should be defined,\
        \ such as strengthening specific security controls, updating detection rules,\
        \ or conducting targeted awareness training."
      implementation_groups:
      - B
      - I
      - E
      - BK
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03
      ref_id: DE.AE-03.2
      description: The organisation shall ensure that event data from critical systems
        is collected and correlated using information from multiple relevant sources.
      annotation: "The goal of this control is to enable the organisation to detect\
        \ complex or distributed threats by combining and analysing event data from\
        \ different systems and sources. Correlating this data helps identify patterns\
        \ that may not be visible when systems are monitored in isolation.\n\nThe\
        \ achieve this goal, the following should be considered:\n\xB7 Relevant sources\
        \ of event data can include system logs, audit logs, network monitoring tools,\
        \ physical access records, and reports from users or administrators.\n\xB7\
        \ Log data should be sent continuously, ideally in real-time or near real-time,\
        \ to a centralised system for storage and analysis. This improves the ability\
        \ to detect patterns and respond quickly to potential issues.\n\xB7 Centralising\
        \ logs on a small number of dedicated servers or platforms, such as a SIEM,\
        \ lightweight log management tools, cloud-based logging services, or managed\
        \ detection services (often part of Managed Detection and Response, or MDR),\
        \ can support efficient analysis and correlation of events across systems.\n\
        \xB7 Cyber threat intelligence can be used to enhance event correlation by\
        \ providing context about known threats, attack methods, and indicators of\
        \ compromise.\n\xB7 Threat intelligence should be securely integrated into\
        \ detection tools and processes to support more accurate and timely identification\
        \ of threats."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-03
      ref_id: DE.AE-03.3
      description: The organisation shall combine event analysis with information
        from vulnerability scans, system performance data, monitoring of critical
        systems, and facility monitoring, where feasible.
      annotation: "The goal of this control is to strengthen the organisation\u2019\
        s ability to detect complex or hidden threats by combining event analysis\
        \ with other relevant data sources.\n\nThis broader view supports more accurate\
        \ and timely identification of suspicious activity, and the following should\
        \ be considered to achieve the goal of this control:\n\xB7 Tools that collect\
        \ and link data from different systems (such as SIEM, XDR, or SOAR) should\
        \ be used to support this integration.\n\xB7 Security issues reported by suppliers\
        \ or trusted sources should be collected quickly and reviewed for possible\
        \ risks.\n\xB7 Data from different monitoring systems should be brought together\
        \ to make it easier to detect patterns or problems.\n\xB7 The setup should\
        \ allow fast detection and response when something unusual is found."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae
      ref_id: DE.AE-04
      description: The estimated impact and scope of adverse events are understood
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-04
      ref_id: DE.AE-04.1
      description: The organisation shall assess the negative impacts of detected
        events on its operations, assets, and individuals, and shall link these impacts
        to the results of its risk assessments.
      annotation: "The goal of this control is to ensure that the organisation understands\
        \ how detected events could cause harm, and uses this understanding to guide\
        \ risk-based decisions and responses.\n\nTo achieve the goal of this control,\
        \ the following should be considered:\n\xB7 Tools that help estimate the scope\
        \ and impact of events should be used to support this assessment.\n\xB7 The\
        \ assessment should consider how problems in one part of a system could affect\
        \ other connected parts.\n\xB7 Negative impacts can include financial loss,\
        \ service disruption, damage to equipment, or harm to people.\n\xB7 Detected\
        \ events can include cyber incidents, system failures, or natural disasters.\n\
        \xB7 The severity and likelihood of these impacts should be evaluated and\
        \ compared with existing risk assessments.\n\xB7 This comparison should help\
        \ prioritise actions, allocate resources, and improve response planning."
      implementation_groups:
      - E
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae
      ref_id: DE.AE-06
      description: Information on adverse events is provided to authorised staff and
        tools
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-06
      ref_id: DE.AE-06.1
      description: Information about adverse events must be promptly delivered to
        authorised personnel and systems to enable timely detection, investigation,
        and response.
      annotation: "The goal of this control is to ensure that information about adverse\
        \ events is delivered promptly to the right people and systems, so that appropriate\
        \ action can be taken without delay. This supports faster detection, investigation,\
        \ and response to potential threats or disruptions.\n\nTo achieve the goal\
        \ of this control, consider the following:\n\xB7 Types of Adverse Events:\
        \ Include indicators such as unusual account activity, unauthorised access,\
        \ system configuration changes, physical security breaches, or malware alerts.\n\
        \xB7 Detection and Alerting: Use cybersecurity tools to detect such events\
        \ and automatically alert authorised personnel (e.g. SOC analysts, incident\
        \ responders).\n\xB7 Integration with Ticketing Systems: Alerts should be\
        \ integrated with the organisation\u2019s ticketing system.\n    Tickets should\
        \ be:\n    \xB7 Automatically generated for predefined alert types.\n    \xB7\
        \ Manually created when technical staff identify suspicious activity.\n\xB7\
        \ Access to Logs and Analysis: Authorised staff must have continuous access\
        \ to log data and analysis results to support investigations.\n\xB7 Maturity\
        \ and Effectiveness Assessment: Evaluate the control\u2019s implementation\
        \ by checking:\n    \xB7 Documentation of procedures for alert generation,\
        \ review, and escalation. This documentation should be regularly reviewed\
        \ and updated.\n    \xB7 Use of automation for standard alerts, with manual\
        \ processes as a backup.\n    \xB7 Access controls for alerts and logs, with\
        \ periodic reviews of permissions (Access to alerts and logs should be limited\
        \ to authorised personnel).\n    \xB7 Monitoring and reporting should for\
        \ example track the number of alerts, response times, and whether procedures\
        \ are followed.\n    \xB7 Training should be provided regularly to staff responsible\
        \ for handling alerts, ensuring they understand how to interpret and act on\
        \ them."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-08
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae
      ref_id: DE.AE-08
      description: Incidents are declared when adverse events meet the defined incident
        criteria.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-08.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:de.ae-08
      ref_id: DE.AE-08.1
      description: Incidents shall be reported when adverse events meet defined and
        documented incident criteria.
      annotation: "This control ensures that adverse events are identified and reported\
        \ when they meet clearly defined and documented incident criteria. It emphasises\
        \ the importance of having consistent thresholds and guidelines in place to\
        \ determine when an event qualifies as an incident, supporting timely awareness\
        \ and appropriate escalation or response.\n\nTo achieve this goal, the following\
        \ should be considered:\n\xB7 Incident criteria (rules for what qualifies\
        \ as an incident) should be clearly defined, documented, and regularly reviewed.\n\
        \xB7 These criteria should help determine when an adverse event becomes an\
        \ incident that must be reported.\n\xB7 The criteria should be based on known\
        \ patterns of normal and abnormal activity, including lessons learned from\
        \ past incidents.\n\xB7 Known false positives should be considered when setting\
        \ the criteria, to avoid unnecessary reporting.\n\xB7 When an event meets\
        \ the defined criteria, it should be treated as an incident and reported according\
        \ to the organisation\u2019s procedures.\n\xB7 Where appropriate and feasible,\
        \ systems should be configured to support this process by generating alerts\
        \ when incident criteria are met. This can help detect incidents more quickly,\
        \ especially in larger or more complex environments."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs
      assessable: false
      depth: 1
      ref_id: RS
      name: RESPOND
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs
      ref_id: RS.MA
      name: Incident Management
      description: Responses to detected cybersecurity incidents are managed.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma
      ref_id: RS.MA-01
      description: The incident response plan is executed in coordination with relevant
        third parties once an incident is declared.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-01
      ref_id: RS.MA-01.1
      description: An incident response plan, including defined roles, responsibilities,
        and authorities, shall be executed during or after a cybersecurity event affecting
        the organisation's critical systems.
      annotation: "The goal of this control is to ensure that a well-defined incident\
        \ response plan is executed during or after a cybersecurity event affecting\
        \ the organisation\u2019s critical systems, enabling timely detection, containment,\
        \ communication, and recovery.\n\nTo support this goal, the organisation should:\n\
        \xB7 Develop a Documented Response Plan\n    The plan should include predefined\
        \ instructions and procedures to detect cybersecurity incidents, respond effectively,\
        \ and support the recovery of critical systems.\n\xB7 Include Detection Capabilities\n\
        \    Detection technologies should be in place to automatically report confirmed\
        \ incidents and trigger response actions.\n\xB7 Define Roles, Responsibilities,\
        \ and Authorities\n    The plan should clearly identify:\n    \xB7 Who is\
        \ involved in the response\n    \xB7 Contact details for key personnel\n \
        \   \xB7 Who has the authority to initiate recovery\n    \xB7 Who is responsible\
        \ for external communication (e.g. regulators, partners, media)\n\xB7 Review\
        \ and Update the Plan Regularly\n    The plan should be reviewed and updated\
        \ to reflect changes in the threat landscape, organisational structure, or\
        \ lessons learned from past incidents.\n\xB7 Test the Plan Through Exercises\n\
        \    Simulations and tabletop exercises should be conducted to validate the\
        \ plan\u2019s effectiveness and identify areas for improvement.\n\xB7 Include\
        \ OT Environments\n    The plan should address incident response in OT systems,\
        \ including coordination with safety protocols, isolation of affected industrial\
        \ assets, and restoration of operational processes."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-01
      ref_id: RS.MA-01.2
      description: The organisation shall coordinate information/cybersecurity incident
        response actions with all predefined stakeholders.
      annotation: "The goal of this control is to ensure that all relevant internal\
        \ and external stakeholders work together effectively during a cybersecurity\
        \ or information incident.\n\nTo achieve this goal:\n\xB7 Incident response\
        \ actions should be coordinated with predefined stakeholders, including business\
        \ leaders, IT and OT system owners, cybersecurity teams, vendors, HR, legal,\
        \ physical security, operations, and procurement.\n\xB7 Coordination should\
        \ follow the organisation\u2019s documented incident response plans.\n\xB7\
        \ A lead person should be assigned to each incident to manage the response\
        \ and ensure clear communication.\n\xB7 If needed, additional plans, such\
        \ as business continuity or disaster recovery, should be activated to support\
        \ the response.\n\xB7 Information should be shared with the right people at\
        \ the right time, following established communication procedures.\n\xB7 Different\
        \ types of incidents should be recognised and handled accordingly:\n    \xB7\
        \ Information incidents (e.g. accidental data exposure)\n    \xB7 Cybersecurity\
        \ incidents (e.g. malware, hacking)\n    \xB7 OT incidents (e.g. disruptions\
        \ to industrial control systems)\n\xB7 OT incidents should involve specialised\
        \ OT personnel and may require different response procedures to protect safety\
        \ and operations."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma
      ref_id: RS.MA-02
      description: Incident reports are triaged and validated.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-02
      ref_id: RS.MA-02.1
      description: "Information/cybersecurity incident reports shall be triaged and\
        \ validated in accordance with the organisation\u2019s incident response procedures."
      annotation: "The goal of this control is to ensure that all reported incidents\
        \ are systematically reviewed and assessed before any further action is taken.\n\
        \nThis control is a foundational step in the incident response process and\
        \ the following should be considered:\n\xB7 Filter out irrelevant or false\
        \ reports\n    Not every report received is a real incident. This control\
        \ ensures that only legitimate, cybersecurity-relevant incidents are acted\
        \ upon.\n\xB7 Ensure timely and appropriate response\n    By triaging and\
        \ validating reports early, organisations can prioritise real threats and\
        \ avoid wasting resources on non-issues.\n\xB7 Support consistent decision-making\n\
        \    Applying structured triage and validation criteria helps ensure that\
        \ incident response is consistent, repeatable, and aligned with organisational\
        \ policies.\n\xB7 Enable effective escalation and categorisation\n    Validation\
        \ is a prerequisite for categorising and escalating incidents (as required\
        \ in RS.MA-03.1). Without it, the response process could be misdirected or\
        \ delayed.\n\xB7 Improve situational awareness\n    Early validation helps\
        \ build a clearer picture of the threat landscape and supports better coordination\
        \ across teams."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-02
      ref_id: RS.MA-02.2
      description: Automated tools shall be used to support the investigation and
        impact assessment of validated cybersecurity incidents.
      annotation: "The goal of this control is to ensure that organisations are equipped\
        \ with the technical capabilities to efficiently and accurately handle cybersecurity\
        \ incidents once they have been validated.\n\nTo implement this control, the\
        \ following should be considered:\n\xB7 Automated tools should help collect,\
        \ analyse, and correlate incident data to support timely and accurate investigation.\n\
        \xB7 These tools should assist in identifying the scope, severity, and potential\
        \ impact of incidents that have been validated through triage. A validated\
        \ incident is one that has been confirmed to be cybersecurity-related (not\
        \ a false alarm or unrelated technical issue, meets predefined severity criteria\
        \ (such as indicators of compromise, threat intelligence, or known attack\
        \ patterns), and requires response actions (meaning it meets the threshold\
        \ for further investigation, categorisation, and escalation).\n\xB7 The following\
        \ types of tools can be considered to support these activities:\n\xB7 Security\
        \ Information and Event Management (SIEM) systems for centralised log collection\
        \ and analysis.\n\xB7 Extended Detection and Response (XDR) platforms for\
        \ integrated threat detection across endpoints, networks, and servers.\n\xB7\
        \ Security Orchestration, Automation and Response (SOAR) platforms to automate\
        \ workflows and coordinate response actions.\n\xB7 Threat Intelligence Platforms\
        \ to enrich incident data with external threat context.\n\xB7 Network Intrusion\
        \ Detection Systems (NIDS) to monitor and alert on suspicious network activity.\n\
        \xB7 Computer Incident Response Centres (CIRCs) for centralised coordination\
        \ and expert analysis.\n\xB7 Automated mechanisms should be integrated with\
        \ the incident response process to ensure that validated incidents are investigated\
        \ efficiently and prioritised appropriately, in line with the organisation\u2019\
        s incident response plan."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma
      ref_id: RS.MA-03
      description: Incidents are categorised and prioritised.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-03
      ref_id: RS.MA-03.1
      description: Information/cybersecurity incidents shall be categorised, prioritised
        and escalated as specified in the incident response plan.
      annotation: "This control is an evolution of RS.MA-02.1 and is to ensure that\
        \ once an incident is validated, it is systematically classified and managed\
        \ based on its nature, urgency, and potential impact, so that the organisation\
        \ can respond efficiently, consistently, and appropriately.\n\nTherefore the\
        \ following should be considered:\n\xB7 Incidents should be reviewed and classified\
        \ based on their type (e.g. data breach, ransomware, DDoS, account compromise)\
        \ and the validated magnitude of their impact.\n\xB7 The estimation and validation\
        \ of an incident\u2019s magnitude \u2014 further developed in RS.AN-08.1 (Essential),\
        \ should inform how incidents are categorised and prioritised.\n\xB7 Indicators\
        \ such as scope, severity, and time sensitivity should guide prioritisation\
        \ decisions.\n\xB7 Software Bills of Materials (SBOM) can support impact assessment\
        \ by identifying affected components and dependencies.\n\xB7 Criteria for\
        \ categorisation, prioritisation, and escalation should be documented in the\
        \ incident response plan and applied consistently.\n\xB7 Incident response\
        \ strategies should balance the need for rapid recovery with the potential\
        \ benefits of observing attacker behaviour or conducting deeper investigation.\n\
        \xB7 Escalation procedures should be coordinated with designated internal\
        \ and external stakeholders to ensure timely and appropriate response."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma
      ref_id: RS.MA-05
      description: The criteria for initiating incident recovery are applied.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.ma-05
      ref_id: RS.MA-05.1
      description: Clear criteria shall be defined and applied to determine when incident
        recovery processes need to be initiated.
      annotation: "The goal of this control is to ensure that organisations have a\
        \ clear, consistent, and risk-informed decision-making process for determining\
        \ when to begin recovery actions following a cybersecurity incident.\n\nTherefore\
        \ the following should be considered:\n\xB7 Criteria for initiating incident\
        \ recovery should be based on the known or assumed characteristics of the\
        \ incident, such as its severity, scope, and potential impact on operations,\
        \ data, or systems.\n\xB7 The decision to begin recovery should also consider\
        \ the potential disruption that recovery activities may cause to ongoing operations.\n\
        \xB7 Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) should\
        \ be included in the criteria to ensure that recovery actions align with business\
        \ continuity requirements and acceptable downtime or data loss thresholds."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs
      ref_id: RS.AN
      name: Incident Analysis
      description: Investigations are conducted to ensure effective response and support
        forensics and recovery activities
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an
      ref_id: RS.AN-03
      description: Analysis is performed to establish what has taken place during
        an incident and the root cause of the incident
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-03
      ref_id: RS.AN-03.1
      description: 'Each incident shall be analysed to determine what occurred and
        to identify its

        root cause.'
      annotation: "The goal of this control is to understand the full scope of a cybersecurity\
        \ incident and identify its root cause, enabling effective response and prevention\
        \ of similar future events.\n\nTo achieve this goal, the organisation should\
        \ consider the following:\n\xB7 The sequence of events during the incident\
        \ should be reconstructed, identifying which systems, assets, and resources\
        \ were involved.\n\xB7 Vulnerabilities, threats, and threat actors linked\
        \ to the incident should be identified, whether directly or indirectly involved.\n\
        \xB7 Forensic analysis should be used when necessary to examine collected\
        \ data and determine the root cause.\n\xB7 The analysis should focus on identifying\
        \ underlying, systemic causes, not just immediate triggers.\n\xB7 Cyber deception\
        \ technologies should be reviewed for additional insights into attacker behaviour."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an
      ref_id: RS.AN-06
      description: "Actions performed during an investigation are recorded, and the\
        \ records\u2019 integrity and provenance are preserved"
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-06
      ref_id: RS.AN-06.1
      description: Actions performed during an investigation shall be recorded, and
        the records' integrity and provenance shall be preserved.
      annotation: "The goal of this control is to ensure that all actions taken during\
        \ an incident investigation are properly recorded, and that the integrity\
        \ and origin of those records are protected.\n\nTo achieve this goal, the\
        \ organisation should:\n\xB7 Require all personnel involved in incident response\
        \ (e.g., responders, system administrators, engineers) to log their actions\
        \ in a way that prevents tampering or deletion.\n\xB7 Assign responsibility\
        \ to the incident lead for documenting the full investigation, including timelines,\
        \ decisions, and sources of information.\n\xB7 Ensure that all records are\
        \ stored securely and remain traceable to their original source."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-07
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an
      ref_id: RS.AN-07
      description: Incident data and metadata are collected, and their integrity and
        provenance are preserved
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-07.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-07
      ref_id: RS.AN-07.1
      description: Incident data and metadata should be collected and protected to
        ensure their accuracy, authenticity, and traceability.
      annotation: "The goal of this control is to ensure that all relevant information\
        \ about a cybersecurity incident is accurately captured, securely stored,\
        \ and reliably traceable, so it can be used effectively for response, investigation,\
        \ and legal or compliance purposes.\n\nTherefore the following should be considered:\n\
        \xB7 Incident data and metadata (such as the source of the data and the time\
        \ it was collected) should be gathered and stored in a way that protects them\
        \ from tampering or loss.\n\xB7 The integrity and origin of this information\
        \ should be preserved using methods such as:\n    \xB7 Chain of custody documentation\
        \ to track how the data is handled from collection to analysis.\n    \xB7\
        \ Digital signatures and encryption to prevent unauthorised access and confirm\
        \ authenticity.\n    \xB7 Audit logs to record who accessed or changed the\
        \ data and when.\n\xB7 Collecting and protecting this information should support:\n\
        \    \xB7 Timely response by helping to understand when and how the incident\
        \ occurred.\n    \xB7 Investigation and analysis by providing reliable details\
        \ about the incident\u2019s cause, scope, and impact.\n    \xB7 Legal and\
        \ compliance needs by ensuring the data can be used as evidence if required."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-08
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an
      ref_id: RS.AN-08
      description: An incident's magnitude is estimated and validated
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-08.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.an-08
      ref_id: RS.AN-08.1
      description: "An incident\u2019s magnitude shall be estimated and validated."
      annotation: "The goal of this control is to ensure that organisations have a\
        \ clear understanding of the full scope and impact of a cybersecurity incident,\
        \ so that response actions can be appropriately scaled, prioritised, and coordinated.\n\
        \nTherefore the following should be considered:\n\xB7 The scope and impact\
        \ of an incident should be assessed by examining not only the initially affected\
        \ system but also other systems or devices that may be compromised.\n\xB7\
        \ Indicators of Compromise (IoCs), such as unusual network activity, unauthorised\
        \ access attempts, or unexpected software changes, should be identified to\
        \ understand how far the incident has spread.\n\xB7 Signs of persistence,\
        \ including backdoors or malware that allow continued access, should be investigated\
        \ to determine whether the attacker remains active in the environment.\n\xB7\
        \ Automated tools should be used to scan for IoCs and persistence mechanisms\
        \ across potentially affected assets to support timely and thorough analysis.\n\
        \xB7 The validated magnitude of the incident should inform how the incident\
        \ is categorised, prioritised, and escalated, as described in RS.MA-03.1 (Important),\
        \ ensuring that response actions are aligned with the actual risk and business\
        \ impact."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs
      ref_id: RS.CO
      name: Incident Response Reporting and Communication
      description: Response activities are coordinated with internal and external
        stakeholders as required by laws, regulations, or policies.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co
      ref_id: RS.CO-02
      description: Internal and external stakeholders are notified of incidents.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co-02
      ref_id: RS.CO-02.1
      description: Information about cybersecurity incidents shall be communicated
        to employees in a way that is clear and easy to understand.
      annotation: "he goal of this control is to ensure that all employees are informed\
        \ about cybersecurity incidents in a timely and understandable manner, so\
        \ they can respond appropriately and help reduce risks.\n\nTo achieve this:\n\
        \xB7 An Incident Response Plan (IRP) should be in place. This plan outlines\
        \ how the organisation will respond to cybersecurity incidents, including\
        \ who is responsible for what and how to escalate different types of threats.\n\
        \xB7 The IRP should include a communication protocol that explains how to\
        \ share accurate and relevant information with employees quickly and efficiently\
        \ during an incident.\n\xB7 The plan should define the communication channels\
        \ to be used, such as email, internal messaging platforms, phone calls, or\
        \ a dedicated incident portal.\n\xB7 Templates for incident messages should\
        \ be prepared in advance. These templates should include key details like\
        \ the type of incident, how serious it is, which systems are affected, and\
        \ what actions employees should take.\n\xB7 Messages should be written in\
        \ clear, simple language that avoids technical terms, so all employees can\
        \ understand what is happening and what is expected of them.\n\xB7 Senior\
        \ management should receive high-level summaries that explain the impact of\
        \ the incident, the risks involved, and the steps being taken to resolve it."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co-02.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.co-02
      ref_id: RS.CO-02.2
      description: Cybersecurity incidents shall be shared with relevant external
        stakeholders within the timeframes defined in the Incident Response Plan,
        including reporting significant incidents to authorities as required by law.
      annotation: "The goal of this control is to ensure that all relevant external\
        \ parties are informed about cybersecurity incidents in a timely, secure,\
        \ and appropriate manner, helping to maintain trust and meet legal and contractual\
        \ obligations.\n\nTo achieve this:\n\xB7 Information should be shared securely\
        \ and in line with the organisation\u2019s Incident Response Plan and any\
        \ information-sharing agreements.\n\xB7 Relevant stakeholders may include\
        \ designated internal roles, affected customers, suppliers, third-party service\
        \ providers, and business partners.\n\xB7 Customers and partners should be\
        \ notified if they are affected by an incident, with clear instructions on\
        \ any actions they need to take.\n\xB7 Communication with external parties\
        \ should follow any contractual requirements or agreements in place.\n\xB7\
        \ Crisis communication should be coordinated with critical suppliers to ensure\
        \ consistent messaging.\n\xB7 When sharing information about attackers\u2019\
        \ tactics or techniques, any sensitive or identifying data should be removed.\n\
        \xB7 The Human Resources department should be informed if the incident involves\
        \ malicious activity by an insider.\n\xB7 Senior leadership should receive\
        \ regular updates on the status of major incidents.\n\xB7 National authorities,\
        \ such as the CSIRT, law enforcement, or regulators, should be notified based\
        \ on the criteria defined in the IRP and with approval from senior management.\n\
        \xB7 All reporting should comply with relevant national and EU legislation,\
        \ such as the EU Implementing Regulation.\n\xB7 Public updates about incidents\
        \ are addressed under a separate control (RC.CO-04.1)."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs
      ref_id: RS.MI
      name: Incident Mitigation
      description: Activities are performed to prevent expansion of an event and mitigate
        its effects.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi
      ref_id: RS.MI-01
      description: Incidents are contained.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi-01
      ref_id: RS.MI-01.1
      description: Cybersecurity incidents shall be contained and eliminated. Any
        decision to accept and retain certain cybersecurity risks shall be formally
        documented.
      annotation: "The goal of this control is to stop cybersecurity incidents from\
        \ spreading, remove their cause, and ensure that any accepted risks are clearly\
        \ recorded and approved.\n\nTo achieve this:\n\xB7 A formal risk acceptance\
        \ process should be in place for cybersecurity risks that are considered low-impact\
        \ and do not threaten critical business systems. These risks should be reviewed\
        \ and approved by the responsible person or team, based on the organisation's\
        \ risk tolerance.\n\xB7 Cybersecurity tools, such as antivirus software or\
        \ built-in security features in operating systems and network devices, should\
        \ be allowed to automatically take action to contain or remove threats when\
        \ appropriate.\n\xB7 Incident response teams should be able to manually choose\
        \ and carry out actions to stop and remove incidents when needed.\n\xB7 Trusted\
        \ third parties, such as internet service providers or managed security service\
        \ providers, should be allowed to help with containment and elimination actions\
        \ if this is part of the organisation\u2019s response plan."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi-01.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rs.mi-01
      ref_id: RS.MI-01.2
      description: The organisation shall detect unauthorised access or data leakage
        and take appropriate mitigation actions, including monitoring of critical
        systems at external boundaries and key internal points.
      annotation: "The goal of this control is to detect unauthorised access and data\
        \ leakage in a timely manner and to take appropriate mitigation actions. This\
        \ should help protect the confidentiality, integrity, availability, and safety\
        \ of data, whether it is stored, being transmitted, or actively used, across\
        \ both Information Technology (IT) and Operational Technology (OT) environments.\n\
        \nTo achieve this goal, the organisation should:\n\xB7 Monitor Critical Systems\n\
        \    Monitoring should be implemented at external network boundaries and key\
        \ internal points to detect anomalies or unauthorised access attempts.\n\xB7\
        \ Protect Data in All States\n    Data should be protected using encryption,\
        \ digital signatures, and cryptographic hashes to ensure confidentiality and\
        \ integrity during storage, transmission, and use.\n\xB7 Control Outgoing\
        \ Communications\n    Outbound communications containing sensitive data should\
        \ be automatically blocked or encrypted based on data classification.\n\xB7\
        \ Restrict Use of Personal Services\n    Access to personal communication\
        \ platforms (e.g. personal email, file-sharing services) from organisational\
        \ systems should be restricted to reduce the risk of data leakage.\n\xB7 Prevent\
        \ Data Reuse in Non-Production Environments\n    Sensitive production data\
        \ should not be reused in development or testing environments unless properly\
        \ anonymised or masked.\n\xB7 Clear Temporary Data\n    Sensitive data should\
        \ be cleared from memory or temporary storage once it is no longer needed.\n\
        \xB7 Audit Identity and Access Management\n    Systems such as Microsoft Active\
        \ Directory should be regularly audited, with a focus on privileged accounts\
        \ and access control consistency.\n\xB7 Ensure OT-Specific Feasibility\n \
        \   In OT environments, detection and mitigation measures should be adapted\
        \ to avoid disrupting safety or operational continuity. Passive monitoring\
        \ and interface-level logging may be used where direct integration is not\
        \ feasible.\n\xB7 Align with ENISA Guidance\n    These practices align with\
        \ ENISA\u2019s Threat Landscape Reports and Information Leakage Guidance,\
        \ which provide recommendations for detecting and mitigating data breaches\
        \ and unauthorised access."
      implementation_groups:
      - I
      - E
      - IK
      - EK
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc
      assessable: false
      depth: 1
      ref_id: RC
      name: RECOVER
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc
      ref_id: RC.RP
      name: Incident Recovery Plan Execution
      description: Restoration activities are performed to ensure operational availability
        of systems and services affected by cybersecurity incidents.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-01
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp
      ref_id: RC.RP-01
      description: The recovery portion of the incident response plan is executed
        once initiated from the incident response process.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-01.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-01
      ref_id: RC.RP-01.1
      description: A recovery process for disasters and information/cybersecurity
        incidents shall be developed and executed.
      annotation: "The goal of this control is to ensure the organisation can respond\
        \ quickly and effectively to disasters, information security incidents, and\
        \ cybersecurity events by developing and executing a structured recovery process\
        \ that protects people, systems, and data.\n\nTo support this goal, the organisation\
        \ should:\n\xB7 Develop a Recovery Process\n    A documented process should\
        \ guide immediate actions in the event of a fire, medical emergency, theft,\
        \ natural disaster, or information/cybersecurity incident.\n\xB7 Define Roles\
        \ and Responsibilities\n    The recovery process should specify who is authorised\
        \ to initiate recovery procedures and who will communicate with external stakeholders.\n\
        \xB7 Protect Information and Systems\n    The process should include steps\
        \ for securing information and systems, such as shutting down or locking devices,\
        \ switching to backup sites, or securing physical documents.\n\xB7 Establish\
        \ Contact Procedures\n    A list of internal and external contacts should\
        \ be maintained and included in the recovery plan for quick access during\
        \ an incident.\n\xB7 Ensure Awareness and Readiness\n    Individuals with\
        \ recovery responsibilities should be familiar with the recovery plan and\
        \ understand the authorisations required to carry out each step.\n\xB7 Integrate\
        \ with the Incident Response Plan\n    The recovery process should be part\
        \ of or aligned with the broader Incident Response Plan (IRP) to ensure consistency\
        \ and coordination.\n\xB7 Include OT Environments\n    Recovery planning should\
        \ address OT systems, including procedures for restoring industrial operations,\
        \ securing control systems, and coordinating with safety protocols.\n\xB7\
        \ Plan for Future Enhancements\n    This control serves as a foundation for\
        \ more advanced recovery planning, as further developed in control RC.RP-06.1."
      implementation_groups:
      - B
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-02
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp
      ref_id: RC.RP-02
      description: Recovery actions are selected, scoped, prioritised, and performed
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-02.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-02
      ref_id: RC.RP-02.1
      description: The organisation's essential functions and services shall be continued
        with little or no loss of operational continuity, and continuity shall be
        maintained until full system recovery.
      annotation: "The goal of this control is to minimise disruption to critical\
        \ operations during incidents and ensure they remain functional until systems\
        \ are fully restored.\n\nTo achieve this goal, the organisation should:\n\xB7\
        \ Plan for Continuity\n    \xB7 A business continuity plan should be maintained\
        \ to identify essential functions and define procedures for uninterrupted\
        \ operation during incidents.\n    \xB7 An incident response plan should be\
        \ included, detailing steps for containment, damage assessment, and staged\
        \ recovery.\n\xB7 Sustain Operations Until Recovery\n    \xB7 Continuity measures\
        \ should support essential functions until full restoration is achieved.\n\
        \    \xB7 Temporary workarounds, redundant systems, or manual procedures should\
        \ be used where necessary to maintain operations.\n\xB7 Prioritise Recovery\n\
        \    \xB7 Business impact analysis and system categorisation should be used\
        \ to define recovery priorities.\n    \xB7 Systems should be categorised based\
        \ on the impact of losing availability, integrity, or confidentiality, with\
        \ special attention to safety-critical OT environments.\n\xB7 Ensure Data\
        \ Resilience\n    \xB7 Robust backup solutions should be implemented to enable\
        \ fast and reliable data restoration.\n    \xB7 Backups should be secured\
        \ and tested regularly.\n\xB7 Monitor and Respond\n    \xB7 Systems should\
        \ be continuously monitored to detect disruptions early.\n    \xB7 Quick response\
        \ actions should be taken to minimise operational impact.\n\xB7 Test and Improve\n\
        \    \xB7 Recovery procedures should be tested regularly to ensure effectiveness.\n\
        \    \xB7 Recovery actions should be documented and reviewed to improve readiness\
        \ over time."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-05
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp
      ref_id: RC.RP-05
      description: The integrity of restored assets is verified, systems and services
        are restored, and normal operating status is confirmed.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-05.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-05
      ref_id: RC.RP-05.1
      description: The integrity of restored systems and assets shall be verified
        before they are returned to service. Systems and services shall be fully restored,
        and normal operations shall be confirmed.
      annotation: "The goal of this control is to ensure that systems and services\
        \ are not only restored after an incident, but also verified to be safe, uncompromised,\
        \ and fully functional before being returned to normal operations.\n\nTo achieve\
        \ this goal the following should be considered:\n\xB7 Restored systems should\
        \ be checked for signs of compromise, such as malware or unauthorised access,\
        \ before being brought back online.\n\xB7 The root cause of the incident should\
        \ be identified and addressed to prevent recurrence.\n\xB7 All recovery actions\
        \ should be reviewed to ensure they were completed correctly and that no security\
        \ gaps remain.\n\xB7 A final check should confirm that the system is safe,\
        \ complete, and ready for normal use."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-06
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp
      ref_id: RC.RP-06
      description: The end of incident recovery is declared based on criteria, and
        incident-related documentation is completed.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-06.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.rp-06
      ref_id: RC.RP-06.1
      description: The end of incident recovery shall be formally declared based on
        predefined criteria, and all incident-related documentation shall be completed
        and reviewed.
      annotation: "The goal of this control is to ensure that the incident recovery\
        \ process is formally and responsibly concluded, and that comprehensive documentation\
        \ is completed to support accountability, learning, and future preparedness.\n\
        \nTo achieve this goal the following should be considered:\n\xB7 An After-Action\
        \ Report should be prepared that includes:\n    \xB7 A summary of the incident\
        \ and its impact.\n    \xB7 The steps taken to respond and recover.\n    \xB7\
        \ Lessons learned and recommendations for improvement.\n\xB7 Before declaring\
        \ the recovery phase complete, the following criteria should be met:\n   \
        \ \xB7 All affected systems and services are fully operational.\n    \xB7\
        \ No known threats or vulnerabilities remain in the environment.\n    \xB7\
        \ Data has been restored and verified for integrity.\n    \xB7 Necessary security\
        \ patches or updates have been applied.\n    \xB7 Monitoring is in place to\
        \ detect any recurring or related issues.\n    \xB7 The After-Action Report\
        \ is finalised and reviewed by relevant stakeholders.\n    \xB7 All stakeholders\
        \ are informed that the incident has been resolved."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co
      assessable: false
      depth: 2
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc
      ref_id: RC.CO
      name: Incident Recovery Communication
      description: Restoration activities are coordinated with internal and external
        parties.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-03
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co
      ref_id: RC.CO-03
      description: Recovery activities and progress in restoring operational capabilities
        are communicated to designated internal and external stakeholders.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-03.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-03
      ref_id: RC.CO-03.1
      description: Recovery activities and progress in restoring operational capabilities
        shall be communicated to designated internal and external stakeholders in
        accordance with established communication procedures.
      annotation: "The goal of this control is to ensure that recovery efforts and\
        \ the progress of restoring operational capabilities are clearly and consistently\
        \ communicated to all relevant internal and external stakeholders. This supports\
        \ transparency, coordination, and informed decision-making during the recovery\
        \ phase of an incident.\n\nTo achieve this goal the following should be considered:\n\
        \xB7 Recovery updates, including progress on restoring systems and services,\
        \ should be shared securely and consistently with internal and external stakeholders,\
        \ in line with the organisation\u2019s response plans and information-sharing\
        \ agreements.\n\xB7 Senior leadership should receive regular updates on the\
        \ status of recovery efforts, especially during major incidents.\n\xB7 Communication\
        \ protocols defined in contracts with suppliers and partners should be followed\
        \ to ensure timely and accurate information exchange.\n\xB7 Crisis communication\
        \ with critical suppliers should be coordinated to support aligned recovery\
        \ actions.\n\xB7 If no actual incidents have occurred, tabletop exercises\
        \ should be conducted to test and validate recovery communication procedures\
        \ and stakeholder coordination."
      implementation_groups:
      - I
      - E
      - IG
      - EG
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04
      assessable: false
      depth: 3
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co
      ref_id: RC.CO-04
      description: Public updates on incident recovery are shared using approved methods
        and messaging.
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04.1
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04
      ref_id: RC.CO-04.1
      description: Public updates on incident recovery shall be shared using approved
        communication methods and messaging, in accordance with established procedures.
      annotation: "The goal of this control is to ensure that public communication\
        \ during the recovery phase of an incident is accurate, timely, and delivered\
        \ through approved channels, in order to maintain trust, manage reputational\
        \ risk, and meet legal or regulatory obligations.\n\nTo achieve this goal\
        \ the following should be considered:\n\xB7 Approved methods for public communication,\
        \ such as press releases, official websites, or designated spokespersons,\
        \ should be defined in advance and used consistently.\n\xB7 Contact information\
        \ for relevant parties (e.g. internal staff, third-party vendors, law enforcement,\
        \ cyber insurance providers, government agencies) should be established and\
        \ maintained.\n\xB7 Contact lists should be reviewed and verified regularly\
        \ (e.g. annually) to ensure accuracy.\n\xB7 Primary and secondary communication\
        \ mechanisms (e.g. phone calls, emails, letters) should be identified, considering\
        \ that some methods may be unavailable during an incident.\n\xB7 Communication\
        \ protocols and mechanisms should be reviewed periodically or when significant\
        \ organisational changes occur.\n\xB7 If no actual incidents have occurred,\
        \ tabletop exercises or simulations should be conducted to test public communication\
        \ procedures and ensure readiness."
      implementation_groups:
      - I
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04.2
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04
      ref_id: RC.CO-04.2
      description: The organisation shall assign a Public Relations Officer (PRO)
        to manage public communications during information/cybersecurity incident
        recovery, ensuring that public updates are shared while maintaining the confidentiality,
        integrity, and accuracy of the information.
      annotation: "The goal of this control is to ensure that public communication\
        \ during cybersecurity or information security incident recovery is professionally\
        \ managed, accurate, and aligned with the organisation\u2019s confidentiality\
        \ and integrity standards. By assigning a dedicated Public Relations Officer\
        \ (PRO), the organisation ensures that public messaging is handled by a trained\
        \ individual who can maintain trust, protect the organisation\u2019s reputation,\
        \ and comply with legal and regulatory requirements.\n\nTo achieve this goal,\
        \ the following should be considered:\n\xB7 Assign a Public Relations Officer\
        \ (PRO): Designate a qualified individual to handle public communications\
        \ during incident recovery. The job description of the PRO may include the\
        \ following:\n    \xB7 Developing Communication Strategies\n    \xB7 Writing\
        \ and Distributing Press Releases\n    \xB7 Building and maintaining relationships\
        \ with journalists and media outlets to ensure positive coverage (media relations).\n\
        \    \xB7 Handling communication during crises to maintain the organisation\u2019\
        s reputation (crisis management).\n    \xB7 Keeping track of media coverage\
        \ and conducting media analysis to gauge public perception (monitoring media\
        \ coverage).\n\xB7 Develop Communication Protocols: Establish clear protocols\
        \ for the PRO to follow when sharing public updates, ensuring all information\
        \ maintains confidentiality, integrity, and accuracy.\n\xB7 Training and Preparedness:\
        \ Provide the PRO with training on incident communication strategies and ensure\
        \ they are prepared to act swiftly during an incident.\n\xB7 Regular Reviews:\
        \ Periodically review and update communication protocols to adapt to new challenges\
        \ and ensure effectiveness."
      implementation_groups:
      - E
    - urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04.3
      assessable: true
      depth: 4
      parent_urn: urn:intuitem:risk:req_node:ccb-cyfun2025:rc.co-04
      ref_id: RC.CO-04.3
      description: The organisation shall implement a crisis communication strategy
        to mitigate negative impacts during a crisis and help restore its reputation
        afterward.
      annotation: "The goal of this control is to ensure that the organisation is\
        \ prepared to manage communications effectively during and after a crisis,\
        \ in order to minimise reputational damage, maintain stakeholder trust, and\
        \ support recovery efforts.\n\nTo achieve this goal, the following should\
        \ be considered:\n\xB7 Develop the Strategy: Create a comprehensive crisis\
        \ communication plan that outlines procedures for managing communications\
        \ during and after a crisis to employees, customers, partners, regulators,\
        \ and the media. Ensure that all communications comply with legal requirements\
        \ and industry regulations.\n\xB7 Assign Roles and Responsibilities: Designate\
        \ a crisis communication team, including a spokesperson, to handle public\
        \ and internal communications. The participation of PR professionals, legal\
        \ advisers and senior management should be considered.\n\xB7 Establish Communication\
        \ Channels: Identify and set up reliable channels for disseminating information,\
        \ such as social media, press releases, and internal communications platforms.\
        \ Media coverage and social media should be continuously monitored for misinformation\
        \ or negative sentiment. Inaccuracies should be responded to and corrected\
        \ immediately.\n\xB7 Training and Drills: Conduct regular training sessions\
        \ and crisis simulations to ensure the team is prepared to respond effectively.\n\
        \xB7 Monitor and Adapt: Continuously monitor the situation and adapt the communication\
        \ strategy as needed to address evolving circumstances.\n\xB7 Post-Crisis\
        \ Review: After the crisis, review the communication efforts to identify lessons\
        \ learned and improve future responses."
      implementation_groups:
      - E
