iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For financial entities covered by EU law, the practical starting point is the Digital Operational Resilience Act (DORA): identify the software and ICT services the business relies on, assess the risks and critical functions they support, set appropriate controls in supplier arrangements, and keep evidence that oversight continues throughout each relationship. DORA applies from 17 January 2025. It is an EU baseline, not a universal rulebook: obligations depend on jurisdiction, entity type, service, and applicable national requirements.
What DORA means for software supply chains
DORA is Regulation (EU) 2022/2554, the EU framework for digital operational resilience. It treats software suppliers as part of the broader ICT third-party risk picture. That can include providers of software, cloud services, analytics, data-center services, and other ICT services used in business operations.
The key accountability principle is that outsourcing does not transfer the financial entity’s regulatory responsibility. Article 28(1)(a) says entities using ICT services to run business operations “shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law.” A supplier’s assurance report or contractual promise can support oversight, but it does not replace the entity’s own decisions and controls.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
DORA’s ICT risk-management requirements, including Articles 6 and 28–30, provide the central framework for covered entities. The European Commission’s Delegated Regulation (EU) 2024/1774 and other implementing or delegated acts supplement the regulation. Check the current legal text and applicable technical standards for the specific entity and service; the required controls can vary with the supported function and risk.
#1 Best Overall
Build the compliance program around services and functions
Start with what the institution depends on, not with a software-compliance certificate or a list of vendors. The aim is to connect assets and supplier relationships to the business processes and critical or important functions they support, then apply proportionate controls to those relationships.
1. Assign accountable owners and set scope
Bring management, security, engineering, procurement, legal, and compliance together to define the regulated entity and inventory boundary. Include internally developed products, purchased software, software-as-a-service, development pipelines, open-source and other external components, and relevant ICT supplier arrangements. Identify the business processes and critical or important functions that depend on each service.
2. Create an operational inventory
Connect software and component records to the institution’s broader ICT asset and supplier inventories so that technical findings have an accountable business owner. For each material product or service, capture information appropriate to the applicable requirements and the institution’s risk, such as:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Product or service, provider, internal owner, and deployment or service location.
- Business processes and critical or important functions supported, plus the service’s criticality.
- Data handled and relevant data-processing locations.
- Known dependencies, including significant software components and subcontractors.
- Contract dates, review status, material changes, and the status of risk findings.
DORA requires relevant ICT inventories and a register of ICT service arrangements. Keep records current when services, dependencies, subcontractors, or supported functions materially change; use the current legal and technical requirements to determine the required register content and format.
3. Assess providers before committing
Before entering an ICT arrangement, assess the service’s role and the risks of relying on that provider. Consider provider suitability, information-security practices, continuity capabilities, incident handling, subcontracting, data locations, and whether the institution can oversee the arrangement. Evaluate concentration risk and the practical availability of alternatives, especially where multiple important services rely on the same provider or infrastructure.
Apply proportionality to the service and its risk; proportionality is not a reason to skip assessment. Record the decision, evidence reviewed, unresolved concerns, and any conditions that must be addressed before onboarding.
4. Make the contract support oversight
Use written agreements that clearly describe the services and allocate rights and responsibilities. Depending on the arrangement and applicable DORA provisions, address service levels, security requirements, incident cooperation, access and audit rights, service and data locations, subcontracting conditions, notice of relevant changes, continuity, and termination or transition. Ensure the institution can obtain the information and cooperation needed to monitor the service and meet its obligations.
Recommended Free Tools
Review Articles 28–30 and applicable technical standards with legal and compliance specialists before finalizing terms. A general supplier template may omit protections needed for a particular service or critical function.
5. Apply secure-development and component controls
For software developed in-house or obtained from suppliers, establish practices that make security decisions and changes traceable. Useful evidence includes design and code reviews, build and release integrity controls, vulnerability testing, remediation records, and information about component provenance.
A software bill of materials (SBOM) or comparable dependency inventory can help identify affected applications when a component vulnerability is disclosed. It is a visibility aid, not proof that the software is secure. The sources cited here do not establish a universal DORA requirement for every financial entity to produce or obtain an SBOM for every software product.
NIST’s Software Security in Supply Chains guidance and NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1, offer implementation practices for supplier assessment, component visibility, provenance, vulnerability management, and secure development. They are guidance, not DORA mandates; applicability may also arise through other regulatory or contractual requirements.
Free tools Windows power users keep installed
One-click scans. No signup required.
6. Monitor, test, remediate, and plan exit
Supplier diligence is not a one-time onboarding task. Reassess risk as services, dependencies, incidents, or subcontracting arrangements change. Test relevant controls, track exceptions with owners and due dates, and document remediation. Keep continuity and exit plans workable for the service’s importance, including how the institution would access or move data and what constraints could impede transition. Revisit concentration and substitutability as the provider landscape changes.
Best Value
What evidence to retain
Keep an evidence trail that lets management, auditors, and supervisors follow the path from service risk to control decision and ongoing oversight. For each material software or ICT supplier, organize records such as:
- The service-to-function mapping, risk classification, and accountable control owner.
- Pre-contract due diligence, security evidence, and the rationale for accepting or mitigating risks.
- The current agreement, amendments, subcontracting information, and relevant register entry.
- Development, dependency, vulnerability, and provenance evidence where applicable.
- Monitoring, testing, audit, incident, exception, and remediation records.
- Continuity and exit arrangements, including review dates and identified transition constraints.
Make each record traceable to its owner and review date. NIST guidance can help structure supplier-assurance and software-provenance evidence, while DORA establishes the legal baseline for entities within its scope.
How to select supporting tools without mistaking them for compliance
Software composition analysis, SBOM management, and third-party risk or GRC platforms can help maintain inventories and evidence. Compare the control outcomes they support rather than relying on a vendor’s “compliance” label.
- For software composition analysis or SBOM tools: check direct and transitive dependency coverage, supported formats, update cadence, vulnerability matching and prioritization, provenance information, integration with build and deployment pipelines, and evidence export.
- For third-party risk or GRC tools: check ICT-service-to-function mapping, register workflows, subcontractor tracking, evidence retention, contract and audit-right tracking, access controls, and reporting.
- For either category: assess the deployment and security model, interoperability, operating effort, and data-export or exit terms.
A platform can improve visibility and workflow, but buying one does not satisfy the institution’s responsibility to assess and oversee its own arrangements. No product is established here as tested, endorsed, or capable of guaranteeing compliance.
Account for jurisdiction and related EU guidance
DORA is specifically an EU regime. Institutions operating across borders or subject to multiple financial-services regimes should confirm which entity, service, and jurisdiction each obligation covers rather than applying DORA indiscriminately worldwide.
The European Banking Authority reports that its ICT and security risk-management guidelines were narrowed in view of DORA’s harmonized ICT risk-management requirements, which apply from 17 January 2025; the EBA lists 20 May 2025 as the compliance deadline for the amended guidelines. The Commission’s DORA index lists implementing and delegated acts that can supplement the regulation. Because those materials may be updated, check the current texts and relevant national supervisory guidance when assessing a particular arrangement.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
