DORA software for a startup should be selected against the entity’s actual regulatory obligations and operating model. A small headcount does not automatically qualify a payment institution, electronic money institution or other fintech for the simplified ICT risk management framework. Establish the legal scope first, then ask vendors to demonstrate the records, decisions and operational evidence your team must maintain.
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 2 determines scope and exclusions, Article 4 addresses proportionality, and Article 16 identifies specific categories eligible for the simplified framework. Funding stage is not a legal classification. This guide provides a procurement workflow without unverified vendor rankings, price ranges or promises that a short document set guarantees compliance.
Separate proportionality from Article 16 eligibility
Proportionality affects how applicable requirements are implemented in light of the relevant circumstances. It does not turn every small financial entity into an Article 16 entity. Check the actual authorisation, exemption and statutory category of the business. A commercial description such as fintech platform or seed-stage startup cannot replace that analysis.
Article 16 lists small and non-interconnected investment firms; payment institutions exempted under the relevant payment services framework; certain institutions exempted under the capital requirements framework where the specified Member State option is not used; exempted electronic money institutions; and small institutions for occupational retirement provision. The definitions and conditions attached to those categories matter. A standard payment authorisation and a qualifying exemption are different facts.
ESMA’s published explanation of Article 16 confirms that the exemption concerns Articles 5–15 and the design of a simplified ICT framework for the listed categories. It does not mean that every other DORA obligation disappears. Record the exact category and supporting evidence, and assess the remaining requirements separately. Being a microenterprise is not, by itself, a universal route into Article 16.
Build a short scope record before requesting demonstrations
| Decision | Evidence to collect | Procurement consequence |
|---|---|---|
| Entity status | Legal entity, authorisation and relevant exemption | Identify the actual obligation owner |
| Applicable regime | Article 2 analysis and Article 16 conditions where relevant | Select the correct framework and workflow |
| Critical operations | Services, dependencies and potential disruption | Prioritise evidence that supports important activities |
| ICT suppliers | Contracts, services, subcontracting and locations | Define register and supplier-management needs |
| Incident obligations | Classification, reporting rules and competent authority | Specify configurable escalation and reporting support |
| Testing | Applicable resilience requirements and any authority selection | Avoid assuming a startup label excludes advanced testing |
| Governance | Responsible management body and delegated operational roles | Define approval, review and evidence access |
Treat uncertain answers as open questions with a named owner. Do not ask the vendor to solve an unspecified regulatory classification through a product questionnaire. The tool may help organise the assessment, but the business still needs a supported decision. Preserve the source and date so that a licence change, acquisition or new activity can trigger reassessment.
Hypothetical example: a small payment business
A fictional company with fifteen staff plans to buy a DORA platform. Its first brief assumes that its size entitles it to the simplified framework. The compliance owner checks the company’s actual authorisation and finds that the assumed qualifying exemption has not been established. The brief is corrected before vendors configure an inappropriate framework. This example illustrates the decision process and does not classify any real institution.
The team then maps its payment service, hosting dependency, operational support and incident contacts. It asks which records it must maintain under the applicable regime and who will keep them current. The product demonstration uses synthetic supplier records rather than confidential customer files. Every required feature is linked to a real task: add a contract, assess a dependency, record a decision or export evidence.
After the demonstration, the team documents observed functionality and unresolved questions. It does not declare compliance because the dashboard is green. A feature that is available only in a higher subscription tier remains outside the current offer until confirmed. A promised future feature is recorded as a delivery dependency, not an existing control.
Demonstrate the register with a realistic supplier change
Use one ICT contract and a service that the business understands. Ask the vendor to show the relevant register fields, relationships between entities and services, and validation of the intended export. Check how contract changes and subcontracting information are maintained. A flat list of supplier names is different from a structured register with the required relationships.
Then change a material detail, such as the service supporting an important function or the responsible contract owner. Observe what must be reviewed and who receives the task. Confirm that the old record remains distinguishable from the current record where history is needed. The Register of Information workflow provides a related starting point for understanding the data structure.
Ask whether the export included in the proposal matches the current applicable reporting specification and the receiving authority’s process. Obtain evidence for the offered version rather than accepting a generic claim that a product is EBA-ready. A successful export should preserve the necessary meaning and relationships, not merely produce a file with the expected extension.
Check incident support without reducing DORA to one clock
The operational workflow must distinguish detection, classification, notification and subsequent reporting. Applicable reporting standards and exceptions need to be checked against the current rules and competent authority instructions. A single generic 24-hour reminder does not demonstrate correct handling of all triggers or report stages. The incident-reporting guide can support the internal mapping, which should retain links to the current primary requirements.
Run a hypothetical incident through the proposed system. Can the on-call person record known facts while estimates remain uncertain? Can the responsible role approve the classification and preserve its basis? Can later information update the report without erasing the earlier record? These functions support a real response, while a static incident form may cover only one part of the process.
Keep GDPR breach decisions separate where personal data are involved. The same technical event can engage different thresholds, recipients and deadlines. Reusing factual evidence can help, but one completed report does not automatically discharge every reporting obligation. The DORA and GDPR overlap analysis explains the need to coordinate distinct assessments.
Match testing and governance to the actual requirements
Do not assume that all startups are automatically outside threat-led penetration testing. Article 26 and the applicable selection framework must be considered, including competent authority identification and relevant exclusions. General resilience testing also needs its own scope and evidence. The procurement brief should reflect the business’s established position rather than a funding-round stereotype.
Ask how findings become assigned corrective actions and how completion is verified. A report uploaded to a folder does not show whether the weakness was fixed. The resilience-testing workflow is a related resource for separating assessment, findings and follow-up. Keep the evidence proportionate and protect technical details that could expose weaknesses.
Management responsibility remains with the entity. Software can make approval history and unresolved issues visible, but cannot substitute for the relevant body’s decisions and oversight. Specify which users may prepare, approve and review records. Confirm how the team will operate during absence or turnover, when a single founder or compliance employee may otherwise become a bottleneck.
Compare written prices for the same scope
There is no verified market-price survey or vendor quotation behind this article. Request written offers for the same number of entities, users, supplier relationships and required workflows. Separate subscription, implementation, migration, training, support, integrations and exit costs. A lower annual licence may exclude substantial work that another offer includes.
Include internal effort in the comparison. Someone must obtain contract information, assess dependencies, resolve gaps and maintain decisions. Automation claims should be tested against those tasks. Ask what still requires manual work and what happens when source information changes. Avoid converting an illustrative internal budget into a claimed market benchmark or an unsupported return-on-investment figure.
A spreadsheet-based process may remain workable in a genuinely limited scope if the entity can maintain required structure, control changes and produce usable evidence. A dedicated platform may become justified by volume, collaboration or reporting complexity. The choice should follow demonstrated needs. Neither a spreadsheet nor an enterprise suite is inherently correct solely because the company is young.
Assess the software provider as part of the ICT environment
The compliance platform can itself become an ICT dependency and may hold personal data, confidential contracts and incident details. Determine its role, access, subcontractors, hosting, recovery arrangements and exit capabilities. If it processes personal data on the entity’s behalf, assess the relevant GDPR processor arrangements as well. Purchasing a compliance product does not exempt that service from supplier due diligence.
Review the ICT third-party risk workflow when defining the provider assessment. Ask how data can be exported, how attachments and history remain readable and how copies are removed at termination. Test the ordinary export before relying on it as an emergency exit route. Record limitations and their operational consequences in the purchase decision.
Close procurement with a bounded acceptance decision
The final record should state the applicable regime, required tasks, demonstrated capabilities, missing evidence, contractual scope and conditions before production use. Assign each remaining condition to an owner and define a verifiable outcome. An accepted commercial proposal should not silently be treated as legal approval for an unresolved processing activity or supplier arrangement.
After deployment, follow one actual, limited workflow from input to decision and export. Confirm that staff can update records, receive relevant tasks and explain the evidence without the salesperson’s help. Reassess when authorisation, services or dependencies change. A useful purchase supports continuing work and clear responsibility; it does not confer a permanent label of compliance on the startup.
Primary sources checked 8 September 2026: the DORA legal text and ESMA’s Article 16 explanation linked above. The worked example is hypothetical. No vendor functionality, quoted price or regulatory approval is asserted for a named product.