Subscribe now

It took me a while to notice that the list never got shorter. Close ten risks, the business opens twelve. A new product, a new market, a new partner, a new piece of software someone in finance already signed up for. The work wasn’t reducing the risk to zero. The work was deciding which risks the company would carry on purpose, and making sure someone owned that decision.

That sounds like a small reframe. In practice it changes almost everything about how you do the job.

It became concrete for me in a conversation with a founder I reported to. I came in expecting us to talk about a specific exposure I wanted closed. That wasn’t the conversation he wanted. What he was actually asking for was a plan and a measurable before-and-after, evidence that we were moving in a direction, not a single fire put out. He wasn’t asking for a technical explanation, and he wasn’t asking me to make a particular risk disappear. He was asking me to show him progress he could see. I’d been about to hand him a closed ticket. What he needed was a trajectory.

Here is the distinction I keep coming back to. Fixing a vulnerability can be a technical act. You can do it alone, with tools, on a Friday afternoon. Deciding what the company does about the business risk underneath it is a governance act. It needs someone with the authority to say “yes, we accept this,” and a record that they said it. The first feels productive. The second is the one that holds up when something goes wrong and people ask who decided.

The trap for security people is that we are usually better at the first than the second. We came up through systems. Saying no to a firewall change is easy; the firewall doesn’t have a budget meeting. Saying to a board, in writing, with your name on it, “I recommend we accept this risk for the next two quarters, here’s why, and here’s what would make me change my mind” is a different muscle. Most of us build it late.

My own sharpest lesson here didn’t come from saying no. It came from not insisting. Early in a role I’d joined as the new security lead, I started where I always do: assessing how mature the processes and controls actually were. One of those checks was simple, what traffic was really going in and out of the network. The person who had effectively hired me, the CTO, pushed back: why do you need that, everything here is fine. I was new, I deferred, I moved the check down the list. A few weeks later it turned out that how he was using the infrastructure was exactly the kind of thing that check existed to catch. I would have found it earlier if I had trusted my own assessment instead of the person who hired me. So when I talk about a security leader’s right to say no, I mean something narrower and harder than vetoing changes: the duty to keep asking your own questions even when the most senior person in the room tells you not to. Sometimes “no” is just “I’m still going to look.”

A few things I try to hold onto, for whatever they’re worth:

• A risk you accept deliberately is safer than one you’re carrying without knowing it. A documented, owned, time-bounded acceptance can be reviewed. A fix you marked done without recording what was left over has no owner and no review date, and those are the ones that come back.

• “It’s handled” is not a risk position. It’s a feeling. A position has an owner, a rationale, and a date it gets looked at again.

• The goal isn’t a smaller risk list. It’s a list the management body can actually see. A leader who hands the board ten risks they understand has done more than one who quietly carried fifty.

None of this means I stopped closing things. Patches still matter; weak controls are still weak. And I want to be careful here, because “manage the risk, don’t just remove it” is easy to twist into “so I can leave things open and call it accepted.” That is not the failure I actually see. What I see is closer to the opposite: teams that don’t document at all, close only what is on fire, and leave the quieter risks both unfixed and unrecorded, no owner, no review date, nothing. In most of the teams I’ve seen up close, it isn’t deliberate neglect. They’re buried in operational routine because the process, the planning and the communication underneath were never built, so from the outside it looks like neglect. They miss the business risks not because they don’t care, but because they aren’t speaking the same language as the business, or they’ve been pushed so far from it that “doing the technology” starts to look like the whole job. In that world, managing risk isn’t permission to do less. It’s the thing that drags the quiet risks into the open where someone can finally own them. And an acceptance isn’t a waiver: signing one doesn’t move what the law, the regulator, or the contract already requires of you.

What changed is what I think the job is. I used to measure myself by what I had eliminated. Now I think a security leader’s real output is a smaller, stranger thing: a set of decisions the company made with its eyes open, that someone owns, that someone can defend. Most of the value isn’t in the risks you removed. It’s in the ones you chose to keep, and the fact that choosing was deliberate.

Share

You don’t get a clean scoreboard for that. The risks are still there, and they still belong to the company, not to me. What changed is that each one has a name against it and a date it gets looked at again. Chosen, not inherited. That’s the difference between running security and just reacting to it.

• Your first year of security is a time-boxed build project (gap analysis, policies, incident response, vendor risk register, DORA Register of Information), not an ongoing operations function. Plan it like a product launch.

• After the build phase, ongoing security maintenance for a 30-100 person fintech runs 10-15 hours per week. That’s not a full-time CISO job.

• Three options to close the function: full-time CISO, fractional/vCISO, or security engineer + compliance consultant. The right choice depends on your stage, not your ambition.

• The most expensive mistake isn’t overpaying. It’s hiring someone who builds the wrong framework and you discover it during your first regulatory inspection.

• EU regulators (Latvijas Banka, Bank of Lithuania) are prioritizing ICT governance, business continuity, and the DORA Register of Information in 2025-2026 supervision cycles. Know what they look for before they arrive.

Subscribe now

You just got your EMI license. Or your PI authorization. Or maybe you closed a Series A and the term sheet had a line about “information security governance” that you nodded through at 2am.

Now it’s Tuesday morning and three things landed in your inbox. Your banking partner wants evidence of PCI DSS compliance before onboarding. An investor’s due diligence questionnaire asks about your incident response plan (you don’t have one). And someone from Latvijas Banka sent a politely worded letter about DORA reporting obligations with a deadline that’s closer than you thought.

All of this is sitting on your desk because you’re the CTO. And you’re already building the product.

I’ve been on the other side of this conversation about a dozen times in the past three years, usually sitting across from a CTO in Riga, Vilnius, or Warsaw who looks exactly like this. Smart, technical, stretched thin, and slightly panicking about a domain they didn’t sign up to own. This article is what I wish someone had handed them on day one.

The first year is a build project, not an operations role

Here’s the thing most CTOs get wrong: they think hiring for security means hiring someone to do security, day in, day out, forever. That’s not what year one looks like.

Year one of security in a 30-100 person fintech is a build project. It has a scope, deliverables, and a deadline. It looks like this:

Months 1-3: Gap analysis against your regulatory framework. For most EU fintechs right now, that means DORA (Regulation EU 2022/2554, fully applicable since January 17, 2025) and whatever your license conditions require. You map what exists, what’s missing, and what’s urgent. You also scope your PCI DSS cardholder data environment if you’re processing payments. PCI DSS 4.0.1 is now the only active version, and all future-dated requirements became mandatory on March 31, 2025. This isn’t optional if Visa or Mastercard is in your stack.

Months 3-6: Policy development. ICT risk management framework (DORA Articles 5-15, or Article 16 simplified framework if you qualify), incident response procedures, business continuity plan, access control policy, change management. For a company of 50 people, this is typically 12-18 documents. Not boilerplate downloaded from a template site, but policies that actually reflect how your engineering team works.

Months 6-9: Operational build-out. Incident response tabletop exercises. Vendor risk register populated with your actual third-party providers. DORA Register of Information (the structured register of all ICT third-party contractual arrangements) compiled and formatted for regulatory submission. Security awareness training rolled out. Vulnerability scanning operationalized.

Months 9-12: Testing and hardening. Internal audit of the framework. Penetration testing. Remediation of findings. Preparation for your first regulatory dialogue or supervision visit.

That’s the build phase. It’s intense. It’s 20-30 hours per week of dedicated security work, sometimes more during policy sprints.

And then it drops off a cliff.

After the build: maintenance mode is smaller than you think

Once the framework is standing, the ongoing work for a 30-100 person fintech looks different. I’ve tracked this across multiple engagements: 10-15 hours per week covers it for a company in this size range that isn’t experiencing active incidents or going through a major audit cycle.

That weekly cadence breaks down roughly like this: monitoring and alert triage (2-3 hours), policy reviews and updates triggered by changes in your tech stack or org (2-3 hours), vendor risk management for new or renewing contracts (2-3 hours), incident response coordination when something happens (variable, but usually 1-2 hours of non-incident coordination), and board/management reporting plus regulatory correspondence (2-3 hours).

This is not a full-time job. And that single fact should reshape how you think about your security hiring decision.

I’ve seen too many fintechs hire a full-time CISO at month one, pay them €120-180K per year, and then watch them run out of meaningful work by month eight. They start empire-building, requesting headcount, buying tools nobody needs, and turning a lean security function into a cost center that’s hard to unwind.

The most important question isn’t “should I hire a CISO?” It’s “how many hours per week does this function actually need right now?”

Three ways to close the security function

This isn’t a sales pitch for any one model. I’ve used all three, and each one has a place. Here’s when.

Option 1: Full-time CISO

When it fits: Your security operations consistently require 30+ hours per week, you’re processing high volumes of sensitive data, you have multiple regulatory frameworks in play simultaneously, and you’re large enough (typically 200+ people) that the CISO needs to manage a team, not just a program.

When it doesn’t: You’re a 40-100 person fintech in your first two years post-licensing. I’m not hedging here. I’ve seen this play out repeatedly, and the full-time CISO at this stage almost always leads to one of two outcomes: you overpay for the build phase and then have an expensive employee with not enough to do, or you hire someone junior enough to afford but too junior to build the framework correctly. Both are bad.

Cost reality: Full-time CISO compensation in Europe ranges from €100K to €200K+ depending on jurisdiction and experience. In the US, total compensation (salary, benefits, equity) averages $260K-$330K for companies under $200M revenue, according to the IANS Research 2025 compensation data. Add recruiting costs (20-25% of first-year salary) and you’re looking at a significant cash commitment before they’ve written a single policy.

Option 2: Fractional CISO / vCISO

When it fits: The build phase plus ongoing maintenance. A seasoned fractional CISO has done this build 5, 10, maybe 20 times across different companies. They know what Latvijas Banka asks for during ICT inspections because they’ve sat through those conversations before. They bring templates that have survived audits, not templates downloaded from an ISO 27001 vendor’s marketing page.

The economics: In Europe, vCISO retainers typically run €5,000-€15,000 per month depending on scope. In North America, hourly rates range from $200-$350. A build-phase engagement (heavy hours for 6-9 months) followed by a maintenance retainer (lighter hours) might total €80-120K for the full first year. That’s less than a full-time hire, and you get someone who starts delivering from week one because they’ve done this before.

What to watch for: Not all vCISOs are created equal. Some are former big-company CISOs who’ve never worked with a 50-person startup. Some are consultants who’ll hand you a gap analysis spreadsheet and disappear. The good ones stay accountable for the outcome: they’ll attend your regulatory meetings, own the DORA Register of Information, and pick up the phone when you have an incident at 11pm on a Saturday.

The downside nobody mentions: Availability. A fractional CISO is working with 3-5 clients. If two clients have incidents in the same week, you’re sharing their attention. Get this into the contract: SLA for response times, clearly defined hours, and escalation procedures.

Option 3: Security engineer + external compliance consultant

