DORA Compliance Mapping
Last updated: October 2026
§1. Purpose
This page explains how HumanKey helps financial-entity customers meet their obligations under the Digital Operational Resilience Act (Regulation (EU) 2022/2554), which entered into application on 17 January 2025.
HumanKey is not itself a financial entity within the meaning of DORA Art. 2(1). When a financial entity uses HumanKey, HumanKey is classified as an ICT third-party service provider under DORA Art. 3(19), and the customer's ICT third-party risk management framework (Art. 28) applies to the HumanKey engagement.
§2. Current designation status
HumanKey is NOT currently designated as a Critical ICT Third-Party Provider (CTPP) by the European Supervisory Authorities (EBA, EIOPA, ESMA). CTPP designation criteria are set out in Commission Delegated Regulation (EU) 2024/1502 and apply to a limited number of pan-European ICT providers whose services are used by a large proportion of the European financial sector. HumanKey expects to remain outside the CTPP perimeter for the foreseeable future, which means HumanKey is subject to the Controller's ICT TPRM framework under Art. 28, but not to the direct oversight regime in Art. 31-44.
§3. Article-by-article mapping
The following table maps the principal DORA provisions relevant to an ICT third-party service provider to the corresponding HumanKey contractual provision or documented practice.
| Article | DORA requirement | HumanKey contribution |
|---|---|---|
| Art. 28(1) | ICT third-party risk management as part of the ICT risk management framework | HumanKey provides the Register-of-Information inputs required by the Controller's framework: service description, data location, sub-contracting disclosure, and function-criticality flag on request. |
| Art. 28(1)(b) | ICT third-party risk managed in light of the principle of proportionality (nature, scale, complexity and importance of ICT-related dependencies) | Before a sub-processor of Controller data is added or replaced, the Controller is informed in advance by e-mail and on the register page and may object (DPA, Section 5.4). |
| Art. 28(3) | Register of Information on all contractual arrangements | HumanKey's published Sub-Processors page is the authoritative source for HumanKey's own onward ICT service chain. Before a sub-processor of Controller data is added or replaced, the Controller is informed in advance by e-mail and on the register page and may object (DPA, Section 5.4). |
| Art. 30(1) | Rights and obligations of the parties clearly allocated and set out in writing | HumanKey's DPA establishes the parties' rights and obligations in writing and is offered to every Controller regardless of tier. |
| Art. 30(2)(a) | Clear and complete description of functions and ICT services to be provided | Article 3 of the HumanKey DPA describes the nature and purpose of processing. HumanKey's public product documentation at humankey.io/docs supplements this description. |
| Art. 30(2)(b) | Locations where functions and ICT services will be provided and data processed | Primary data storage is within the European Economic Area (Neon Postgres Frankfurt, Railway Amsterdam). Sub-processor locations are documented on the Sub-Processors page and assessed in the public TIA. |
| Art. 30(2)(c) | Provisions on availability, authenticity, integrity and confidentiality of data | HumanKey DPA Article 5 (Processor Obligations), in particular Article 5.3 (Technical and Organisational Measures), documents the controls in place. |
| Art. 30(2)(d) | Access, recovery and return of personal and non-personal data on insolvency, discontinuation of business or termination | DPA Section 5.7 sets out deletion or return of Controller personal data: the Controller can download its data before deleting the account, and the data is deleted from the Service when the account is deleted; backups expire on the database provider's cycle. JSON export is available on demand throughout the engagement, and GDPR data-subject rights tooling (JSON export, cascading deletion, rectification) also covers this obligation. |
| Art. 30(2)(e) | Service level descriptions | The Service is described in Section 3 of the Terms of Service and in Article 3 of the DPA. The Terms promise no particular level of availability (Section 11); for Enterprise plans, a service level can be agreed individually. HumanKey is not currently designated as a Critical ICT Third-Party Provider. |
| Art. 30(3)(a) | Full service level description with precise quantitative and qualitative targets (CIFs) | The standard Terms set no quantitative or qualitative service-level targets (Section 11). For Enterprise plans, a service level can be agreed individually. A Controller that needs such targets for a critical or important function should take this into account in its own assessment. |
| Art. 30(2)(g) | Obligation to cooperate with the competent and resolution authorities of the financial entity | Committed in §4 below. HumanKey cooperates with the Controller's competent authority within the meaning of DORA Art. 30(2)(g). |
| Art. 30(2)(h) | Termination rights and related minimum notice periods | If the Controller objects to a sub-processor change that goes ahead, it may cancel the subscription and end the contract by deleting the account (DPA, Section 5.4); the contract can also be ended under Section 12 of the Terms. |
| Art. 30(3)(b) | Notice periods and reporting obligations of the ICT third-party service provider to the financial entity | HumanKey notifies the Controller of a personal data breach without undue delay (Art. 33(2) GDPR; DPA Section 5.6). Cooperation with the Controller's upstream DORA Art. 17 reporting timelines is committed in §5 below. |
| Art. 30(2)(a) — subcontracting | Whether subcontracting of ICT services supporting critical or important functions is permitted, and the conditions applying | Before a sub-processor of Controller data is added or replaced, the Controller is informed in advance by e-mail and on the register page and may object (DPA, Section 5.4). |
| Art. 17 | Management of ICT-related incidents (classification, reporting, response) | HumanKey's breach notification (see the Art. 30(3)(b) row above) feeds into the Controller's internal incident management so the Controller can classify and, where required, report major ICT incidents to the competent authorities within the DORA timelines. |
§4. Cooperation with competent authorities
HumanKey cooperates with the Controller's competent authority within the meaning of DORA Art. 30(2)(g). HumanKey provides reasonable assistance to the Controller in responding to supervisory inquiries regarding HumanKey's processing activities, subject to applicable confidentiality obligations and HumanKey's review of each request.
Cooperation requests should be routed through the HumanKey legal contact form at humankey.io/contact, selecting the "Legal & Compliance" or "Security" category as appropriate. HumanKey aims to acknowledge receipt within two (2) business days and to provide a substantive response within the timeline communicated to the Controller by the competent authority.
§5. Incident notification flow
DORA Art. 17 requires financial entities to establish an ICT-related incident management process, classify incidents, and notify competent authorities of major ICT-related incidents within the timelines set out in the delegated Regulatory Technical Standards.
HumanKey supports the Controller's upstream notification flow as follows:
- HumanKey notifies the Controller without undue delay upon becoming aware of a Personal Data Breach affecting Controller Personal Data, as required by Art. 33(2) GDPR (see DPA Section 5.6).
- The notification includes the information required by GDPR Art. 33(3) insofar as known at the time: nature, categories and approximate number of affected data subjects, likely consequences, and measures taken or proposed.
- HumanKey provides reasonable cooperation to enable the Controller to meet the Controller's own DORA Art. 17 reporting timelines, while preserving HumanKey's own internal incident response procedures and the confidentiality required by ongoing forensic work.
- HumanKey does not issue any public announcement about such an incident without the Controller's prior written consent, unless required by applicable law.
§6. What HumanKey does NOT yet commit to
In the interest of honesty and to avoid creating expectations HumanKey cannot meet today, the following items are explicitly out of scope for this public mapping:
- HumanKey is not currently ISO 27001 certified. A documented Internal Compliance Roadmap is available to financial-entity prospects on written NDA request.
- HumanKey is not currently SOC 2 Type II reported. The same Internal Compliance Roadmap covers the planned path toward this assurance mechanism.
- HumanKey is not currently designated as a Critical ICT Third-Party Provider (designation criteria are set out in Commission Delegated Regulation (EU) 2024/1502) and is therefore not subject to the direct ESAs oversight regime in DORA Art. 31-44.
- This mapping does not purport to be legal advice. Financial-entity Controllers should review it together with their own legal counsel and map it back to their internal ICT TPRM framework.
This DORA Compliance Mapping is provided as a public positioning document. It supplements but does not replace the HumanKey Data Processing Agreement. Last updated: October 2026.