> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/dora.md). # DORA What the Digital Operational Resilience Act asks of a financial entity and its software, how Heeler assesses the technical part of it, and how to adopt it. The **Digital Operational Resilience Act** (DORA), Regulation (EU) 2022/2554, sets the ICT risk rules for EU financial entities. Heeler assesses the part of DORA that your software can show evidence for, and records the rest as statements from your organization. {% hint style="warning" %} DORA is off by default until an Administrator adopts it. The evidence Heeler selects for each requirement is Heeler's reading of the regulation, cross-referenced to CIS Controls v8.1 where CIS publishes a mapping. See [Crosswalk](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#crosswalk). The assessment is readiness evidence, not a compliance determination. {% endhint %} ## What DORA is DORA applies to EU financial entities: banks, insurers, investment firms, payment institutions and others. Through their contracts it also reaches their **ICT third-party service providers**, which is how it reaches many software companies. Most of DORA is about the entity, not its code: governance, incident reporting, resilience testing and the management of suppliers. The technically verifiable part is **Commission Delegated Regulation (EU) 2024/1774**, the regulatory technical standards (RTS) on ICT risk management. Its Articles 10 (vulnerability and patch management), 16 (ICT systems acquisition, development and maintenance) and 17 (ICT change management) are where most of Heeler's evidence applies. For financial entities, DORA sets no fine amounts: each Member State sets its own administrative penalties (Article 50). A provider designated as a critical ICT third-party service provider can receive a periodic penalty payment from its Lead Overseer, of up to 1% of its average daily worldwide turnover (Article 35). ## DORA in Heeler Heeler holds 73 DORA requirements, with text reproduced verbatim from the Official Journal: * **Chapters** are the pillars of DORA: ICT risk management framework, ICT-related incident management, digital operational resilience testing, ICT third-party risk, and information sharing. * **Sections** are the DORA articles and the RTS topics within each pillar. * **Requirements** are points of DORA and of the RTS. Keys show where each one comes from: **A24.6** is DORA Article 24(6), **RTS16.4** is RTS Article 16(4). DORA has two cumulative levels: | Level | Requirements | For | | -------------- | ------------ | -------------------------------------------------------------------------------------------------- | | **Simplified** | 57 | Entities that use the simplified ICT risk management framework of DORA Article 16 (RTS Title III). | | **Full** | 73 | Every other financial entity (RTS Title II). Contains every Simplified requirement. | The Simplified level reuses the Title II wording of each provision. An entity under Article 16 is bound by Article 16(1)(a)-(g) and RTS Title III (Articles 28-41); the level marks which Title II provisions have a Title III counterpart, so an auditor of a simplified-framework entity reads the level as the scope of what Heeler assesses, not as the citation to quote. **Full** is the default target level. Two attributes change how DORA reads: | Attribute | Where | What it does | | --------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Article 16 simplified-framework entity** | The tenant, under Administration > Program > Standards | Records that your organization is an Article 16 entity: small and non-interconnected investment firms, institutions exempted under Directive 2013/36/EU, exempted payment and e-money institutions, and small IORPs. Set the target level to **Simplified** to match. | | **Supports a critical or important function** | Each application's Standards tab | Records that the application supports a critical or important function (DORA Article 3(22)). The RTS sets stricter rules for such assets, such as six-monthly firewall and access reviews. | Some requirements apply only to ICT assets that support a critical or important function. On an application without **Supports a critical or important function**, those requirements read **Not applicable**, and the requirement's detail says *Applies when Supports a critical or important function is true*. Strong authentication (RTS 21(1)(f)(ii)) and vulnerability scanning (RTS 10(2)(b)) are assessed on every application. The regulation binds publicly accessible assets and scanning commensurate to classification whatever the function. Heeler checks that SAST, dependency and secret scans ran in the last 30 days, and the requirement caps at Partial because ICT assets are wider than repositories. The weekly floor for critical-function assets is not assessed separately; record it as an attestation if an auditor asks. The firewall and access reviews (RTS 13(1)(h), 21(1)(e)(iv)) keep the critical-function gate. ## Adopting DORA DORA is off until an **Administrator** turns it on: 1. Under **Administration > Program > Standards**, turn on **Adopted** on the DORA card. 2. Set **Default for applications** to **On** to assess every application, or turn on **Assessed** on each application's Standards tab instead. 3. Set **Article 16 simplified-framework entity** and the **Target level** if they apply to you, then select **Save**. See [Standards](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/standards.md). ## Automated, attested and not applicable DORA requirements fall into two groups: * **Technical requirements** that Heeler assesses from evidence: vulnerability management, scan cadence, SBOM and library tracking, remediation SLOs, source code integrity through OpenSSF Scorecard checks, change gates through enforced guardrails, and end-of-life components. 30 of the 73 requirements have automated evidence. * **Organisational requirements** that no code signal can show: governance, incident management and reporting, threat-led penetration testing, contracts with ICT providers and oversight. These read **Manual** until someone attests to them. DORA is entity-level, so most organisational requirements are **attested once for the tenant**. One tenant-wide attestation covers every application, and an Administrator can still mark the requirement not applicable for one application. A few organisational requirements differ per application (for example, separation of environments) and are attested on each application. Coverage leaves not-applicable requirements out of the denominator, and counts attested requirements separately from verified ones. See [Dispositions](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#dispositions). Each technical requirement also shows a [crosswalk](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#crosswalk) to the CIS Controls v8.1 Safeguards behind its evidence. The CIS mapping to DORA covers the regulation's articles but not the RTS, and it leaves the application security Safeguards unmapped. So most technical requirements carry a **Heeler reading**, and the entries that CIS publishes are the ones a reviewer can check against CIS directly. ## If you are a supplier to a financial entity If you sell software to a bank or other financial entity, the entity must check how its ICT suppliers handle vulnerabilities, track open-source libraries and test code before production. The requirements behind those checks are RTS Articles 10(2)(c), 10(2)(d), 10(2)(e), 16(3), 16(4), 16(7) and 16(8), and a DORA assessment of your application shows where you stand on each. The **Supplier evidence pack** is a [report view](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/compliance-reports.md#report-views). On the application's Standards tab, select **Generate Report**, choose **Supplier evidence pack** under **View**, pick PDF or CSV, and select **Generate pack**. The pack carries only the eight RTS requirements a financial entity verifies about a supplier: 10(2)(c), 10(2)(d)(i) and (ii), 10(2)(e), 16(3), 16(4), 16(7) and 16(8). The PDF's **Selected requirements** tile and score are computed over those requirements, and its cover carries a scope note that says so. The CSV holds the same eight rows and nothing else; it has no cover, so the scope is the filename. The application's CycloneDX SBOM downloads beside either format as a second file, and the PDF cover names it with its generation time. If the SBOM cannot be fetched, the report still downloads and the dialog says so. ## Enforcing Two bundles turn the DORA controls Heeler can enforce into pull-request guardrails: | Bundle | Controls | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Enforce DORA (simplified framework)** | Cryptography findings and overdue vulnerability SLOs. | | **Enforce DORA (full framework)** | Everything in the simplified framework, plus critical vulnerabilities with a fix, exposed secrets and injection findings. | See [Guardrail Bundles](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md). ## Related * [Assessments](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md): how Heeler scores an application, and how dispositions work. * [Standards](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/standards.md): adopting the standard and setting the tenant attribute. * [Compliance Reports](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/compliance-reports.md): the assessment as a document, with the DORA disclaimer on its cover. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/dora.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.