When it fits: You already have a strong internal engineer who’s technically capable, security-minded, and already handling some security work. What they lack isn’t technical skill but governance experience: how to write policies that satisfy a regulator, how to structure a risk register, how to prepare for a DORA supervision visit.

In this model, the engineer handles day-to-day security operations (vulnerability management, access reviews, incident triage) while an external compliance consultant builds the governance layer. The consultant comes in 2-3 days per month for framework design, policy review, and regulatory preparation. The engineer executes.

When it breaks down: If the engineer doesn’t have governance instincts and the consultant isn’t technically competent enough to understand your stack. I’ve seen this model produce beautiful policy documents that have no connection to how the company actually operates. The regulator will notice.

The Security Staffing Decision Matrix

Here’s a simple model I use with CTOs. It maps the key factors to the right staffing model for fintechs in their first two years:

If your honest answer is “we need 10-15 hours per week after the build phase,” a full-time CISO is the wrong hire. Period.

The most expensive mistake: hiring the wrong person

This one isn’t about money. It’s about time.

I worked with a Latvian EMI in 2024 that hired a security manager who’d spent 15 years in corporate IT at a telco. Good resume, real certifications, nice person. Six months later, they had an ISO 27001-style information security management system in place. Clean documentation. Proper control matrices.

One problem: the regulator didn’t ask for ISO 27001. They asked about DORA compliance. The DORA ICT risk management framework has specific requirements that ISO 27001 doesn’t cover: the Register of Information for third-party ICT providers (Article 28), specific incident classification and reporting timelines, digital operational resilience testing requirements, and the board accountability provisions. The security manager had built the wrong framework, and six months of work needed to be substantially reworked.

That’s the real cost. Not the salary. The rework, plus the missed regulatory deadline, plus the reputational damage of showing up to a supervision dialogue unprepared.

Four questions to screen a security hire (if you’re not a security expert yourself)

If you’re a CTO interviewing CISO candidates and you’re not a security specialist, these four questions will tell you whether someone understands fintech-specific security work:

1. “Walk me through how you’d build our DORA Register of Information. What data do you need, and where does it come from?”

Good answer: They describe identifying all ICT third-party service providers, mapping contractual arrangements, classifying which support critical or important functions, and structuring the data into the ITS template format for regulatory submission. They mention talking to procurement, engineering, and operations to build the inventory.

Red flag: They don’t know what the Register of Information is, or they conflate it with a generic vendor list.

2. “We process card payments. How would you scope our PCI DSS cardholder data environment, and where do you expect the boundaries to be?”

Good answer: They ask about your payment flow, tokenization strategy, and which systems touch cardholder data. They talk about reducing scope through segmentation and outsourcing card data storage to a PCI-compliant processor.

Red flag: They jump straight to “we need to be PCI DSS compliant” without asking about your architecture first. Scope is everything in PCI DSS, and bad scoping wastes months.

3. “If we had a ransomware incident at 3am on a Saturday, what’s the first hour look like?”

Good answer: They describe a concrete incident response sequence: containment, evidence preservation, internal notification chain, regulatory notification assessment (DORA requires initial notification within 4 hours of classifying a major ICT incident), and communication to affected parties. They mention not wiping systems before forensic imaging.

Red flag: They start with “call the police” or “notify the insurance company.” Those come later. The first hour is about containment and evidence.

4. “What does proportionality mean in the context of DORA implementation for a company our size?”

Good answer: They reference Article 4 of DORA, explain that requirements should be implemented in proportion to size, risk profile, and complexity of services. They give a concrete example: “A 50-person EMI doesn’t need a dedicated ICT risk control function the way a bank does, but it still needs documented ICT risk management.”

Red flag: They’ve never heard of proportionality in DORA, or they treat every requirement as equally weighted regardless of company size. This person will over-engineer everything and burn your budget on controls you don’t need.

What regulators actually look for (and where they find gaps)

I want to be specific here because “what does the regulator check?” is the question every CTO asks, and the answers they find online are usually just lists of DORA articles. That’s not useful. Here’s what actually happens.

Latvijas Banka (Latvia)

Latvijas Banka published its 2026 supervision priorities in January. The fintech-relevant focus areas are explicit: DORA compliance, ICT governance, outsourcing management, operational resilience, and business continuity. For 2026, they’ve planned 3 ICT-focused on-site inspections across the financial sector, plus 11 thematic off-site inspections and supervisory dialogues.

In practice, here’s what I’ve seen them focus on during supervision visits and dialogues with fintechs:

Register of Information. The first submission deadline was April 15, 2025 (with data as of March 31, 2025). Going forward, it’s annual by March 1 with data as of December 31. If your register is incomplete, poorly structured, or missing critical ICT providers, that’s the first finding. This is the single most visible compliance artifact because it’s submitted directly to the regulator.

ICT governance documentation. Do you have a documented ICT risk management framework? Does it match what you actually do? They’ll ask for the framework document and then ask your CTO or security lead to walk through it verbally. Mismatches between documentation and reality are a common finding.

Business continuity and incident response. Not just “do you have a plan” but “when did you last test it?” They want evidence of tabletop exercises, test results, and lessons learned. A business continuity plan that’s never been tested is a finding waiting to happen.

Outsourcing oversight. For fintechs that outsource heavily (and most do), they look at whether you’ve assessed the ICT risks of your outsourcing arrangements and whether your contracts include the mandatory DORA provisions (audit rights, exit strategies, sub-outsourcing controls).

Bank of Lithuania

Lithuania is one of the most fintech-dense jurisdictions in the EU. The Bank of Lithuania supervises hundreds of EMIs, PIs, and payment institutions. Their DORA supervision has been building since 2025, with particular attention to ICT risk management and outsourcing (a big deal in a market where many fintechs outsource development to third-party teams).

The pattern is similar: Register of Information compliance, ICT governance documentation, and incident reporting capability. But Lithuania also places heavy emphasis on AML/CFT alongside security, so expect supervision visits to cover both domains. If your security framework doesn’t address how security controls support AML transaction monitoring integrity, you’ve got a gap.

What they all have in common

Across Baltic and Central European regulators, the first supervision cycle post-DORA is focused on three things: do you have the framework documented, can you explain it, and have you submitted your Register of Information correctly? They’re not doing deep technical penetration testing of your systems. They’re checking governance. That’s both good news (it’s achievable) and a warning (you can’t fake it with a Confluence page labeled “Security Policy” that nobody reads).

What to do on Monday morning

If you’re a CTO reading this and recognizing yourself in the first paragraph, here’s the sequence:

This week: Decide which model you need (full-time, fractional, or engineer + consultant). Use the decision matrix above. Be honest about your hours-per-week number.

This month: If you don’t have a DORA Register of Information, that’s priority one. The next submission cycle will come whether you’re ready or not.

This quarter: Get your ICT risk management framework documented and reviewed. Not perfect, but documented. A regulator would rather see an honest framework with known gaps than a polished document that doesn’t match reality.

By month six: Run your first incident response tabletop exercise. Invite your CTO, operations lead, and whoever handles customer communications. Record the findings. Fix them.

Security in a post-licensing fintech isn’t mysterious. It’s a project with knowable deliverables, reasonable timelines, and a clear finish line for the build phase. The trick is treating it that way instead of either ignoring it or over-engineering it.

The CTOs who get this right aren’t the ones who hire the most expensive CISO. They’re the ones who correctly estimate the scope.

If you found this useful, share it with a CTO who just got licensed. And if you’ve been through this build phase yourself, I’d love to hear how your first year went. What surprised you? Reply or leave a comment.

Share

• DORA’s regulatory ecosystem spans 27+ documents across Level 1 legislation, Level 2 RTS/ITS, and Level 3 guidelines — scattered across EUR-Lex, EBA, ESMA, EIOPA, and ECB portals.

• doralib.fromciso.com is a free, searchable index that centralises all of them with filtering by category, keyword search, and a capability map view.

• This guide walks through five real compliance scenarios where the library saves time: gap assessments, incident reporting setup, contract reviews, audit evidence, and TLPT preparation.

• Includes a quick-reference checklist: which DORA documents you actually need, by pillar.

• The library is a research accelerator, not legal advice. Always validate applicability with your Legal and Compliance stakeholders.

Last quarter, a compliance lead at a mid-sized EMI asked me a simple question: “Where’s the final version of the DORA incident reporting RTS?”

She’d been looking for twenty minutes. She had three browser tabs open — EUR-Lex, the EBA website, and a Google search that kept returning the 2023 consultation draft instead of the adopted version (RTS 2025/301). Her legal team had sent her a different link the week before. Neither of them was sure they were reading the current text.

This is a compliance professional. She knows what she’s looking for. The problem isn’t knowledge — it’s that DORA’s regulatory sources are scattered across at least five EU institutional portals, published on different dates, with confusing version histories. And the documents themselves don’t make it easy: “Commission Delegated Regulation (EU) 2024/2956” doesn’t exactly roll off the tongue when you’re trying to explain to Procurement what the Register of Information template requires.

I built doralib.fromciso.com to fix that specific problem. Not a content library. Not a compliance platform. Just a fast, searchable index of every DORA regulatory source, organised so you can find the right document in under 30 seconds instead of twenty minutes.

Here’s how to get the most out of it.

What’s actually in the DORA regulatory ecosystem (and why it’s hard to navigate)

Before the “how-to” part, some context on why a library like this is necessary.

DORA (Regulation (EU) 2022/2554) entered into force on 17 January 2025. But the regulation itself — the Level 1 text — is just the framework. The operational detail lives in a growing set of Level 2 technical standards and Level 3 guidelines developed by the European Supervisory Authorities (ESAs: EBA, EIOPA, and ESMA).

As of early 2026, the DORA ecosystem includes roughly 27 documents:

• 2 Level 1 texts — the core DORA regulation and the amending directive

• ~8 RTS (Regulatory Technical Standards) — defining what “good” looks like for ICT risk management, incident classification, third-party contractual policies, TLPT methodology, and subcontracting

• ~3 ITS (Implementing Technical Standards) — standard templates and forms for incident reporting, the Register of Information, and related submissions

• Guidelines, opinions, and supporting reports — from the ESAs, ECB, and ENISA, covering everything from oversight cooperation to the TIBER-EU framework alignment

These documents were published in batches across 2023–2025. Some went through multiple consultation rounds. The subcontracting RTS (2025/532) was adopted as late as March 2025 after the European Commission removed a provision that exceeded the original mandate. New guidance continues to appear.

The practical problem: if you’re building a DORA control framework, writing policies, or preparing for an audit, you need to reference the right version of the right document — and the EU portals don’t make that easy. EUR-Lex has the legal text but no operational context. The ESAs publish final reports alongside the standards, but on separate pages. Google returns consultation drafts mixed with final versions.

DORA isn’t one PDF. It’s an ecosystem of 27+ documents, published across five portals, over three years. If you’re not sure you’re reading the current version, you’re not alone.

How to use doralib.fromciso.com in your workflow

The library is at doralib.fromciso.com. No login, no paywall, no email gate. Bookmark it and share the link with your team — consistency in sources matters more than most people realise.

