Article 28(1) of Regulation (EU) 2022/2554, DORA, makes the customer's ICT risk management framework the thing your service is a component of, and Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, published on 25 June 2024 and in force since 15 July 2024, specifies that framework in forty-two articles: the policies, procedures, protocols and tools of Article 9(2) of DORA, the detection mechanisms of Article 10, the continuity and recovery plans of Article 11, and a simplified framework for the small entities of Article 16. Most of it is the customer's own housekeeping. Nine articles name the ICT third-party service provider, and each of them is a question the customer's framework has to be able to answer about you, which means a question you will be asked. This article reads those nine from the Official Journal on CELLAR on 12 September 2026, from the vendor's side. It is not legal advice.
The asset register wants your support end dates, Article 4
Article 4 requires an ICT asset management policy under which the entity keeps records of every ICT asset: a unique identifier, its physical or logical location, its classification, its owner, the business functions it supports, its continuity requirements including recovery time and recovery point objectives, whether it is exposed to external networks, its links and interdependencies with other assets, and, point (b)(ix) of paragraph 2, where applicable, the end dates of the ICT third-party service provider's regular, extended and custom support services, after which the asset is no longer supported. For a vendor that means a published support lifecycle per product version, with dates, because the customer's register has a column for it and an empty column is a finding at the customer's next audit.
The vulnerability procedure verifies you, and tracks your libraries, Article 10
Article 10 requires vulnerability management procedures that, among other things, verify whether ICT third-party service providers handle vulnerabilities related to the services they provide and whether they report to the entity at least the critical vulnerabilities and statistics and trends in a timely manner; and that track the usage of third-party libraries, including open-source libraries, used by services supporting critical or important functions, and of services developed or customised for the entity by a provider. The Regulation adds that the entity requests providers to investigate the relevant vulnerabilities, determine the root causes and implement mitigating action, and that it monitors the versions and updates of third-party libraries where appropriate in collaboration with the provider. The entity itself runs automated vulnerability scanning at least weekly on assets supporting critical or important functions, and its patch management sets deadlines with escalation.
Read from the vendor's side this is three deliverables: a vulnerability handling process the customer can verify exists, a periodic vulnerability report that names at least the critical ones with statistics and trends, and a list of the third-party and open-source components in the product with their versions, which is the software bill of materials the Cyber Resilience Act requires a manufacturer to produce for its own reasons. A vendor that already produces one for the CRA answers Article 10(2)(d) with the same document.
Data and system security: roles between you and the customer, measures on your infrastructure, Article 11
Article 11 requires a data and system security procedure whose elements include, for ICT assets or services operated by an ICT third-party service provider, point (k), the identification and implementation of requirements to maintain digital operational resilience in line with the data classification and the ICT risk assessment. For that point the entity considers the implementation of vendor-recommended settings on the elements it operates itself, a clear allocation of information security roles and responsibilities between the entity and the provider, in accordance with the entity's full responsibility under Article 28(1)(a) of DORA, the competences it needs to manage and secure the service, and technical and organisational measures to minimise the risks related to the infrastructure the provider uses for its services, considering leading practices and standards. Point (f)(ii) of the same article, on endpoint devices, requires security mechanisms that cannot be modified, removed or bypassed by staff or by ICT third-party service providers in an unauthorised manner.
For a SaaS vendor the allocation of roles is the shared-responsibility document: which security settings the customer configures, which the vendor operates, and which the customer may not turn off. The measures on your infrastructure are the controls your certificate scope describes, and the customer's framework will ask for them by reference to a standard.
Encrypted connections over third-party networks, Article 13
Article 13 requires network security measures that include the encryption of network connections passing over corporate, public, domestic, third-party and wireless networks, for the communication protocols used, taking into account the data classification, and, for the entity's network services, documentation of whether they are provided by an intra-group or by third-party providers. The vendor's answer is the encryption in transit for every connection between the customer and the product and between the product and its subcontractors, with the protocol versions written down.
Source code from providers is analysed and tested before production, Article 16
Article 16 requires a policy on the acquisition, development and maintenance of ICT systems, and a procedure for testing and approving all ICT systems before use and after maintenance, commensurate with the criticality of the business processes and assets concerned. The procedure contains controls to protect the integrity of source code developed in-house or by a provider and delivered to the entity, and provides that proprietary software and, where feasible, the source code provided by third-party providers or coming from open-source projects are analysed and tested before deployment in production. For a vendor whose product is installed by the customer, that is the customer's right to test your release before it goes live and to see integrity controls on what you deliver: signed releases, checksums, a build pipeline you can describe. For a SaaS vendor it is the customer's interest in your own release testing, because the deployment into production happens on your side.
A named account for each of your staff with access, Article 20
Article 20 requires identity management policies under which a unique identity corresponding to a unique user account is assigned to each staff member of the entity or of an ICT third-party service provider accessing the entity's information assets and ICT assets. Where your support staff reach into the customer's environment, the customer will issue them named accounts and expect you to tell it who joins and who leaves; where they reach only into your own environment, the customer's questionnaire will ask you to show the same rule applied at home.
Your incident notifications are one of the customer's detection inputs, Article 23
Article 23 requires a mechanism to promptly detect anomalous activities that collects, monitors and analyses, among other inputs, ICT-related incident notifications from an ICT third-party service provider, detected in the provider's own systems and networks, that may affect the entity. The customer's alerting is designed to receive your notifications as a feed, alongside its own logs and threat intelligence, and to prioritise them for management within its expected resolution time, during and outside working hours. The major-incident article explains what happens next: the four-hour clock at the customer starts when it classifies, and your notification is what lets it classify.
Continuity tests include your service and your insolvency, Articles 25 and 26
Article 25 requires the testing of the entity's ICT business continuity plans to contain the testing of ICT services provided by third-party providers where applicable, and procedures to verify that the entity's staff, its providers, its systems and its services can respond adequately to the scenarios of Article 26; for the provider scenarios the entity duly considers insolvency or failure of the provider and political risks in the provider's jurisdiction. Article 26 requires the response and recovery plans to consider scenarios in which a critical or important function deteriorates or fails, with the potential impact of a provider's insolvency or other failure, and political and social instability in the provider's jurisdiction and where the data are stored and processed, and to implement continuity measures to mitigate failures of providers of services supporting critical or important functions. The vendor's part is the exit and transition procedure of the Article 30 clause checklist, 30(3)(f), and its willingness to take part in the customer's continuity test, which point (c) of Article 30(3) already puts in the contract.
What an ISO 27001 system already answers
The Delegated Regulation names no standard, and what follows is StandardOS's reading of where an ISO/IEC 27001:2022 management system produces the answers, with no presumption of conformity. Article 4(2)(b)(ix) is the asset inventory, A.5.9, if the inventory carries support end dates. Article 10 is the vulnerability management control, A.8.8, and the supplier reporting terms of A.5.20; the component list is the same record the CRA asks for. Article 11(k) is the supplier agreement, A.5.20, and the configuration control, A.8.9; point (f)(ii) is A.8.1 and A.8.7. Article 13 is A.8.20 to A.8.22 and the cryptography control, A.8.24. Article 16 is secure development, A.8.25 to A.8.29, with the release testing of A.8.29 and the change control of A.8.32. Article 20 is A.5.16, identity management, and A.5.18, access rights. Article 23 is the incident management planning of A.5.24 and the logging and monitoring of A.8.15 and A.8.16, which is where the notification comes from. Articles 25 and 26 are A.5.29 and A.5.30 and the continuity tests they require. What the standard does not give you is the customer's register, its classification of your service, and its scenarios; those are questions you answer with facts, and the register data sheet holds the ones about locations and subcontractors.
What to do before the framework's questions arrive
Publish a support lifecycle with dates per version. Produce a component list with versions and a periodic vulnerability report, and write the reporting cadence into the contract. Write the shared-responsibility document that allocates roles under Article 11(k), including the settings the customer may not turn off. Document the encryption in transit with protocol versions. Describe the release pipeline and its integrity controls. Apply named accounts to your own staff and offer the joiner-leaver notice for accounts in the customer's environment. Wire your incident notifications into a channel the customer can ingest. And rehearse the exit with the customer when it asks, because Article 25 says it will. The DORA hub holds the dates of the Regulation and its acts.