Resilience the supervisor can read
DORA has applied to banks, payment institutions, investment firms, insurers and the other financial entities it lists since 17 January 2025. It asks for evidence rather than policies: an inventory of ICT assets, systems that are tested, and a register of every ICT third party. We answer those obligations with a source-code audit, four products and engineering squads that build with the record in mind.
The difference from the regimes before it is the form of the answer. A policy says what should happen; DORA asks what did, on which system, tested when and by whom. Everything on this page exists to produce that record.
Article by article
Regulation (EU) 2022/2554. The provisions a technical supervisor asks about first, and what of ours answers each one.
| Provision | What DORA requires | What we bring |
|---|---|---|
| Art. 8Identification | Identify and document every ICT asset and the dependencies between them, and keep that inventory current. | Ibex discovers the hosts on your network segments, including the ones no cloud agent can reach, and keeps one record per device, compared against your baseline. Buteo keeps the inventory of the outside: the subdomains, services and certificates your domains show the internet. |
| Art. 9Protection and prevention | Encryption, patching, access control and secure configuration, with the security of ICT systems monitored continuously. | Ibex checks what your databases allow against a set of rules, and the code audit reads whether the secure development rules held. Both leave the appliance as files the auditor can keep: SARIF findings and the audit PDF. |
| Art. 24(6)Testing, at least yearly | Every ICT system supporting a critical or important function is tested at least once a year. | Goshawk runs the code audit on demand, so the yearly test is a scheduled run rather than a procurement. |
| Art. 25(1)Source code review | A resilience testing programme that includes source code reviews where feasible. | The Security Audit: a manual review, scored with CVSS v4.0, in a form the testing programme can file. |
| Art. 28Third-party risk | A register of information on every ICT third-party provider, and an assessment of the risk each one carries. | An audit of the application a supplier delivers, before acceptance or renewal, is evidence for that assessment that does not depend on the supplier's word. |
| Art. 30Audit rights down the chain | Contractual rights of access, inspection and audit over providers supporting critical or important functions, and over their subcontractors. | A cloud model you escalate to is a provider you cannot audit. Marmot decides per request what may reach it, and its decision log reconciles against your own firewall. |
The Security Audit page maps the same review to NIS2 and its implementing regulation, for the obligations a financial entity carries outside DORA. For Portugal, who supervises, the incident deadlines, the fines under Lei n.º 73/2025 and a self-check are on DORA in Portugal.
Where we are typically brought in
ICT asset inventories and resilience evidence for DORA supervision
Digital lending, treasury and wealth portals with compliance built in
Payments modernisation and Open Banking connectivity
When the answer is software we build
Some obligations are met by a product and some by a portal, an API or a workflow that does not exist yet. For those we embed product, design and engineering squads with your team, on top of the banking stack you already run, in partnership with risk, compliance and security.
Co-design sprints with risk, compliance and operations, so the evidence DORA asks for is designed in rather than reconstructed later
Custom portals, APIs and workflow tools layered on top of your core banking or payment systems
Open Banking and PSD2 connectivity, reused where it fits
Secure development an auditor can follow: documentation, testing and an SDLC that leaves the record the ICT risk framework expects
Long-term teams that stay with the product after launch, because resilience is measured after go-live
Telemetry built in, so adoption and incidents are measured rather than guessed
The products behind the table
Ibex for the inventory and the posture inside, Buteo for what your domains show the internet, Goshawk for the code, and Marmot for the AI that must not become a third-party provider.
Ibex
Security for the networks the cloud can't reach
Air-gapped attack surface management: network, code, AI and databases assessed from one sealed appliance inside your perimeter, with findings tied to the host they run on.
Learn More about Ibex
Buteo
External attack-surface auditing
The outside view of your domain as a service: DNS and email posture, TLS, headers, subdomains and ports, scored, tracked and compared scan to scan.
Learn More about Buteo
Goshawk
Only what survives refutation ships
Security audits of your repositories as an application: automated scanning with its limits stated in writing, and a full tier with senior human verification.
Learn More about Goshawk
Marmot
Sovereign AI with a Gate
On-premises AI with a per-request gate that decides what may reach a cloud model, and what never leaves the building.
Learn More about Marmot