Here are five ways I use it (and recommend clients use it) in real DORA work.

1. Running a DORA gap assessment

When you start a gap assessment, you need to know which documents define the requirements for each DORA pillar. The library’s category filter (Regulation / RTS / ITS / Reports & Opinions) lets you pull up just the Level 2 standards relevant to your scope.

How I do it: I filter by RTS, scan the titles, and map each one to a DORA pillar in my assessment template. For ICT risk management alone, the relevant RTS prescribes 20 policies and procedures. I learned this the hard way — my first DORA gap assessment was scoped entirely from the Level 1 text, and I missed about half the required controls. The Level 2 detail is where the real implementation effort hides.

If you’re building a gap assessment from scratch, I wrote a step-by-step DORA compliance roadmap that walks through the full process, starting with governance and ownership.

Start your gap assessment from the RTS, not the regulation. The Level 1 text tells you what to do. The RTS tells you how much — and that’s where most teams underestimate the work.

2. Setting up incident reporting

Incident reporting is where DORA gets operationally demanding. The reporting timeline is tight — initial notification within 4 hours for major incidents, intermediate report within 72 hours, final report within one month. The classification criteria use six dimensions (clients affected, duration, geographic spread, data losses, economic impact, criticality of services).

The library groups the incident-related documents together:

• RTS 2025/301 — content and timelines for incident reports

• ITS 2025/302 — the actual templates and forms

• The incident classification RTS — how to determine if an incident is “major”

• The ESA final report (JC 2023 83) — the rationale and worked examples behind the classification thresholds

Most teams I work with start by reading the regulation text (Article 19), then try to build their own reporting templates from scratch. One fintech client spent three weeks designing custom forms before discovering that the ITS provides standard templates. Three weeks of wasted work. The library links the RTS, ITS, and supporting report together so you can pull up all three in one search instead of navigating three separate ESA publication pages.

3. Reviewing vendor contracts for DORA compliance

Third-party risk management (DORA Articles 28–30) requires specific contractual clauses: audit rights, data location provisions, exit strategies, subcontracting controls, and service level descriptions. The RTS on contractual policies adds detail. The subcontracting RTS (2025/532), adopted in March 2025, adds further constraints on how ICT services supporting critical functions can be subcontracted.

How I use the library here: Before a contract review session with Legal and Procurement, I pull up the relevant RTS entries and share direct links. In a recent contract renegotiation with a cloud infrastructure provider, linking directly to Section 3 of the contractual policy RTS cut the back-and-forth from three review rounds to one — because everyone was reading the same text, not paraphrasing from memory.

When Legal, Procurement, and Security work from the same source links, the debate shifts from “which version are we reading?” to “how do we implement this clause?” That’s a better use of everyone’s time. For more on the vendor side of DORA compliance, I covered the CTO-CISO coordination model for vendor oversight in a separate piece.

4. Building audit evidence packs

Auditors want to see that your controls trace back to regulatory requirements. The library helps you build a “Regulatory Sources” appendix in your evidence pack — a list of which documents you referenced, which version, and where the specific expectation comes from.

How I did it last quarter: When I built an evidence pack for a PI client’s first DORA readiness review, the “Regulatory Sources” appendix took me about 15 minutes to compile. For an ICT risk management control like “annual risk assessment,” the appendix referenced:

• DORA Article 6 (Level 1 requirement)

• The ICT Risk Management RTS (Level 2 detail on what the assessment must cover)

• The ESA final report explaining the regulatory rationale

Each entry included a library link. The auditor later told me this was the first evidence pack they’d reviewed where every regulatory reference was a working link to the current version. That shouldn’t be unusual, but it is.

5. Preparing for threat-led penetration testing (TLPT)

TLPT is the most operationally complex DORA requirement. Significant financial entities must complete their first TLPT exercise before 17 January 2028, with ongoing tests every three years thereafter.

I’ve started scoping TLPT for two significant entities this year. The first thing you discover is that the documentation is split between multiple institutions — the ESAs, the ECB, and the Official Journal — each publishing different parts of the puzzle. The library connects all three key documents:

• RTS 2025/1190 — scope, methodology, and assessor criteria for TLPT

• The TIBER-EU framework (updated by the Eurosystem in February 2025) — detailed phase-by-phase guidance for what is typically a 9–14 month process

• The ESA final report on TLPT — regulatory rationale and expectations

Having all three accessible from one place — instead of navigating the ECB publications page, the Official Journal, and the ESA reports separately — saves real time during scoping. For entities tracking the relevant resilience KPIs, the TLPT section of the library maps directly to your testing pillar metrics.

The DORA Capability Map

The library includes what I call the DORA Capability Map — a view that organises documents by operational pillar rather than document type.

This matters because DORA programs are usually structured around capabilities (ICT risk management, incident reporting, third-party risk, resilience testing, information sharing), not around document categories. The capability map lets you:

• Assign document ownership — “Who in the team is responsible for the incident reporting pillar? Here are the four documents they need to know.”

• Spot coverage gaps — if your implementation backlog doesn’t have work items for TLPT, the capability map makes that visible immediately.

• Structure steering committee updates — report progress by capability area, with links to the relevant standards for each.

If you take one thing from this guide: organise your DORA program by capability, not by document type. The DORA Capability Map is there to make that easier.

Quick reference: which documents do you actually need?

Not every entity needs every document. Here’s a checklist by DORA pillar — find your scope, pull the relevant entries from the library, and ignore the rest.

ICT Risk Management (all entities)

• Core DORA regulation (Articles 5–16)

• ICT Risk Management RTS (full or simplified framework)

• ESA final report on ICT Risk Management (JC 2023 86) — for rationale and interpretation

Incident Reporting (all entities)

• Incident Classification RTS — the 6 criteria for “major” incidents

• RTS 2025/301 — reporting content and timelines

• ITS 2025/302 — standard templates and forms

• ESA final report (JC 2023 83) — worked examples and thresholds

Third-Party Risk Management (all entities with ICT outsourcing)

• Contractual Policy RTS — 8 mandatory clauses

• Subcontracting RTS (2025/532) — constraints on sub-outsourcing critical functions

• Register of Information ITS (2024/2956) — templates for the mandatory ICT provider register

Resilience Testing (all entities; TLPT for significant entities only)

• RTS 2025/1190 — TLPT scope and methodology

• TIBER-EU framework (updated Feb 2025) — phase-by-phase guidance

• ESA final report on TLPT — regulatory expectations

Oversight & Cooperation (awareness — primarily for entities with designated CTPPs)

• Oversight Harmonisation RTS — conditions for oversight activities

• ESA Guidelines on cooperation and information exchange

Use this checklist to build your initial reading list. Then link the relevant library entries to your controls, your evidence, and your steering committee slides. Consistency in sources across Legal, Risk, IT, and Procurement is half the battle.

What this isn’t

A library speeds up research, but it doesn’t replace governance, gap analysis, or the hard operational work of implementing controls. It indexes regulatory sources — it doesn’t interpret them. Always validate applicability with your Legal and Compliance teams for your specific entity type, jurisdiction, and operating model. And check your document versions — the DORA ecosystem is still developing, with new ESA guidance arriving periodically.

Where to start

If you’re early in your DORA program:

1. Bookmark doralib.fromciso.com. Share the link with Legal, Risk, IT, and Procurement — get everyone on the same reference point.

2. Use the capability map to identify which documents are relevant to your entity type and operating model.

3. Start your gap assessment from the RTS, not the regulation. The Level 2 detail is where most of the implementation effort hides.

If you’re mid-program:

1. Link the relevant library entries to your controls and evidence packs.

2. Use direct document links in audit responses to reduce back-and-forth on “which version are you referencing?”

3. Check the TLPT and subcontracting sections — these are the most recent additions and often the least mature in existing programs.

Open the DORA Documents Library →

Which DORA pillar is giving your team the most trouble right now? Tell me in the comments — I read every reply.

Subscribe now

That library did well because it solved a very specific pain:

• DORA isn’t one PDF. It’s a system of documents.

• Teams lose hours cross-checking Level 1 vs Level 2 (RTS/ITS) vs Level 3 guidance.

• People needed a single, structured reference point and a “bookmark + share” workflow.

In the comments and DMs on LinkedIn, the next natural step showed up quickly:
“Great! Now, how do we turn this into something that helps us work daily, not just read?”

This article is my answer: build a DORA-focused AI assistant in NotebookLM using the exact DORA Library sources so that you can query the framework like a living knowledge base.

No selling. No “magic compliance.” Just a practical workflow that many teams are already using in other domains, but not everyone is applying it to DORA yet.

Who this is for

• CISOs / CTOs in fintechs who need fast, defensible answers grounded in the actual text

• GRC / compliance leads mapping requirements → controls → evidence

• Risk / audit teams doing reviews and gap analysis under time pressure

What you’ll build in 20–30 minutes

A “DORA Notebook” that:

• uses your selected DORA sources as grounding

• answers questions based on the sources you uploaded

• generates usable outputs (briefings, mind maps, audio/video overviews, reports, infographics, slide decks, etc.) to support implementation and internal alignment

NotebookLM is explicitly designed to work from your sources; if something isn’t in the sources, you should expect weaker answers, and you should adjust your question or sources.

NotebookLM: what it is (and why it fits DORA work)

Think of NotebookLM as a research and synthesis layer that sits on top of a curated document set. For DORA, that means:

• fewer “hallucinated” answers (because you push it back to citations and sources)

• faster cross-referencing across RTS/ITS/guidelines

• repeatable workflows: incident reporting, ICT risk, TPRM registers, oversight prep, TLPT prep

Limits (free plan): why the DORA Library fits

As of today, NotebookLM’s free limits are:

• 100 notebooks

• up to 50 sources per notebook

• up to 500,000 words per source (or up to 200MB per uploaded file)

• daily limits: 50 chat queries and 3 audio generations

Since the DORA Library is 27 documents, it fits cleanly inside the 50-source limit.

Step-by-step: build your “DORA AI Assistant” in NotebookLM

Step 1. Open NotebookLM

Go to NotebookLM and sign in with your Google account.

Step 2. Create a new notebook

Name it something obvious, for example:

• DORA Copilot — RTS/ITS/Guidelines

  

Step 3. Add sources from the DORA Library

Open the DORA Library article and start adding sources into NotebookLM.

For those who prefer a faster, more practical way to work with the source texts, I’ve also compiled all 27 DORA regulatory documents into a single archive.

Each file is renamed and ordered for quick scanning, so your compliance, risk, IT/security, and audit teams can find what they need in seconds instead of hours.

Free download here: store.fromciso.com/l/EU-DORA-Official-Docs-Pack

NotebookLM supports multiple source types (PDFs, web URLs, Google Docs/Drive, Word files, etc.).
For DORA, web URLs + official PDFs are typically the cleanest.

How to add:

1. In your notebook, click + Add sources in the Sources panel.

2. Paste the URLs (or upload PDFs) from the DORA Library list.

3. Keep titles consistent (important for later querying).

Practical naming convention (recommended):

