DORA ICT third-party map #
For a financial entity, buying a reporting channel is not a software purchase. Regulation (EU) 2022/2554 (DORA) has applied since 17 January 2025, and it makes EthicsPortal an ICT third-party service provider: the engagement runs through your ICT third-party risk process, gets an entry in your register of information, and must carry the contractual provisions in Article 30.
This page supplies provider-side information for that work. It is not legal advice, a compliance certification, a warranty of regulatory suitability, or part of a customer contract. The Financial Entity must verify the information against its own classification, risk assessment and intended use.
The DORA contracting template shows the subjects a bilateral DORA order must cover. It does not bind through publication, subscription, acceptance of the DPA, or a customer’s unilateral classification. A DORA arrangement exists only after both parties sign a scoped order with fixed schedules, assistance rates and transition terms.
DORA does not require a reporting channel. It governs how you procure one. The obligation itself comes from Directive 2019/1937 — which, under Art. 8(4) , applies to entities within the scope of the Union financial-services and anti-money-laundering acts irrespective of headcount — and from the sector rules summarised on the financial services page.
Last updated: 2026-09-13.
How to read this page #
| Status | Meaning |
|---|---|
| DPA / Terms | The cited obligation is already present in the ordinary customer agreement, subject to its scope and limits |
| DORA order required | The item must be completed and incorporated in a bilateral signed DORA order before it becomes contractual |
| Published | The information the provision requires is published on this site and can be lifted directly into your register or assessment |
| Partial | Substantively in place, with a stated limit — the limit is named, not glossed |
| Not offered | Not available. The reason is stated, and the item appears in open items where it is fixable |
Is this service in scope for you? #
Two determinations, in order.
Is it an ICT service? Yes. EthicsPortal is delivered as software-as-a-service and falls under type S19 (Cloud services: SaaS) in the ICT-services taxonomy used by the register of information.
Does it support a critical or important function? That classification is yours to make, not ours to assert. The facts you need to make it:
- The function supported is a statutory compliance obligation, not a licensed activity. Directive 2019/1937 sets a 7-day acknowledgement and a 3-month feedback deadline. EthicsPortal publishes a four-hour recovery time objective, but the full-service recovery path and operator-incapacity response have not been demonstrated against it. Financial entities must assess the continuity impact on their own process.
- The service holds no customer funds, executes no transactions, and sits on no payment, trading, settlement, or core-banking path. It has no integration with your systems: it runs standalone, so it cannot propagate a failure inward.
- It does process information that may be legally protected in your sector, which is why the confidentiality controls below matter regardless of the classification.
The result depends on your documented Article 3(22) assessment, including whether disruption or defective performance would materially impair your continuing compliance. The facts above support that assessment but do not predetermine it. If your assessment treats the Service as supporting a critical or important function, contact EthicsPortal before contracting. The classification does not itself activate additional obligations; the Article 30(3) scope, supplier chain, fees and exit terms must be agreed in a signed DORA order.
Register of information data #
Provider-supplied fields for the register of information under Article 28(3) DORA and Implementing Regulation (EU) 2024/2956. They are a baseline, not a completed register: the financial entity supplies its own arrangement, function, risk, cost and classification fields and validates the relevant ICT service supply chain.
Direct provider #
| Field | Value |
|---|---|
| Legal name | Yaroslav Shmarov, sole proprietor (jednoosobowa działalność gospodarcza), trading as EthicsPortal |
| Registered country | 🇵🇱 Poland |
| Registered address | ul. Obrzeżna 1A, 02-691 Warsaw, Poland |
| Identification code | Polish tax identification number (NIP) 5272755790 |
| Type of identification code | VAT — the ITS code for a VAT number |
| Type of provider | Individual acting in a business capacity |
| Type of ICT service | S19 — Cloud services: SaaS |
| Function supported | Internal reporting channel under Directive 2019/1937 and applicable sector rules |
| Countries from which the service is provided | 🇵🇱 Poland (operator and contractual performance); 🇩🇪 Germany (application and storage infrastructure) |
| Country where data is stored | 🇩🇪 Germany (Nuremberg) |
| Sensitivity of data stored | Assess against your own scheme. Report content, reporter identity and handler messages are encrypted at rest at field level; see Security |
| Reliance on subcontracting | Yes — the provider-side baseline is below; the GDPR inventory is published separately at /subprocessors/ |
| Governing law of the contractual arrangement | 🇵🇱 Poland (Terms §13 ) |
| Provision of service to the entity’s own critical or important functions | The entity’s determination — see scope |
On the identification code. EthicsPortal does not hold a Legal Entity Identifier (LEI). The operator is a sole proprietorship registered in the Polish CEIDG rather than a company in the KRS, so no European Unique Identifier (EUID) is issued for it either. Use the NIP above with code type VAT. An LEI is on the open items list; when one is issued it will be published here.
ICT service supply chain #
The GDPR sub-processor list and the DORA supply chain answer different questions. The table below contains direct providers whose components underpin delivery of the Service. Stripe is used for billing and Cloudflare only for the marketing site; neither supplies the reporting channel and neither is included in this service chain.
Rank 1 is EthicsPortal. Direct providers are shown at rank 2. The public rank-3 examples below show that the chain does not end there; they are not a complete, account-verified register. Where the Service supports a critical or important function, the Financial Entity determines which indirect providers effectively underpin it, and EthicsPortal must complete account-specific validation before accepting the CIF classification.
| Direct ICT provider | Contracting country | ICT service type | Rank | Component and data |
|---|---|---|---|---|
| Hetzner Online GmbH | 🇩🇪 Germany | S17 — Cloud services: IaaS | 2 | Application server, database, file attachment storage — all report data |
| Mailjet / Sinch (contracting entity to verify) | 🇫🇷 France | S19 — Cloud services: SaaS | 2 | Handler and optional reporter notification delivery; reporter email and access code where email is elected, but no report narrative in notification templates |
| AppSignal B.V. | 🇳🇱 Netherlands | S19 — Cloud services: SaaS | 2 | Error and performance telemetry; reporter portal requests are configured for exclusion |
Publicly listed downstream examples include Hetzner Finland Oy for EU hosting support; Google Cloud France for Mailjet infrastructure; US-based Mailgun Technologies for Mailjet support; AWS EMEA and Worldstream for AppSignal storage/hosting; and US-based Mailgun Technologies for AppSignal transactional email. Hetzner DPA Appendix 3 , Sinch sub-processor list , and AppSignal security page describe these roles. A listed US supplier does not prove report content reaches it, but an EU-based direct supplier does not prove an EU-only chain. Legal names, identifiers, parent undertakings, exact provision locations, data access and material downstream ranks must be confirmed against account-specific evidence before submission to a competent authority.
Subcontractor changes are notified at least 30 days in advance, and you may object and terminate if no resolution is reached (DPA §6.4 ).
Article 30(2) — baseline provisions #
These apply to every ICT service contract, whatever the classification.
| Article 30(2) | Requirement | Status | Where |
|---|---|---|---|
| (a) | Description of functions and services; whether subcontracting is permitted and on what conditions | DPA / Terms + order required | The DPA §2 and §8 provide the standard scope and processor chain. A DORA order must fix the covered service and ICT subcontracting conditions |
| (b) | Locations — regions or countries — where services are provided and data is processed, with advance notice of change | Published + order required | Current locations are at /subprocessors/ and Security#infrastructure . The DORA order must fix the applicable locations and change notice |
| (c) | Availability, authenticity, integrity and confidentiality of data, including personal data | DPA / Terms + published | DPA §6.3 and /security/ describe the standard contractual and operational controls |
| (d) | Access, recovery and return of data in an easily accessible format on insolvency, resolution, discontinuation, or termination | Partial + order required | Standard export and DPA return/deletion rights exist. The order must define additional formats, deadlines, contingency arrangements and known incapacity limits; see template §5 |
| (e) | Service level descriptions, including updates and revisions | Published + order required | /sla/ states the standard offering. The order must identify the binding version and change process |
| (f) | Incident assistance at no additional cost, or at a cost determined ex ante | Order required | Ordinary incident notifications and existing information are included. Customer-specific DORA assistance requires included hours and a rate fixed in the signed order; see template §6 |
| (g) | Full cooperation with the entity’s competent authorities and resolution authorities | Order required | The scope and process must be included in the signed order; see template §7 |
| (h) | Termination rights and minimum notice periods | Order required | Ordinary cancellation follows the Terms. DORA grounds and minimum notice periods must be stated in the signed order; see template §9 |
| (i) | Conditions for participation in the entity’s ICT security awareness and digital operational resilience training (Art. 13(6)) | Order required | Format, frequency, included hours and the pre-agreed rate must be stated in the signed order; see template §8 |
Article 30(3) — extended provisions (critical or important functions) #
These topics apply only where the parties’ signed DORA order records the Service as supporting a critical or important function. A unilateral classification does not activate them.
| Article 30(3) | Requirement | Status | Where |
|---|---|---|---|
| (a) | Full service level descriptions with precise quantitative and qualitative performance targets | Published baseline + order required | /sla/ states the standard offering. The signed order must fix binding targets, measurement, reporting and corrective actions |
| (b) | Notice periods and reporting obligations, including developments with a material impact on service delivery | Order required | The signed order must define material developments, reporting content and notice periods |
| (c) | Business contingency plans, tested, and ICT security measures appropriate to the service | Published | Business continuity plan with activation triggers and recovery objectives; information security policy ; risk register . Restore drills run monthly in CI and on demand, with backup freshness monitored continuously (Security ) |
| (d) | Participation in threat-led penetration testing under Articles 26–27 | Order + statement of work required | Scope, safety, responsibility, environment and all charges must be agreed in writing; see template §8 |
| (e) | Unrestricted rights of access, inspection and audit, including by the competent authority | Order required, downstream validation open | The order must preserve the required rights while defining routine logistics and pre-agreed assistance rates. Supplier access exists only where verified; see template §7 |
| (f) | Exit strategies with a mandatory adequate transition period | Order required | The transition length, continued service, exports, migration work, fees, customer cooperation and incapacity limits must be fixed in the signed order; see template §10 |
Article 28 — the surrounding obligations #
| Provision | What it requires of you | What we supply |
|---|---|---|
| Art. 28(1)–(2) | Manage ICT third-party risk within your own framework, proportionate to the arrangement | The published evidence set: security , subprocessors , business continuity plan , risk register , incident register , ISO/IEC 27001:2022 Annex A control map , CAIQ-aligned questionnaire |
| Art. 28(3) | Maintain a register of information and report it to your competent authority | The provider-side baseline above, with the limits and customer-owned fields stated explicitly |
| Art. 28(4) | Pre-contract due diligence and assessment before entering the arrangement | The same evidence set, plus a pre-filled DPIA for the processing itself |
| Art. 28(7) | Termination rights on material breach, supervisory impediment, or weaknesses in ICT risk management | Must be stated in the signed DORA order; ordinary cancellation remains governed by the Terms |
| Art. 28(8) | Document and test an exit strategy — required only for ICT services supporting a critical or important function | Customer-owned obligation; standard exports support it, while a binding transition period requires a signed DORA order |
| Art. 29 | Assess ICT concentration risk before contracting | Concentration is at the infrastructure layer: report data sits with a single IaaS subcontractor in one region. That is stated plainly rather than obscured, so it can enter your assessment |
Open items #
Published because a gap that is named can be assessed, and one that is glossed over will be found later.
| Item | Why it matters | Status |
|---|---|---|
| Legal Entity Identifier (LEI) | Your register of information prefers an LEI or EUID; neither exists for a Polish sole proprietorship today, so the NIP is used as an other identifier | Being obtained |
| Executed DORA order | Article 30 requires the full arrangement to be documented in one written and durable record | Template published ; scoped bilateral signature required before any DORA commitment applies |
| CIF subcontractor validation | Regulation (EU) 2025/532 requires identification of the material service chain and pass-through access, inspection and audit rights | Provider-by-provider evidence and downstream ranks must be verified before a CIF order is signed |
| Operator-incapacity protocol | Article 30(2)(d) access and return in the discontinuation case | In treatment — BCP §8 , risk register R-01 |
| Independent penetration test | Asked by every regulated-finance assessment | None on record — /trust/ |
| Cyber liability insurance | Asked by every regulated-finance assessment | Under review — /trust/ |
Poland: the withdrawn UKNF cloud communication #
The UKNF communication of 23 January 2020 on the processing of information by supervised entities in public or hybrid cloud computing — the komunikat chmurowy — was withdrawn on 17 January 2025, the day DORA became applicable. KNF withdrew it alongside the sector IT-management resolutions (resolution 6/2025 repealing 7/2013, which issued Recommendation D for banks; 7/2025 repealing 615/2016; 8/2025 repealing resolutions 409–411 and 413/2014), on the stated ground that their subject matter overlaps the obligations arising from DORA and its implementing acts.
Practically: the 14-day pre-notification to UKNF and the Annex 1 form no longer apply. Your obligations run through DORA and the register of information instead.
Many internal cloud policies, vendor questionnaires and sector rankings still carry the komunikat’s checklist. The mapping below is kept for that reason, and for that reason only — it describes a standard that is no longer in force.
| Komunikat requirement | EthicsPortal position |
|---|---|
| VII.4.1(a) — division of responsibility for security, continuity, RTO/RPO, declared SLA with measurement method | /sla/ : 99.5% monthly, RPO 24h, RTO 4h, externally measured. Processor/controller split in DPA §2 |
| VII.4.1(b) — clear definition of processing locations and how they are verified | Nuremberg, Germany, named per component at Security#infrastructure and /subprocessors/ |
| VII.4.1(c)–(e) — governing law and venue; GDPR conformity; ownership of processed information | Polish law, Warsaw courts (Terms §13 ); DPA under Article 28 GDPR; customer data returned or deleted at the customer’s choice (DPA §6.8 ) |
| VII.4.1(f)–(g) — guarantees, insurance, liability limits | Liability capped at 12 months of fees (Terms §11 ); no cyber liability policy in place — see open items |
| VII.4.1(h)–(i) — subcontractors named with location and scope, and their accountability made transparent | /subprocessors/ and DPA §8 ; the provider answers for its subcontractors as for itself (DPA §6.12 ) |
| VII.4.1(m)–(n) — right of inspection, and the supervisor’s right to carry out its control duties | DPA §6.9 provides standard GDPR audit cooperation. DORA-specific authority rights require a signed order and downstream validation. Documentary and remote — no own premises exist to inspect |
| VII.4.1(q) — rules and deadlines for the return or deletion of processed information | DPA §6.8 |
| VII.4.1(s) — exchange of information on security and incident management | Breach notification without undue delay after awareness (DPA §6.6 ); public incident register |
| VII.6.1 — provider conformity with ISO 20000, 27001, 22301, 27017, 27018 | Not certified. Published instead: an ISO/IEC 27001:2022 Annex A control map covering all 93 controls with status and evidence. The infrastructure subcontractor holds ISO 27001 certification under its own scope |
| VII.6.2 — data centre to EN 50600 class 3 or ANSI/TIA-942 Tier III | Not evidenced. Hetzner’s ISO/IEC 27001 certification is not evidence of EN 50600 class 3 or ANSI/TIA-942 Tier III. The supervised entity would have had to accept the gap on a documented risk basis |
| VII.6.3 — data centre located in the EEA | Core application, database and attachment storage: Nuremberg, Germany. This does not establish an EU-only email or telemetry supplier chain; see international transfers |
| VII.6.4 — default no access; least privilege for service work; tenant separation; secure-by-default | Privileged access is limited to the named operator; controls can be described during procurement review. Defined report and account events are written to an append-only audit trail, but individual reads and every access are not logged. Report content, reporter identity and messages use non-deterministic field encryption, and tenants are logically separated (Security ) |
| VII.7 — encryption at rest and in transit; key management | Partial. TLS protects transport and defined report fields use application encryption, but backup dumps and attachments are not encrypted as whole objects at rest (Security#data-encryption ). Keys are processor-managed; customer-managed keys are not supported (DPA §6.11 ) |
| VII.8 — logging, log protection, MFA for privileged access | Append-only audit trail at database level; two-factor authentication available for handler and admin accounts (Security ) |
| IX — notification to UKNF before processing begins | No longer applicable following the withdrawal |
What to ask for next #
Materials available for controlled procurement review include the DPA template, registry and tax evidence, a security questionnaire, a privileged production-access summary, and written business-continuity and offboarding answers. An executed DPA can be supplied for the contracting customer. Request available materials at support@ethicsportal.eu .
For the whistleblowing obligation itself rather than its procurement, see financial services and e-money and payment institutions .
Last updated: