+5.1.7 For the purpose of point 5.1.6., the relevant entities shall: (a) regularly monitor reports on the …

5.1.7 For the purpose of point 5.1.6., the relevant entities shall: (a) regularly monitor reports on the …

Requirement

For the purpose of point 5.1.6., the relevant entities shall: (a) regularly monitor reports on the implementation of the service level agreements, where applicable; (b) review incidents related to ICT products and ICT services from suppliers and service providers; (c) assess the need for unscheduled reviews and document the findings in a comprehensible manner; (d) analyse the risks presented by changes related to ICT products and ICT services from suppliers and service providers and, where appropriate, take mitigating measures in a timely manner.

Guidance

  • Set up a regular review (e.g. as part of a regular supplier meeting) and follow up on deviations from the agreed SLAs.
  • Define and assign responsibilities regarding maintenance, operation and ownership of assets.
  • Make sure that monitoring encompasses periodic reassessment of supplier and service provider compliance, and monitor supplier and service provider release notes.
  • Periodically ensure that product configuration is aligned with vendor recommendations, with increasing frequency as products age.
  • Keep track of security incidents related to or caused by suppliers and service providers as they might trigger an unscheduled review of the suppliers and service providers. Other circumstances for such an unscheduled review include to suppliers and service providers (indicative, non-exhaustive list):
    • material changes in their operations;
    • changes in their risk exposure;
    • failure to meet their contractual obligations; and
    • emergence of new threats or vulnerabilities affecting the provided ICT products or services.
  • Monitoring frequency should be aligned with supply chain policy (Annex to the regulation, point 5.1.1) and the review of the secure acquisition of ICT services, systems or products processes (Annex to the regulation, point 6.1.3).

Examples of evidence

  • Records showing that service levels are monitored in accordance with established SLA).
  • Incident response records which confirm whether the entity takes into account incidents related to ICT services, systems or products from suppliers and service providers;
  • Evidence that signed contracts with third parties (e.g. contractors and suppliers) are in line with the policy on the security of network and information systems, for example contractual clauses, references to key security-relevant roles and responsibilities, and requirements for the contractor to report incidents.
  • Supplier and service provider exit process, meaning documentation outlining how the entity manages the exit of suppliers and service providers. This includes transitioning services, data and access rights when terminating a supplier and service provider relationship.
  • List of security incidents related to or caused by engagement with third parties.