• DORA-01 Regulation (EU) 2022-2554

• DORA-04 RTS ICT Risk Management (EU) 2024-1774

• DORA-24 RTS Joint Examination Teams (EU) 2025-420

This makes it easier to tell NotebookLM exactly where to look later (“use sources 8, 9, and 10”).

Important operational detail: NotebookLM stores a static copy of what you upload/import. Drive sources can be manually re-synced; other source types may need re-uploading if the original changes.

Step 4. Validate the notebook (quick check)

Before you “trust” anything, run one check:

Check: coverage

Prompt:

“List all sources currently loaded in this notebook, grouped by DORA pillar.”

(You’re validating that the notebook actually contains what you think it contains.)

Output:

Using your DORA Notebook: Chat workflows that actually help

Below are practical prompts I’ve used (and seen work well for CISOs/CTOs/GRC). These are written to reduce ambiguity and force useful outputs—basic prompt-engineering hygiene that consistently improves quality.

1) “Tell me what I must implement”

Prompt:

“Act as a fintech GRC lead. From the sources, extract the DORA requirements relevant to ICT incident reporting. Output a table with: Requirement, Trigger/Threshold, Timeline, Evidence Artifact, Owner Role, and the source citation.”

Why it works: role + scope + structured output.
Output:

2) “Map obligations to controls”

Prompt:

“Create a control-mapping draft for ICT third-party risk management under DORA. Output as a control catalog: Control Objective, Control Statement, Evidence, Testing Approach, Frequency, RACI, and citations.”

Output:

3) “Compare RTS vs ITS without losing your mind”

Prompt:

“Compare the incident reporting RTS and ITS: what is normative vs what is template/procedure? Output differences and overlaps, and cite the exact sources.”

Output:

4) “Turn requirements into an execution plan”

Prompt:

“Create a 90-day implementation plan for a mid-sized fintech starting today. Prioritize by risk and dependency. Output: Week-by-week plan, deliverables, and which DORA documents justify each workstream.”

Output:

5) “Prepare me for audit questions”

Prompt:

“Generate 25 audit-style questions a regulator/auditor might ask about our DORA operational resilience testing program, and for each question list what evidence we should show and which sources justify it.”

Output:

Studio: where NotebookLM becomes a “content engine” for your team

NotebookLM’s Studio can produce different formats from the same source base—useful when you need alignment across Security, Engineering, Legal, Procurement, and the Board.

Studio outputs include Audio Overviews, Video Overviews, Mind Maps, and Reports, and you can store multiple outputs per notebook.

Studio workflow ideas for DORA

A) Mind Map

B) “Briefing pack” for leadership (CTO/CISO/Board)

Use Studio to generate a role-specific report:

• “Executive summary (Board-ready): what changed, what we must do, what risk remains”

  

• “Engineering summary: required capabilities and operational changes”

  

• “GRC summary: evidence and control mapping expectations”

  

(Studio supports creating multiple outputs per notebook, so you can keep variants for different audiences in one place.)

C) Audio / video overview for fast absorption

Audio is useful when you need a quick “deep dive” on a subset of sources. Video overviews add narrated slides and visuals for explaining complex concepts.

Remember: free plans have daily generation limits.

D) Infographic for fast communication

Generate an infographic outline from the DORA sources: “what it means / what to do / what evidence to keep”.

E) Slide deck for workshops and exec updates

Turn a DORA topic into a slide-by-slide deck: titles, 3 bullets per slide, plus speaker notes with citations.

Use it for kickoff sessions, steering committees, and audit-readiness alignment.

Dora Operational Readiness Reporting And Testing

13.2MB ∙ PDF file

Download

Slide Deck created in Google NotebookLM

Download

The honest part: limitations of a “DORA AI Assistant”

This is not a compliance silver bullet. Treat it as a research acceleration layer.

1) It’s only as current as your sources

NotebookLM uses a static snapshot of what you uploaded. If a document changes, you need to re-sync (Drive) or re-upload (many other source types).

2) It can be wrong

Google explicitly notes NotebookLM can make mistakes, and you should consult qualified professionals for legal/financial advice.

For fintech compliance, this means: use it to draft and accelerate, then verify.

3) Privacy and confidentiality still matter

Google’s documentation states your data is protected and is not used to train NotebookLM unless you provide feedback; Workspace users get additional protections (no human review; not used to train AI models).

That said, follow your internal policy. For this workflow, you can stay fully in the “public documents only” zone by using the DORA Library sources.
4) Source limits are real

50 sources per notebook means you may need separate notebooks if you expand beyond the core 27 (for example: internal policies, procedures, incident postmortems, vendor contract packs).

How to get maximum value (without becoming an “AI prompt person”)

Three practical rules (these also align with standard prompt-engineering best practices):

1. Be specific about output (tables, checklists, control catalogs).

2. Use role + context (“act as fintech GRC lead…”) to steer tone and scope.

3. Ask for citations, and name sources when you know where the answer should be.

We are now deep into the operational phase of DORA (Digital Operational Resilience Act). The “preparation” phase is over; the “execution” phase is here. But DORA isn’t just one PDF. It’s a sprawling ecosystem of Level 1 legislation, Level 2 Technical Standards (RTS/ITS), and Level 3 Guidelines.

As a CISO helping financial entities and fintechs navigate this, I realised we all needed a single source of truth, not just a dump of links, but a structured library organised by operational pillar and context.

Below is the complete inventory of the 27 DORA documents defining the framework as of January 2026.

The General Framework (3 Docs)

The foundation. Before you implement the controls, you need to understand the mandate.

1. DORA Regulation – (EU) 2022/2554

The core legislative act establishing the digital operational resilience framework for the EU financial sector.

2. DORA Amending Directive – (EU) 2022/2556

Modifies existing financial directives to ensure consistency with DORA requirements.

3. ESAs Q&A Tool on the DORA Regulation

A living supervisory Q&A tool on DORA that is updated periodically.

ICT Risk Management (2 Docs)

4. ICT Risk Management – RTS (EU) 2024/1774

Mandatory technical standards for the ICT risk management framework and simplified requirements.

5. Final Report on ICT Risk Management RTS (JC 2023 86)

Explanatory report providing the regulatory rationale behind the ICT Risk Management RTS and the simplified framework.

Incident Management & Reporting (7 Docs)

6. Incident Classification – RTS (EU) 2024/1772

Specific criteria used to determine if an ICT incident or cyber threat is classified as “major”.

7. Final Report on Incident Classification RTS (JC 2023 83)

Final report explaining the incident classification criteria and thresholds for major incidents and significant cyber threats.

8. Incident Reporting Content – RTS (EU) 2025/301

Mandatory details and strict time limits are required when reporting major incidents and significant cyber threats to authorities.

9. Incident Reporting Templates – ITS (EU) 2025/302

Official standard forms, templates, and procedures used for filing incident reports and cyber threat notifications.

10. Final Report on Incident Reporting RTS/ITS (JC 2024 33)

Final report explaining reporting triggers and timelines for major ICT incident notifications and how they map to the RTS/ITS requirements and templates.

11. Cost and Loss Estimation – Joint Guidelines (JC/GL/2024/34)

Guidelines on estimating aggregated annual costs and losses caused by major ICT-related incidents.

12. ESAs Report on a Single EU Hub (JC 2024 108)

Joint ESAs report evaluating the feasibility, options, and implications of further centralising major ICT incident reporting under DORA.

Operational Resilience Testing (3 Docs)

13. Threat-Led Penetration Testing (TLPT) – RTS (EU) 2025/1190

Rules for advanced security testing (TLPT), including scope, methodology, and assessor criteria.

14. Final Report on TLPT RTS (JC 2024 29)

Final report explaining the rationale, scope, methodology, and expectations underpinning the TLPT RTS.

15. TIBER-EU Framework (Updated)

Eurosystem framework and guidance for threat intelligence-based ethical red teaming, updated to support consistent TLPT under DORA.

ICT Third-Party Risk / TPRM (6 Docs)

16. ICT Third-Party Policy – RTS (EU) 2024/1773

Description: Regulatory technical standards specifying the detailed content of the policy for contractual arrangements on ICT services supporting critical or important functions.

17. Register of Information Templates – ITS (EU) 2024/2956

Official data structure and templates for the mandatory register of ICT service contracts (Register of Information).

18. Final Report on Register of Information ITS (JC 2023 85)

Final report explaining the design and completion guidance for the Register of Information templates.

19. Sub-contracting – RTS (EU) 2025/532

Specific rules for assessing and monitoring ICT services that involve subcontracting chains.

20. ESAs Opinion on RoI ITS (JC 2024 75)

Opinion responding to the European Commission’s changes to the draft ITS on the Registers of Information, including implications for data quality and identifiers.

21. ECB Guide on Outsourcing Cloud Services

Non-binding ECB guide describing supervisory expectations and recommended good practices for banks outsourcing cloud services.

The Oversight Framework (6 Docs)

How the EU supervises Critical Third-Party Providers (CTPPs).

Note: The first wave of CTPP designations landed in Nov 2025, meaning oversight audits are now imminent for major cloud providers.

22. Critical ICT Providers Designation Criteria – (EU) 2024/1502

Delegated act setting out the quantitative and qualitative criteria for designating ICT providers as critical for the EU financial sector.

23. List of Designated Critical ICT Providers (CTPPs)

Published list of designated critical ICT third-party providers subject to EU-level oversight.

24. Oversight Fees – (EU) 2024/1505

Delegated act determining how oversight fees are calculated and paid by designated critical ICT third-party providers.

25. Oversight Harmonisation – RTS (EU) 2025/295

Ensures uniform conditions for how authorities conduct oversight activities, including audits and inspections, over CTPPs.

26. Joint Examination Teams – RTS (EU) 2025/420

Details the composition, tasks, and working arrangements of the Joint Examination Teams responsible for supervising critical providers.

27. Oversight Cooperation – Joint Guidelines (JC/GL/2024/36)

Guidelines on cooperation and information exchange between ESAs and competent authorities for DORA oversight activities.

Why This Library Matters Now (And How to Use It)

We are past the theoretical stage. Deadlines are active, and supervision is ramping up.

• If you’re auditing your incident response plan, you need RTS 2025/301.

• If you’re calculating last quarter’s losses, you need the Cost and Loss Guidelines.

• If you’re preparing for your first TLPT, you need RTS 2025/1190.

How to use this library:

1. Bookmark this page. Save it as your DORA home base.

2. Map it to your roadmap. Identify the key documents for your next audit or reporting cycle.

3. Share with your team. Ensure Legal, Procurement, and Tech Leads work from the same source.

Subscribe now

1. Third-Party Risk Exposure Score

Managing third-party risk remains a core challenge under evolving EU security regulations. CTOs require a KPI that aggregates and quantifies vendor-related exposures while demonstrating ongoing compliance with laws such as DORA and other related frameworks.

Definition and Components:

• Vendor Assessment Coverage measures the percentage of all third-party suppliers, especially critical ICT and cloud providers, that have passed documented risk assessments within the past twelve months. DORA and associated compliance guidelines require full inclusion of any critical service providers.

• Risk Tier Classification organises vendors according to business impact:

  • Tier 1 (Critical): Directly support essential business functions or handle sensitive financial data.

  • Tier 2 (High): Strongly influence operational continuity but are less integral than Tier 1.

  • Tiers 3–4 (Medium/Low): Limited immediate impact on operations. Typically, only Tiers 1 and 2 undergo the most detailed controls required under DORA, the NIS2 Directive, and sector norms.

• DORA-Compliant Contract Status tracks the proportion of Tier 1 and Tier 2 vendors with up-to-date contracts containing mandatory ICT risk, audit, and incident-reporting clauses. According to recent industry surveys, contract modernisation delays are consistently cited as a major obstacle during DORA implementation.

Composite Score Calculation:

Third-Party Risk Exposure Score = Σ (Domain Weight × Risk Tier Score × Compliance Status)

Domains include ICT and cybersecurity risk, regulatory compliance, service criticality, financial resilience, and contractual completeness. Assign scores (1–5) and weights reflecting organisational priorities, typically giving precedence to cybersecurity and current contracts.

Application and Reporting:

Dashboards often present:

• Per cent of Tier 1 vendors with current assessments and DORA-compliant contracts.

• Proportion of critical vendor agreements that specify audit rights and incident reporting.

• Aggregated risk exposure scores for all essential suppliers are reviewed quarterly.

Adopting this metric directly supports audit preparation and provides evidence of ongoing oversight as required by regulators. Configurable scoring makes this KPI both adaptable and actionable, highlighting both compliance gaps and risk management progress.

The Third-Party Risk Exposure Score enables CTOs to present vendor management performance in a format accessible to both technical teams and executives, strengthening transparency and accelerating both compliance and operational improvement initiatives.

2. Incident Detection & Response Time

DORA sets strict timelines for notifying competent authorities of significant ICT‑related incidents. MTTD and MTTR are recommended KPIs to help ensure those timelines are met.

Key Metrics:

• Mean Time to Detect (MTTD) records the elapsed time from incident occurrence to initial detection.

• Mean Time to Respond (MTTR) measures the interval from detection through to remediation and return to standard operations.

Regulatory Alignment:

DORA mandates notification of significant ICT‑related incidents per the European Supervisory Authorities’ incident‑reporting technical standards: within four hours of classification and, in all cases, within 24 hours of detection, with an update at 72 hours and a final report within one month.

Improvement Strategies:

• Establish real-time observability across payment and core business systems, leveraging solutions for traceability.

• Integrate Security Information and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) platforms to centralise alerts and automate triage. These tools can reduce MTTR by automating triage and response; actual impact varies by implementation. If you cite a percentage, include a verifiable source and context (e.g., study scope and methodology).

• Maintain well-tested Incident Response Plans (IRPs) with explicit roles and decision points. Conduct regular simulations and reviews, in line with DORA and TIBER-EU guidance.

• Schedule frequent threat-led drills involving red, purple, and blue teams, which ENISA recommends and many firms adopt; quantify your effect with internal MTTD data or cite a specific study rather than ENISA generically.

• Brief board members through accessible dashboards and clear progress visualisations.

Presenting these metric trends in leadership meetings encourages evidence-based investment in tooling and team development, directly supporting audit obligations and risk governance for fintechs.

3. Regulatory Compliance Coverage

Regulatory requirements governing operational resilience are dynamic, and CTOs face the challenge of aligning technology, process, and contractual obligations to meet DORA and other EU security regulations.

Structuring the KPI:

Regulatory compliance coverage is visualised through a regularly updated gap analysis heatmap. This tool benchmarks organisational controls, policies, and vendor contracts against the latest requirements of DORA and related European frameworks.

Assessment Methodology:

• Map current ICT controls, policies, and vendor engagements against all DORA principles.

• Identify and prioritise any deficiencies through detailed document review and stakeholder interviews, focusing on technical controls, contractual completeness, and operational readiness.

• Display results through a colour-coded heatmap highlighting compliant (green), partially compliant (amber), and urgent remediation (red) areas.

Effective reporting breaks down compliance status by key domains, such as incident management, third-party oversight, and operational risk and tracks completion percentages (e.g., “62% of DORA requirements met, with vendor contract revisions and technology asset inventory remaining”).

Best-Practice Implementation:

• Update the gap analysis monthly to account for regulatory updates and organisational changes.

• Automate metric collection and dashboarding to reduce manual oversight and error.

• Assign clear ownership for all outstanding actions, ensuring board and regulator visibility of progress and accountability.

Comprehensive and ongoing gap analysis reporting enables CTOs to demonstrate how resilience and risk management underpin compliance, building trust with stakeholders at every organisational level.

Share

4. Threat-led Penetration Testing Score

Threat-led penetration testing is required under DORA for entities selected by competent authorities; NIS2 requires regular testing of cybersecurity risk‑management measures but does not mandate TLPT. It is an advanced control for operational resilience, providing actionable insights beyond traditional vulnerability scanning.

Core Metrics:

• On-Schedule Completion Rate
  Percentage of scheduled threat-led penetration testing (TLPT) exercises completed within planned timeframes. This reflects program discipline and regulatory consistency.

• Average Remediation Time
  Calculated as the mean number of days between vulnerability discovery and resolution. This quantifies the agility of security teams in closing risk windows.

• Test Types:

  • Red Teaming: Simulate adversarial attacks.

  • Purple Teaming: Cooperative offence and defence evaluations.

  • Blue Teaming: Focused internal detection and response sprints.

Comprehensive coverage supports DORA and other EU data protection standards.

Reporting Practice: Incorporate test progress (on-time completion, risk severity, and remediation velocity) within monthly executive dashboards. Balanced reporting bridges technical operations with business and compliance objectives.

Integrating these KPIs validates penetration testing as both a compliance requirement and an indicator of continuous risk mitigation.

5. ICT Change Management Effectiveness

ICT change management effectiveness directly influences operational resilience and is scrutinised by EU regulators under DORA and related laws.

Primary Metrics:

• Percentage of Major ICT Changes Reviewed for Operational Risk
  Identifies how thoroughly significant changes are vetted for threats, compliance, and operational impacts. For instance, reviewing 18 of 20 major changes reflects a 90% review rate.

• Percentage of ICT Changes Resulting in Post-Implementation Incidents
  Tracks change-induced issues, such as outages or compliance failures. Set a clear internal target for post‑change incident rates (e.g., <3%).

Reviews should evaluate:

• Vulnerability and risk exposures,

• Compliance with all regulatory obligations under DORA and GDPR,

• Impact on both internal and vendor operations,

• Rollback and incident response planning.

Illustrative Example: A mid-sized fintech previously experienced a 7% incident rate after accelerating core API updates without adequate review, triggering a major payment system outage. Subsequently, by introducing automated risk assessments and post-deployment validation, the firm achieved uninterrupted upgrades and lowered its incident metric to below 3%.

Board Reporting and Action: Convey results using trend lines, annotated with significant changes or incident spikes, and supplement with brief narratives that make risks and progress clear for executive oversight. Align improvement and training programs with updated regulatory standards to ensure ongoing compliance.

Effective change management measurement ensures both operational integrity and sustained regulatory compliance, even as expectations continue to evolve.

6. Cyber Resilience Maturity Index

The Cyber Resilience Maturity Index (CRMI) offers a single, comprehensive score summarising a fintech’s readiness across all DORA competencies. By consolidating progress in risk management, incident response, testing, information sharing, third-party risk, and governance, this KPI supports strategic decisions and meets regulatory expectations.

Structure and Assessment:

Each domain is rated 1–5:

ScoreDescription

1 Initial: Unstructured, ad hoc responses

2 Developing: Basic controls, inconsistent

3 Established: Documented routines, reviewed

4 Advanced: Continuous, proactive refinements

5 Optimised: Integrated, automated, audit-ready

This approach, advocated by KPMG and Wavestone in recent sector guidance, ensures consistent interpretation and eases benchmarking.

Visualisation:

A radar chart displays each domain’s score, revealing strengths and highlighting areas needing strategic investment. Comparing current and target positions provides actionable direction for resource allocation.

Practical Benchmarking: Aggregate the six domain scores (e.g., [2, 3, 2, 1, 3, 2]) and average for a sector-comparable maturity index.

Industry data helps CTOs determine if current maturity meets, lags, or exceeds both peer organisations and evolving EU regulatory expectations.

Executive Value: Consolidating resilience measurement into a single KPI streamlines board reporting and provides a direct reference for compliance investment discussions, supported by recognised industry data.

7. Cost and Resource Allocation Efficiency

Proactive management of cost and resource allocation is integral to meeting EU security regulation demands and delivering sustained value from resilience investments.

Measurement Components:

• Resilience Proportion of Operational Budget: Identifies the share of total ICT expenditures dedicated to resilience activities—such as risk management, incident response, and compliance—that are essential for EU readiness.

• Resource Headcount and Specialisation: Tracks the number and expertise of Full-Time Equivalents (FTEs) supporting resilience objectives, including compliance leads, cyber risk analysts, and incident responders.

• Budgetary Trends: Monitors year-on-year changes in spend, aligned to regulatory priorities. External consultancies underscore that sustained increases, such as raising resilience spend from 7% to 10% of total IT budget, signal active compliance management and competitive positioning.

• Resource Impact Reporting: Links budget or staff reallocations to tangible improvements (e.g., faster incident resolution, increased risk transparency, or demonstrable progress along regulatory milestones).

Effective Practices:

Quarterly board reporting should include budget splits and headcount tables, emphasising the business value of resilience compliance. Dashboards clarify alignment between investments and risk reduction, supporting executive decision-making.

Consistent cost and resource allocation monitoring positions fintech CTOs to demonstrate efficiency, regulatory leadership, and long-term growth potential.

Executive Summary and Next Steps

Fintech CTOs navigating the demands of EU security regulations establish operational resilience as both a compliance imperative and a strategic asset by deploying focused, quantifiable KPIs. The seven resilience KPIs presented, spanning third-party risk, incident response, regulatory compliance, threat-led testing, change management, resilience maturity, and cost efficiency, offer practical, actionable measurement systems.

These frameworks enable CTOs to:

• Transparently communicate progress to technical and non-technical stakeholders,

• Prioritise investments by data-driven assessment of risk and readiness,

• Satisfy evolving DORA and EU audit standards with evidence-backed reporting.

The adoption and continual refinement of resilience KPIs will support fintechs in quantifying achievements, identifying actionable gaps, and future-proofing both compliance programs and overall business strategy. CTOs are encouraged to select one or more of the outlined KPIs for immediate implementation, ensuring cross-functional collaboration, automated metric tracking, and alignment with regulatory and organisational goals. This approach establishes a clear path towards mature, defensible, and value-driven operational resilience.

Subscribe now

1. Start With a Blunt Gap Analysis

Why the "Blunt" Approach Works Best