Tips: guidance

  • In addition to the elements referred to point 5.1.4 of the Annex to the regulation, consider the following additional elements for contract clauses (indicative, non-exhaustive list):
    • a clear and complete description of ICT products and services;
    • service level descriptions, including uptime guarantees or target service levels, response times for service issues and updates to the service level descriptions thereof;
    • locations (regions or countries) where the ICT products are to be produced and ICT services are to be provided and where data is to be processed, including the storage location and the requirement for the supplier and service provider to notify the entity in advance if it envisages changing such locations;
    • provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data;
    • non-disclosure agreements;
    • obligations on the suppliers and service providers, such as retrieval and disposal of the information obtained by the suppliers and service providers in the exercise of their tasks, in the event of the insolvency, resolution, termination or discontinuation of the business operations of the supplier or service provider;
    • obligations of the supplier or service provider to provide assistance to the entity at no additional cost or at a cost that is determined ex ante , in the event of a cyber incident that presents a risk and was caused by the ICT product or the ICT service contracted;
    • roles and responsibilities;
    • contacts and reporting lines;
    • the obligation of the supplier or service provider to fully cooperate with the competent authorities;
    • termination rights and related minimum notice periods for the termination of the contractual arrangements;
    • notice periods and reporting obligations of the supplier or service provider to the entity, including notification of any development that might have a material impact on the supplier’s or service provider’s ability to effectively provide the ICT products or services in line with agreed service levels;
    • the right to audit by the entity or an appointed third party and by the competent authority and the obligation of the supplier and the service provider to fully cooperate during onsite inspections and audits performed by competent authorities and the obligation to provide details on the scope, procedures to be followed and frequency of such inspections and audits;
    • exit strategies, in particular the establishment of a mandatory adequate transition period, provisions on intellectual property and responsibilities of the supplier during the exit period, for example to provide relevant documentation and historical logs.
  • In addition to the elements referred to in point 5.1.5 of the Annex to the regulation , consider the following (indicative, non-exhaustive list):
    • country-specific information (e.g. threat assessment from national security services), if available;
    • restrictions or exclusions posed by a relevant national authority, for example equipment with high criticality for the entity or for high-risk suppliers;
    • information stemming from known incidents or cyber threat intelligence; and
    • the characteristics of each supplier, such as the quality of its security practices, the legal framework and the level of transparency.
  • Make sure that secure decommissioning service providers consider issues such as deactivating user and service accounts, terminating data flows and ensuring secure disposal of the entity’s data within supplier or service provider systems.
  • Awareness training regarding rules of engagement and behaviour should be delivered to the entity’s and the suppliers or service providers’ personnel, where appropriate, based on the level of access to the entity’s assets and information assets.
  • Include relevant personnel of suppliers and service providers and their relevant responsibilities, in crisis management tests, where appropriate.
  • Make sure that contracts with suppliers and service providers are in line with the policy on the security of network and information systems.
  • When implementing a supply chain security policy, consider the following elements regarding the use of free and open source software (FOSS) supply chain:
    • When using FOSS without purchasing a related software product or entering into a service agreement for development with the originator of the FOSS, obligations for compliance cannot be imposed beyond the adherence to the terms of the open source software licence (45).
    • Consider supporting the communities developing and maintaining FOSS and invest in a mutually beneficial relationship with them. Where effective, this could involve relationships with the relevant OSS steward that ‘provid[es] support on a sustained basis for the development and ensures the viability of those products’ (46). Such a relationship should not qualify the steward as a direct supplier or service provider, as imposing technical or methodological requirements might not be appropriate, applicable or feasible considering their role.
    • Consider steps to mitigate the identified risks to the security of network and information systems as it relates to free and open source software dependencies:
      • before integrating free and open source components, require the direct supplier or service provider to conduct a risk assessment and communicate the results to understand potential vulnerabilities and their impact on the entity’s systems;
        • where feasible, the risk assessment should be done in coordination with its open source project or associated OSS Steward, at the expense of the supplier or service provider using the component and in such a way that subsequent risk assessments done by third parties benefit from this work;
      • require suppliers or service providers to provide evidence of their engagement with the OSS community to ascertain whether adequate resources are available to support sustainable maintenance efforts and contribute such resources where appropriate, including to guarantee future availability of security patches;
      • ensure that free and open source components are regularly updated by the supplier or the service provider to address all known and patched security vulnerabilities;
      • require the supplier or service provider to perform regular code reviews and security testing on free and open source components to identify and address any security issues (47);
      • require the supplier or service provider to provide information on tools to manage software dependencies (e.g. Dependabot, Yarn, Gradle and Pip) and ensure that all components and their dependencies are secure and up to date;
      • require the supplier or service provider to provide clear documentation and policies for using free and open source components, including guidelines for evaluation and integration, along with evidence of efforts to ensure the sustainable maintenance of their dependencies by nurturing the open source projects they rely on, such as by referencing their public (code) contributions.
    • Engage with relevant open source communities to stay informed about significant updates, patches and best practices for using and updating their FOSS component.

Tips: examples of evidence

  • Contract clauses that include, in addition to the elements referred to in point 5.1.4 of the Annex to the regulation, one or more of the above lists with additional elements.
  • Evidence of awareness trainings.
  • Records from crisis management tests (Annex to the regulation, point 4.3.4), if available or written confirmations by the supplier or provider after crisis management tests, which demonstrate the participation of relevant personnel of suppliers and service providers.
  • For FOSS (indicative, non-exhaustive list):
    • results from risk assessments of the FOSS,
    • dependency monitoring tools,
    • documentation.

1. Áttekintés

Megnevezés Szabvány

1.1 Hivatkozások

1.2 Azonosított követelmények

1.3 Kapcsolódó szabályozások

2. Azonosított követelmények

Követelmények
Forrás Követelmény

3. Kapcsolódó szabályozások

Szabályozások
Forrás Szabályozás

Kapcsolt feladatok