Before you dive into new controls, find out exactly where you stand. A brutally honest gap analysis reveals hidden weaknesses faster than any polished presentation. For you, this means fewer surprises during audits and a clear roadmap for spending.

Your Four-Step Playbook

1. Gather Existing Documents

Collect policies, runbooks, vendor contracts, and penetration-test reports into one central folder. Don't forget parallel frameworks like ISO 27001 and SOC 2, you can reuse this evidence later.

2. Map Artefacts to DORA’s Five Pillars

- ICT risk management

- Incident reporting

- Digital operational resilience testing

- ICT third-party risk

- Information-sharing arrangements

Create a spreadsheet with DORA articles as rows and artefacts as columns. Mark each as direct, partial, or missing coverage.

3. Score and Visualise Gaps

Assign scores from 0 (Not Compliant) to 3 (Compliant). Generate a heatmap so executives instantly see weak spots. Validate your scoring with a free checklist fromCISO.

4. Turn Gaps Into Two-Week Sprints

Prioritise critical "red" controls that carry fines or customer impact. Assign each action to Jira with clear owners, definitions of done, and expected evidence. Re-score monthly and watch your heatmap shift from red to green.

Mini-case: Payment scale-up OneCompanyPay boosted its ICT third-party coverage from 43% to 88% in just six weeks using this method. The blunt gap analysis clearly demonstrated ROI, making it easy to secure board approval.

2. Map a Federated Controls Library

Why Consolidation Beats Silos

Running SOX, ISO 27001, PCI-DSS, and DORA separately leads to duplicate testing and audit fatigue. A federated controls library eliminates overlap, letting one piece of evidence satisfy multiple frameworks.

Five Steps to Build Your Matrix

1. Pull Source Material

Export controls from SOX, ISO 27001 Annex A, PCI-DSS v4, and DORA Articles 9-15. Standardise wording into "action + object + purpose."

2. De-duplicate by Intent

Group controls with the same outcome. Keep the strictest requirement as master, referencing others as aliases.

3. Assign Universal IDs

Prefix IDs with framework codes (e.g., SOX-SD-01). Add a DORA cross-reference column for easy sorting.

4. Tag Supporting Evidence

Link controls to Jira tickets, AWS Config rules, or SOC 2 reports. Aim for "one-click proof" during audits.

5. Store in a Living Repository

Use a version-controlled GRC platform like LeanIX Continuous Controls Catalogue. Set up peer-reviewed pull-request workflows.

Quick Wins for Next DORA Compliance Audit

- Replace multiple auditor lists with one export from your matrix.

- Auto-populate evidence packets using DORA filters.

- Track control ownership centrally, ending "who owns this?" email chains.

Red Flags to Avoid

- Mapping only at clause level—always drill down to control statements.

- Letting the library go stale—schedule quarterly reviews aligned with sprint retrospectives.

Adopt this matrix now, and your next DORA review will feel like reusing code instead of rewriting it.

3. Refresh Your DORA Compliance Audit Charter for DORA

Why a Charter Update Matters

DORA makes ICT risk a board-level liability. Your audit charter must clearly show the internal audit’s ability to independently assure all five pillars without conflicts of interest. fromCISO’s guide on the five pillars is a solid reference.

Step-by-Step Rewrite

1. Expand the Mandate

Include ICT third-party risk, incident response, and resilience testing explicitly in your annual DORA Compliance Audit plan.

2. Define Clear Roles

3. Hard-Code Escalation Paths

Material findings must reach the Audit Committee within five business days. Legal non-compliance issues go straight to the board chair.

4. Continuous Assurance

Authorise auditors to use continuous monitoring dashboards. Schedule quarterly mini-reviews.

5. Resilience Testing Rights

Grant audit observer status during resilience tests. Require post-exercise reports within ten days.

A well-crafted charter arms your team with clear authority, satisfies regulators, and lets you focus on innovation, not firefighting.

4. Automate Your Vendor Register

Why Spreadsheets Won’t Cut It

DORA views critical ICT suppliers as extensions of your risk surface. A static spreadsheet can't capture daily changes. Automating your vendor register ensures real-time accuracy.

Four Moves to Automation

- Embed vendor creation in your procurement portal.

- Enrich data nightly with Bitsight or SecurityScorecard risk scores.

- Tie updates to CI/CD pipelines to block shadow IT.

- Stream evidence into the audit via weekly snapshots.

Mini-case: OneCompanyPay caught shadow IT instantly when their CI/CD pipeline flagged an unregistered SaaS. Procurement completed due diligence within 48 hours, impressing auditors with rapid control effectiveness.

5. Monitor ICT Risk in Real Time

Why Continuous Monitoring Matters

DORA Article 9 demands the timely identification of anomalous activities. Continuous control-monitoring (CCM) dashboards replace quarterly PDFs with live risk scores, eliminating blind spots.

Build a CCM Dashboard in Three Sprints

- Pipe data from SIEM, ticketing, and cloud posture tools.

- Map metrics to DORA articles.

- Set visual alerts that trigger Slack and Jira notifications.

Daily metrics like mean time to patch and backup success rates impress auditors and demonstrate proactive oversight.

6. Drill Incident Response & Reporting

Why Drills Are Essential

DORA gives just 24 hours to report material incidents. Regular tabletop and live-fire exercises ensure your team meets this tight deadline.

Internal DORA Compliance Audit observes drills, capturing timestamps and artefacts to prove control effectiveness.

7. Stress-Test Operational Continuity

Why Advanced Testing Counts

Scenario-based resilience tests (e.g., power loss, cloud outages) provide hard evidence that your recovery targets actually work. Automate metric collection for audit-ready documentation.

8. Elevate Board-Level Oversight

Why Regular Updates Matter

Make DORA readiness a standing board agenda item. Present a concise heatmap and clear budget motions quarterly to keep directors informed and accountable.

9. Industrialise Evidence Capture

Why Automation Beats Manual Gathering

Automate evidence capture into a secure data lake, tagging artefacts for rapid retrieval. Regular "evidence health checks" ensure continuous compliance.

10. Stage Mock Supervisory Reviews

Why Practice Makes Perfect

Run mock ESMA/EBA inspections every six months. Identify gaps early and build muscle memory, turning real inspections into routine events.

11. Close the Loop With Continuous Improvement

Why Iteration Is Key

Turn DORA Compliance Audit findings into an agile backlog. Assign clear owners, bake KPIs into operational metrics, and re-run gap analyses semi-annually. Continuous improvement becomes routine engineering work.

Quick Win: Download the 1-Page DORA Compliance Audit Sprint Planner

Grab a free XLSX that slots all 11 tactics into six two-week sprints. Drop it into Google Sheets or Jira, assign owners in minutes, and start turning red gaps green. No calls, no commitments—just a practical worksheet you can use today.

DORA Sprint Planner – Detailed (EN)

7.04KB ∙ XLSX file

Download

One-page XLSX template covering all 11 DORA tactics, broken into 22 granular tasks across six two-week sprints. Includes columns for Owner, Due Date, Status, and Evidence Link—ready to import into Google Sheets or Jira.

Download

Good luck—your next audit just got easier.

1. Know the Legal Bedrock

Recital 36 — The Intent

“Financial entities shall put in place and maintain resilient ICT systems taking into account the nature, scale and complexity of their services, activities and operations, as well as their overall risk profile.”
Share this exact wording whenever someone treats DORA as a one-size-fits-all rulebook.

Article 4 — The Mandate

Supervisors must assess compliance “in a proportionate manner,” weighing:

• nature, scale and complexity of services

• overall risk profile

• potential impact on customers and markets

Article 16 — The Safety Valve for Micro & Small Firms

Entities with fewer than 10 staff and an annual turnover below €2 million may use a simplified ICT-Risk Management Framework (ICT-RMF). They are exempt from Articles 5–15 (including TLPT) provided they maintain basic security-by-design controls and an incident log.

Quick Win — Circulate the Excerpts

Create a two-page brief containing Recital 36, Article 4 and Article 16; highlight key phrases and send it to executives and legal counsel before budget talks.

Mini-Checklist for CTOs

• Recital 36 archived in the policy wiki

• Articles 4 and 16 linked from every DORA project charter

• Excerpts included in the next board deck

• Internal FAQ entry: “Proportionality is built into DORA—see Recital 36, Art. 4 & 16”

2. Profile Your Size-Risk Matrix

Why Start Here?

Regulators expect an up-front self-assessment. Skipping it invites over-engineering—or blind spots.

Step-by-Step Mapping

1. List core assets — systems, code repos, on-prem hardware, SaaS.

2. Capture transaction volumes — daily payments, peak API calls.

3. Mark geographic scope — customer countries, data-centre locations.

4. Identify critical functions — activities whose failure halts payments, trading or onboarding.

Classify Impact Tiers

Mini-Checklist

• Matrix covers 100 % of production assets

• Impact tier agreed by two + stakeholders

• Reviewed quarterly or after material changes

3. Governance Guard-Rails (Article 5)

The board remains ultimately accountable for ICT risk:

• An accountable executive (CTO, CIO or COO) is formally appointed.

• The three lines of defence model is respected: operations, risk-control, and internal audit.

• The board approves and publishes the underlying assumptions of the size-risk matrix every year.

Mini-Checklist

• Board minutes reflect an annual ICT-risk review

• First- and second-line roles separated by policy or contract

4. Tailor Your ICT-RMF (Article 6)

Article 6 demands an ICT-Risk Management Framework but explicitly allows scalability based on “size, risk profile and business complexity.” You can extend existing cyber- or operational-risk processes instead of starting from scratch.

Reminder: If you qualify for Article 16, the entire framework can often be compressed into a single 10–15-page integrated policy.

Minimum Viable Controls Every CTO Must Evidence

Even the leanest ICT-RMF must demonstrably cover the six NIST-style functions:

5. Scale Incident Reporting (Articles 19–20)

Match the Clock to Your Size

The final RTS (17 July 2024) sets strict windows:

• 4 hours after designating an incident as major — initial notification

• 24 hours after detection — if classification is still pending

• If a deadline falls on a non-business day, most entities (except significant/systemic ones) may report by 12:00 on the next working day

Automate Severity Mapping

A rules engine that weighs service impact, customer reach, and data loss can instantly tag incidents as major or significant, ensuring only genuinely major events trigger the 4-hour clock.

Keep One Taxonomy — DORA, GDPR, NIS2

Align labels so one incident equals one record. The Commission explicitly encourages converged taxonomies.

6. Calibrate TLPT & Testing (Article 26)

Document your rationale and keep evidence for auditors.

7. Streamline Third-Party Oversight (Articles 28–31)

Quick Risk Triage

1. List all external ICT services.

2. Score criticality: core, important or supporting.

3. Scale due diligence accordingly.

Risk-Based Due Diligence

Mandatory Contract Clauses (Article 30 § 2)

Every contract covering a critical or important service must include:

• audit and inspection rights

• conditions for sub-outsourcing

• data location and portability requirements

• incident-notification timelines

• exit and transition plan

8. Evidence Your Decisions

Regulators want the logic behind scaled controls. Annotate each control with its link to the size-risk matrix and refresh documentation quarterly. All controls must be fully in force or explicitly scheduled.

9. Tap Guidance & Peers

Reg-Tech sandboxes, industry round-tables and peer benchmarks are excellent ways to pressure-test proportionality decisions before audits.

10. Build a Three-Year Maturity Roadmap

KPIs should track impact (e.g., MTTR on critical services) rather than headcount.

Final Tip — One-Control Sprint (4 Weeks)

Pick a single high-impact control, map it to DORA’s proportionality wording, right-size it and document your rationale. Repeat quarterly; proportionality will soon become muscle memory.

Assign Clear Ownership in Your DORA Compliance Roadmap

Why Ownership is Your First Step

DORA (Digital Operational Resilience Act) places direct responsibility for ICT risk management squarely on your board (Article 4). Without formal accountability, remediation stalls, audits drag, and regulators quickly lose patience. By formally assigning board-level responsibility and naming a single DORA Programme Lead, you eliminate confusion and empower teams to focus on delivery rather than debating decision-making authority.

Four Actions Your Fintech Can Complete This Month

1. Board Resolution

   • Add DORA compliance explicitly to your risk appetite statement.

   • Officially appoint a DORA Programme Lead (often your CTO or COO).

2. Draft a RACI Matrix

   • Map each Delegated/Implementing Regulation requirement to roles:

     • Board (Accountable)

     • Programme Lead (Responsible)

     • Control Owners (Consulted)

     • Audit (Informed)

   • Keep it concise—one page—for daily reference.

3. Launch an Operational Resilience Council

   • Members: CTO (Chair), CISO, Head of DevOps, Legal, Risk, and a business-line lead.

   • Schedule bi‑weekly 30‑minute meetings focused on blockers and metrics, not slide decks.

4. Publish a Two‑Tier Escalation Path

   • Tier 1: Medium‑severity incidents handled by Control Owners.

   • Tier 2: Major ICT incidents escalate internally within 15 minutes; regulators must be notified by the end of the next business day (per DORA Article 9), with a detailed report within one month.

Clear ownership accelerates compliance and reduces regulatory friction.

Mini‑Case: How One 120‑Person Payments Firm Did It

Previously, five separate teams managed security, causing vendor assessments to take 90 days. After appointing a DORA Programme Lead and launching their Operational Resilience Council:

• Vendor review cycles dropped to 25 days.

• Completed a cross‑service gap analysis in three weeks.

• Reduced regulator follow‑up questions by 40%.

Think of ownership as a product feature: design it once, test it regularly, and iterate when people or processes change.

Map Your Critical Business Services

Why This Matters

Under DORA, your board is accountable for critical functions. A glitch in payments or onboarding can trigger regulatory intervention and fines. Clearly defining critical services—those whose failure would harm customers, impact capital, or breach licence conditions—is essential.

Four‑Step Mapping Playbook for Fintech CTOs

1. List Candidate Services

   • Identify top‑level customer journeys from your product roadmap and incident logs.

   • Stress‑test each against DORA criteria: customer impact, market integrity, and financial stability.

   • Typical critical services: payments execution, digital lending, KYC/AML screening, core ledger.

2. Decompose Each Service

   • Break down into people, processes, technology, facilities, and data.

   • Identify hidden dependencies (shared SRE teams, single secrets vaults).

   • Tip: Run a half‑day workshop with engineering, ops, and compliance.

3. Visualise with Service Blueprints

   • Plot customer activities, internal assets, and external providers.

   • Label components with RTO/RPO targets defined in your ICT risk management framework (per DORA Article 7) and aligned with ESAs guidance.

   • Identify single points of failure—input for gap analysis.

4. Validate and Assign Ownership

   • Assign an accountable executive (often the product owner) for each blueprint.

   • Store blueprints in your GRC/wiki, updating quarterly to track drift.

Quick Win: Two‑Week Dependency Map

• Week 1: Daily 60‑minute workshops to draft blueprints in Miro or Lucidchart.

• Week 2: Circulate for feedback, finalise RTO/RPO tags, and present a one‑page heat map to your board.

Outcome: A regulator‑ready register of critical services by month‑end—no new tooling required.

Run a Structured DORA Gap Analysis

Why a Structured Approach Matters

DORA’s Articles set objectives; the RTS/ITS Regulations (e.g., Delegated Reg 2024/1773, Implementing Reg 2024/2956, ESA v4.0 Reporting Package) specify controls. A systematic gap analysis shows compliant controls, tweaks needed, and missing elements.

Five‑Step Playbook for Fintech CTOs

1. Scope the Assessment

   • Entities: parent, regulated subsidiaries, and relevant cloud regions.

   • Include all applicable Delegated/Implementing texts currently in force.

2. Map Existing Controls

   • Leverage SOX, ISO 27001, and PCI evidence where relevant.

   • Document control owners, artefacts, and frequency.

3. Score Each Clause

   • Status: Compliant (✓), Partially Compliant (~), Not Compliant (✗).

   • Impact: High if it affects critical services; else Medium/Low.

   • Effort: High for new tooling; else Medium/Low.

4. Visualize Results

   • Create a heat‑map spreadsheet (red for urgent gaps).

   • Import into your GRC platform for remediation tracking.

5. Prioritize Fixes

   • Address High‑Impact/Low‑Effort first; schedule Low‑Impact/High‑Effort later.

   • Set deadlines.

Mini‑Checklist:

• Board approval of scope.

• Cross‑reference table linking Delegated/Implementing clauses to controls.

• Action log with owners, budgets, target dates.

• Time‑stamped audit trails from your GRC.

Build a Modular Control Library

Why This Matters

DORA demands consistent, comprehensive ICT controls. A modular library lets you define each control once, reuse across services, and automate updates, cutting maintenance and audit pain.

Four Steps to Your “Golden Sources”

1. Define a Control Taxonomy

   • Group by domain (access management, change control, backup & recovery).

   • Include metadata: objective, owner, frequency, KPIs, and evidence source.

2. Single Source of Truth

   • Store controls in version‑controlled Markdown/YAML in Git.

   • Link to your GRC for synchronisation.

3. Parameterise for Variation

   • Use variables for RTO/RPO targets, environments, and jurisdictions.

4. Automate Distribution

   • GitOps pipelines push changes to runbooks, IaC templates, and policy portals.

   • Nightly, jobs update KPI dashboards and flag orphaned controls.

Core Controls to Cover First

• Access management (MFA, orphan account sweeps)

• Change control (code reviews, rollback plans)

• Backup & recovery (immutable snapshots, quarterly tests)

Harden Incident Reporting Procedures

Why It Matters

DORA Article 9 requires notification of major ICT incidents to authorities by the end of the next business day, with a detailed report within one month and a summary within three months. Internal SLAs can be tighter to ensure readiness.

Implementation in Four Sprints

• Sprint 1: Map current incident flows.

• Sprint 2: Create pre-authorised report templates.

• Sprint 3: Automate submission via serverless functions.

• Sprint 4: Conduct tabletop exercises.

Launch Threat‑Led Penetration Testing (TLPT)

Note: Delegated Regulation C(2025) 885 (13 Feb 2025) mandates annual TLPT only for systemic financial entities and designated Critical ICT Third‑Party Providers (CTPPs). Tailor your TLPT approach accordingly.

Industrialise Third‑Party Risk Management

Align vendor tiering with the 18 Feb 2025 ESA CTPP Roadmap, and submit registry data using ITS 2024/2956 templates.

Retrofit Contracts for Resilience

Update SLAs with RTOs, incident‑sharing clauses, audit rights, data portability, exit strategies, and sub‑outsourcing notifications.

Embed a Resilience Culture

Use secure‑by‑design checklists, micro‑learning, quarterly drills, and reward proactive behaviours.

Set Up Continuous Assurance

Automate evidence collection via central logs, config‑drift detection, and attestation workflows.

Final Tip: Start your 30‑day sprint now: secure executive ownership, run a focused gap analysis using the Delegated/Implementing Acts in force, and build an actionable backlog. Acting now makes compliance a competitive advantage well before regulators arrive.

Let me guess—when you hear "DORA regulation," you might think it's just another tedious compliance checkbox, right? But here's the kicker: ignoring DORA could put you and your leadership team personally at risk.

Digital Operational Resilience: Lessons from NIS2 and DORA for Senior Management explains it clearly: DORA elevates digital operational resilience from a "tech-only" task to a board-level obligation. Without a formal charter, executives like you face serious personal exposure.

To protect your firm—and yourself—you need a spelt-out DORA Charter. And guess what? Setting this up doesn't have to be a headache. Let’s dive in.

Your 5-Step Checklist for a Clear, Actionable DORA Charter

1. Digital-Resilience Objectives

Clearly defined, measurable targets like "Critical APIs must recover within 2 hours with 99.95% availability."

2. Scope and Ultimate Accountability

• Explicitly assert that the board holds final accountability.

• Assign the CTO to lead tech delivery and the CISO to manage controls.

3. Governance Cadence

Commit to quarterly board reviews using a unified Risk & Resilience Dashboard, keeping accountability fresh, not buried in paperwork.

4. Escalation Thresholds

• Predefined “break-glass” triggers (e.g., cumulative downtime >15 minutes, data loss ≥1 GB).

• Assign duty officers and explicit communication channels (e.g., dedicated Signal channel) to ensure quick board visibility.

5. Delegated Authorities

Clearly outline who can make decisions independently (like CTO–CISO teams selecting tools) and when board ratification is unavoidable (e.g., payment processor outsourcing).

An Example Charter Excerpt (Simple and Clear):

Charter Clause 4: Ultimate Accountability 
The Board retains full accountability for all ICT risk decisions (DORA Article 5) 
The CTO owns the technology strategy 
The CISO oversees risk management. 
Both must jointly approve deviations from established thresholds

Tips for a Smooth Board Sign-Off:

• Start each clause with a plain-English summary—no jargon first!

• Attach a simple RACI matrix showing roles clearly at a glance.

• Rehearse the pitch with your Company Secretary to iron out any wording confusion upfront.

Now that your foundational charter is set, every decision—dashboards, testing, vendors—rests on firm, mutual authority.

Mastering the Complementary Leadership Archetypes Under DORA

Think about this for a moment: Why do compliance discussions sometimes feel like battles? Often, it's not missing controls—it's clashing leadership styles. Mapping how each leader naturally drives decisions can smooth friction and ease compliance.

Understanding CISO Management Styles, ISACA

Quick Self-Audit:

1. Identify your leadership style (DISC, MBTI, or plain English).

2. Exchange style notes with your CISO over a 15-minute coffee huddle.

3. Highlight conflicting approaches (e.g., rapid iteration vs. strict control) and agree on a decision-making rule, usually defaulting to board-defined risk tolerance.

Want the secret sauce? Choose the right leader for the right forum:

• CTO chairs Architecture Boards; authoritative CISOs co-pilot with checks.

• CISO leads Risk Committee; collaborative CTOs provide smart evidence.

• Ensure servant-leader CISOs facilitate post-incident learning while SRE leads the technical portions.

Checklist for Next Quarter:

☐ Identify each leader’s two strengths and one blind spot.

☐ Document forum leadership clearly in your DORA charter.

☐ Quarterly review to adapt as needed.

Think of leadership archetypes as technical dependencies within your governance architecture—map, version-control, and refactor regularly. But wait—there's more!

DORA Articles to Roles: Using a Crystal-Clear RACI Matrix

DORA regulations read like they're written for regulators, not your org chart. A clear RACI matrix converts dense legal text into four clear verbs—Responsible, Accountable, Consulted, and Informed. No more guessing games.

Your Rapid-Fire 5-Step Workshop:

1. List DORA workstreams (ICT risk, incident response, resilience tests, vendor oversight).

2. Map workstreams directly to key DORA articles (e.g., Incident reporting → Art. 15–20).

3. Define critical roles clearly (CTO, CISO, DevOps, Risk Lead, Procurement, Board Audit).

4. Build your RACI matrix as a team using simple tags—R, A, C, I.

5. Stress-test for oversights—especially incident Root Cause Analysis (RCA).

Gartner confirms effective RACIs cut audit headaches by 30% versus unwieldy charts (Gartner, Building Effective RACI Matrices).

Hybrid Governance: COBIT Meets ISO 42001 for Effortless Oversight

Ever felt torn between COBIT’s disciplined framework and ISO standards for AI? Here's the good news: you don’t have to choose. Blend COBIT 2019 with ISO 42001 for a simple, comprehensive library covering both legacy and AI-driven fintech services.

Create Your One-Stop Control Framework in 3 Simple Steps:

1. Combine COBIT governance objectives with ISO controls on AI lifecycle, data drift, and bias testing.

2. Clearly assign roles to Tech (Process Owners) and Security (AI Risk Owners).

3. Automate evidence—connect CI/CD pipelines to compliance metrics.

When regulators come knocking, your controls tell a consistent story, exactly what DORA expects.

Imagine This: A Single Dashboard for Joint Visibility

Here’s why two slide-decks—one tech-focused, one risk-focused—won't work anymore: Directors must stitch fragmented stories mentally. A single Joint Risk & Resilience Dashboard clears that confusion instantly.

Your dashboard's essentials?

• Tech KPIs: MTTR and change fail rates

• Risk KRIs: Inherent risk, DORA maturity rating

Use plain language: “MTTR ↑30%” becomes “Customers faced an extra 18 mins downtime last quarter.” Directors get it instantly.

Simplified DevSecOps Control Testing for Continuous Assurance

DORA demands "continuous assurance"—daily management, not annual audits. Embedding security directly into your CI/CD pipelines cuts risk, drift and debugging nightmares.

Four Shift-left Essentials:

• Static Code Analysis

• Automated Dependency Scans (e.g., high CVSS scores)

• IaC Security Linting

• Secrets Detection

Joint Crisis Drills: Rehearsals That Really Pay Off

Tabletop and red-team drills expose CTO–CISO frictions before actual incidents do. Keep drills short (90 minutes) and feed identified issues straight into your sprint backlog. Simple. Effective.

NIST's SP 800-84 backs this proactive approach—why reinvent the wheel?

Unified Vendor Risk: One Front Door, Fast Decisions

Running parallel procurement, vendor risk, and security review streams? Guess what—you're wasting 30-40% time. Bundle questionnaires, assessments, and SLAs into a unified vendor intake pipeline.

Personal Liability Isn’t Just an Abstract Threat

It's your career on the line now. Three safeguards that protect you:

• Decision logs clearly timestamped

• Updated D&O Insurance

• Collective board-minute approval for critical releases

Your Simple 30-60-90-Day CTO Roadmap Starts Today

• Days 0–30: Draft your DORA Charter.

• Days 31–60: Launch a quick-win Joint Dashboard.

• Days 61–90: Conduct your first joint CTO–CISO drill.

Start now—before auditors ask tough questions you can’t answer.

DORA, therefore, elevates “tone at the top” from a feel-good slogan to a statutory duty. Boards that embed digital resilience into culture, incentives, and decision-making can convert regulatory pressure into a competitive edge—protecting customer trust, lowering recovery costs and signalling robustness to investors, rating agencies and supervisors.

Key takeaways:

1. Liability is personal; delegation does not absolve directors.

2. Digital literacy is now a board-composition issue.

3. Metrics such as mean-time-to-detect and patch latency will sit alongside capital ratios on dashboards.

4. Table-top exercises, clear escalation protocols and 24-hour notification playbooks separate resilient firms from merely compliant ones.

5. Culture is the multiplier: boards that value transparency and psychological safety encourage early escalation of weak controls—a hallmark of organisations that resist or recover quickly from attacks.

Intended audience: chairs, non-executive directors, CEOs, CTOs, CISOs and Audit & Risk Committee members who need a concise roadmap for meeting DORA obligations while leveraging operational resilience as a source of long-term value.

Why Tone at the Top Now Matters

Culture, governance and accountability. Digital tone at the top is the sum of explicit actions and implicit signals that tell employees, vendors and regulators how seriously the organisation takes operational resilience. Directors model cyber-hygiene, reward early escalation of bad news and refuse “executive exemptions.” Clear charters assign ownership of ICT risk, yet the full board approves the overarching framework and records why it accepted, mitigated or transferred each material risk. Finally, individual directors attest annually that controls are effective—signatures that now carry personal liability.

Regulatory tail-winds. DORA lands in a dense thicket of overlapping rules—NIS2, PSD3, GDPR, Basel’s operational-risk capital framework, and sector guidelines from ESMA, EBA and EIOPA—all converging on the same theme: explicit board accountability. Fail in one regime and investigations quickly spill into the others.

Lessons from public failures. TSB’s 2018 migration meltdown, Worldline’s 2021 payment outage, and Bank of Ireland’s 2023 mobile-banking crash share three threads: inadequate testing, poorly governed third-party dependencies and sluggish escalation to directors. Each episode underlines a simple truth—when boards fail to set a rigorous digital tone, regulators and investors are increasingly willing to set it for them.

What DORA Demands from Boards

Statutory obligations and liability. Article 5 requires directors to “approve, oversee and be accountable” for the entire ICT-risk framework. National authorities must impose “effective, proportionate and dissuasive” fines—many are setting ceilings at the higher of €10 million or 2 % of worldwide turnover. Supervisors may also re-assess fitness and propriety or refer gross negligence for criminal prosecution. Most daunting, the board must file an annual attestation that becomes discoverable evidence in future litigation.

Governance wiring. Specialist committees may prepare and monitor, but ultimate accountability stays with the board. A simple decision-rights map clarifies boundaries:

Minutes must show genuine challenge; rubber-stamping violates DORA’s accountability principle.

Skills and composition. At least one director should have deep ICT or cyber-security expertise, while the rest must be able to interrogate dashboards on patch latency, TLPT findings and cloud concentration. Induction boot-camps, quarterly deep dives and external certifications close knowledge gaps and satisfy DORA’s “effectively informed” standard.

Lifecycle oversight—identify, assess, test, respond.

• Identify critical functions: approve criteria, demand living inventories and push for visibility of shadow IT.

• Assess risk: sign off on extreme-but-plausible scenarios—heatwaves that knock out cooling, geopolitical sanctions that sever managed services.

• Test controls: sanction TLPT scope at least every three years, track mean-time-to-fix as a standing KRI.

• Respond to incidents: verify 24-hour notification capability, ensure CTO have a “red-phone” to the chair and review lessons-learned within 30 days.

Third-party and cloud risk. Boards must approve dependency maps, exit strategies and contractual clauses—on-site audit rights, encryption-key control, one-hour incident notice—because accountability does not stop at the firewall.

Documentation and assurance. A defensible evidence trail is the board’s first shield: detailed minutes, decision logs, risk-acceptance records, incident dossiers and director-training registers. Internal Audit, operating under the Three Lines Model, provides independent assurance and maintains a combined-assurance map to avoid blind spots.

Supervisory engagement. Expect data-driven, intrusive supervision: annual planning meetings, thematic reviews, short-notice inspections and public naming-and-shaming for serious breaches. Administrative fines can reach 2 % of global turnover; individuals may be suspended or disqualified.

From Governance Wiring to Culture

Interlocking committees. Risk, Audit and Technology Committees should share dashboards, minutes and joint sessions so risk appetite, control assurance and tech forecasting reinforce each other. Rotating non-executive directors across committees spreads digital literacy and prevents single points of knowledge failure.

Direct access for CTO. Officer needs independent reporting lines to the board and the right to escalate outside normal cycles. Escalation triggers include any incident that might hit DORA’s 24-hour clock, control failures affecting critical functions and breaches of risk appetite.

Metrics that matter. A concise dashboard blends technical KRIs with culture indicators:

Numbers must flow from independent sources, be tagged to accountable executives and be colour-coded against risk appetite.

Training and simulations. Annual board-level crisis drills, quarterly micro-learning on new threats and joint tabletop exercises with critical cloud providers build muscle memory. After each exercise, assign directors as “guardians” for communications, legal or technology strands so lessons embed into normal governance cycles.

Culture as the multiplier. Boards that link resilience to customer trust and career incentives, celebrate early escalation of near-misses and log the rationale for every risk decision outperform on crisis readiness. Insert culture goals into the chair’s annual letter, start each meeting with a five-minute incident-learning spotlight and ask, “What systemic assumption did we challenge this quarter?”

Turning Compliance into Advantage

Investor and rating-agency lens. Moody’s can cap a rating by two notches when cyber governance is weak; S&P bakes resilience into its Management & Governance score; a 2023 MSCI study found that banks with top-quartile cyber scores enjoy a 17 bp lower five-year CDS spread. Post-breach bond issuances often carry a “cyber premium” until boards prove governance has improved.

Customer trust and market share. Sub-60-minute recovery objectives, public status dashboards and 99.99 % availability SLAs translate directly into retention, price premium and net inflows when rivals stumble.

ESG and sustainability narrative. Digital trust now sits squarely in the “G” of ESG. Boards that weave DORA compliance into sustainability reports attract Article 8/9 funds and strengthen their social licence to operate.

Global convergence. The SEC, PRA/BoE, MAS and APRA all echo DORA’s board-level expectations—explicit accountability, tight notification windows, scrutiny of third-party risk. Aligning with DORA, therefore, positions a firm for worldwide compliance, reducing duplication and eliminating safe harbours.

Action roadmap.

Common pitfalls. Treating TLPT as a one-off tick-box, failing to document deliberations and allowing siloed committees to create blind spots.

Success factors. Chair-level sponsorship, independent assurance and a living culture of psychological safety.

In Short

DORA makes “tone at the top” a legal requirement and a strategic opportunity. Directors who embed resilience into strategy, lead by example, insist on data-driven oversight and close the skills gap continuously will not only satisfy regulators but also strengthen market positioning, lower the cost of capital and reinforce the organisation’s social licence to operate.

Are you ready to turn compliance into a competitive advantage?