RiskImmune (Tech, Compliance, Cybersecurity)

For fintech companies and tech-enabled institutions who are overwhelmed by the increasing complexity of AI, cybersecurity, and data privacy regulations, especially with over 100,000 regulatory updates annually and global compliance costs reaching $310 billion. We provide an AI-driven Regulatory Lifecycle Management platform that automates compliance monitoring, regulatory updates, and risk assessment. So they can focus on business growth while ensuring compliance, reducing manual labor costs, and avoiding substantial fines (up to 6% of global revenue for AI non-compliance).

[riskimmune]

DORA Article 19 incident reporting interacts with NIS2 Article 23 in ways that surprise financial entities. Both regulations require incident reporting on similar timelines (24h, 72h, longer-form). For purely financial incidents, DORA reporting takes precedence. For incidents affecting non-financial subsidiaries or non-DORA scope, NIS2 reporting may apply. The complexity: many incidents have mixed scope. A cyber attack affecting both the bank's core operations (DORA scope) and a non-financial subsidiary's operations (NIS2 scope) triggers both reporting regimes. Mature financial entities have integrated incident command structures that produce coordinated notifications: - Single incident commander - Coordinated content across DORA and NIS2 notifications - Single timeline for both reporting streams - Documented reconciliation of any differences Immature entities run parallel notification streams, often producing inconsistent information that creates supervisory follow-up complications. -> Integrate incident command. Don't run parallel streams.

[riskimmune]

A DORA reality I've been telling smaller financial entities: The full DORA framework was designed with mid-to-large entities in mind. Implementing it at scale for a small payment institution or e-money issuer is operationally heavy. ESA proportionality guidance helps. Smaller entities can implement DORA proportionate to their size and risk profile. But the foundational obligations (register, contracts, incident reporting) apply regardless of size. What works for smaller entities: - Outsource register operation to specialised provider - Use shared service models for incident reporting infrastructure - Lean on broader compliance functions that already exist - Automate where possible to reduce ongoing burden What doesn't work: - Trying to build full enterprise-grade compliance with 2-3 people - Treating DORA as primarily a documentation exercise - Hoping proportionality will excuse shortcuts in foundational obligations -> Smaller entities should get help. The capability gap is real.

[riskimmune]

The DORA penetration testing obligations under Article 26 are the most expensive operational requirement. For significant financial entities (those classified as such by competent authority), threat-led penetration testing (TLPT) is required at least every three years. What TLPT actually involves: - Independent threat intelligence to identify relevant threats - Red team operations conducted against production environments - Cooperation from critical ICT providers (their environments are in scope) - Detailed reporting on findings and remediation - Direct oversight by competent authority Cost ranges typically EUR500k-EUR2M per TLPT cycle for the testing itself, plus internal effort, plus provider cooperation costs. Critical providers bear material costs for TLPT cooperation; their contracts must address this. Providers without DORA-aware pricing models are subsidising customer TLPTs at cost. -> Plan TLPT cost into 3-year ICT budgets. It's not a small number.

[riskimmune]

Three DORA register quality issues I find in nearly every audit: 1. Intragroup arrangements omitted. Many financial entities treat services from the parent or sister entity as "internal" and exclude them from the register. DORA explicitly requires intragroup arrangements to be included as third-party arrangements. 2. SaaS subscriptions outside procurement. Marketing tools, design software, productivity SaaS signed up by line-of-business teams without procurement involvement are routinely missing from registers -- even when they have ICT relevance. 3. Subcontracting chains capped at first level. The register captures the primary contractor but not their material subcontractors. Where the primary contractor runs critical services on a major cloud, the cloud provider is a material subcontractor that should be visible. Each of these gaps creates regulatory exposure. Each is closable with deliberate attention. -> Audit your register against these three patterns specifically.

[riskimmune]

DORA Article 30(2)(c) requires contractual provisions on data location. Most financial entities have addressed this for primary data. Few have properly addressed it for backup, replication, processing, and analytics -- where data may move across regions for operational reasons. The full requirement: - Where contracted services are provided - Where subcontracted services are provided - Where data is processed - Where data is stored - Notification requirement when locations change Cloud providers in particular need explicit attention. Default cloud configurations may move workloads or data across regions for performance, redundancy, or cost optimisation. DORA-compliant arrangements require this be locked down or notified. The practical configuration: - Specify regions explicitly in contracts - Disable cross-region replication outside permitted regions - Configure cloud workload affinity to permitted regions - Notification triggers for any operational changes affecting location -> Configuration as much as contracting. Both matter.

[riskimmune]

The DORA Article 31 critical ICT third-party designation process is operationalising in 2026. Designation criteria established: - Systemic importance based on number/share of financial entities served - Substitutability difficulties - Importance of services for systemic functions - Cross-border dimension Once designated, providers face: - Direct ESA oversight engagement - Oversight plan with specific obligations - Periodic comprehensive assessments - Recommendations on risk management - Potential periodic penalty payments for non-cooperation For financial entities using designated critical providers, the practical effect: - Reduced concentration risk concerns (provider is being supervised) - Increased visibility into provider's regulatory posture - Specific reporting obligations to ESAs - Cooperation with oversight activities affecting your services Designation reshapes the provider relationship from purely commercial to dual commercial-supervisory. -> Track which of your providers are being considered for designation. Plan accordingly.

[riskimmune]

Concentration risk under DORA is becoming a strategic constraint, not just a compliance topic. The pattern emerging: ESAs aggregate register data across DORA-regulated entities. They identify providers with substantial market share among financial entities. Those providers become candidates for critical ICT third-party designation. Once designated, providers face direct ESA oversight. But the financial entities depending on those providers also face supervisory attention to concentration. What this means for financial entities: If your top 3 providers cover >50% of critical ICT services, you have concentration exposure. If those providers are being considered for critical designation, your concentration becomes ESA-visible. Diversification strategy may move from "operational best practice" to "regulatory expectation." The boundary between operational efficiency (concentrate with best providers) and regulatory prudence (diversify to manage concentration) is shifting toward prudence. -> Map your concentration exposure. Discuss it at management body level.

[riskimmune]

A pattern I see across DORA-regulated entities: The register is built. The contracts are remediated. The classification methodology is documented. And then... nothing. The register doesn't update with new contracts. The contracts drift back out of compliance with amendments. The classification doesn't evolve as services change. The regulation is not a one-time compliance event. It's a continuous operational discipline. What ongoing capability looks like: - New contracts route through DORA review before signing - Contract amendments trigger compliance check - Quarterly register validation against contracted services - Annual contract review cycle for critical providers - Continuous monitoring of provider posture changes - Annual reporting preparation as confirmation, not data-gathering The entities that maintain ongoing capability survive supervisory engagement. The entities that treated DORA as a project struggle through every annual cycle. -> Build the function, not the project.

[riskimmune]

The DORA register field that catches financial entities off-guard: "Date of the last contractual review." Implication: registers are expected to evidence ongoing review of contracts, not just initial signing. If your last contractual review for a critical provider was 4 years ago, that's a finding. What "contractual review" means in DORA terms: - Verification that contract still satisfies Article 30 requirements - Review of any amendments since last review - Confirmation that subcontracting hasn't changed materially - Validation that location commitments hold - Assessment of whether the contract reflects current risk The recommended cadence: annually for critical providers, biennially for high-risk providers, triennially for others. -> The register is a living document. Build the review cycle.

[riskimmune]

Subcontracting under DORA Article 30 is more restrictive than most providers initially expect. The regulation requires contracts to address whether subcontracting of critical or important functions is permitted, and if so under what conditions. What "under what conditions" actually means in mature 2026 contracts: - Prior notification of any subcontracting (typically 30-90 days advance) - Prior consent for subcontracting of material parts of critical functions - Flow-down of equivalent contractual obligations to subcontractors - Right to object to specific subcontractors with documented reasoning - Visibility into subcontracting chain, not just first-tier subcontractor The cloud market has been particularly affected. Major providers historically subcontracted infrastructure delivery freely. DORA-compliant arrangements now require explicit subcontracting disclosures and approvals. -> The subcontracting visibility is part of the regulatory architecture. Take it seriously in contracts.

[riskimmune]

The DORA exit strategy provision is the most-ignored element of Article 30(3). Required: "exit strategies, in particular the establishment of a mandatory adequate transition period during which the provider continues providing the respective functions or ICT services." In practice, this means contracts must specify a transition period during which the provider keeps delivering while you migrate. For critical functions, "adequate" typically means 12-24 months. Most legacy contracts have: - 30-90 day notice periods - No defined transition period - No data return specifications - No knowledge transfer obligations For DORA compliance, all of this needs amendment. For new contracts, this is straightforward. For legacy contracts with major providers, the negotiation can be contentious. -> The exit provision is what protects you when something goes wrong. Don't sign without it.

[riskimmune]

DORA Article 30(3) audit rights provisions are the most contested in critical ICT third-party negotiations. The regulation requires unrestricted rights of access, inspection, and audit. Right to take copies of relevant documentation. Right to access provider's premises and data centres. Cloud hyperscalers initially resisted; most now have DORA-compliant audit programs. Mid-tier SaaS providers continue to resist; some are using third-party attestations as substitutes for direct audit rights. The practical compromise emerging in 2026: Tier 1 financial entities -> direct audit rights with structured implementation Tier 2 financial entities -> third-party attestation supplemented by remote audit capability All entities -> on-demand right to invoke direct audit when justified Contract negotiations are shaped by your relative leverage. Large banks get full audit rights; smaller institutions accept attestation-based arrangements with right to escalate. -> Know your leverage. Negotiate accordingly.

[riskimmune]

The "critical or important function" classification under DORA drives a substantial portion of your obligations. Wrong classification = wrong obligations. Both directions are problematic: Over-classify -> you're applying critical-function obligations (full Article 30(3) provisions, threat-led penetration testing cooperation, exit strategies) to non-critical relationships. Operational waste. Under-classify -> you're missing critical-function obligations on relationships that actually qualify. Regulatory exposure. The methodology I recommend: Start with: would disruption of this function materially impair our ability to deliver our services, comply with regulatory requirements, or operate sustainably? If yes -> critical or important. If no -> not critical, but document the reasoning. Borderline cases -> conservative classification (treat as critical), document why, revisit annually. -> Document the methodology. Document the application. The methodology is what regulators inspect.

[riskimmune]

The DORA register has more than 15 templates with hundreds of data fields. Most financial entities I've worked with initially underestimated the granularity: - Each contract gets a record (B_02) - Each provider gets a record (B_05) - Each ICT service gets a record (B_06) - Each function supported gets a record (B_07) - Each subcontractor gets a record (B_08+) - Linkages between all of the above A simple cloud arrangement can generate 8-15 register entries when properly mapped. A complex managed services arrangement can generate 50+. Organisations that built registers with simplified data models (one row per supplier) are now retrofitting to the ITS-required granularity. The retrofit is more painful than building correctly from the start. -> Build to the ITS templates from day one. Cheaper than retrofit.

[riskimmune]

DORA Article 28 register of information has become the most operationally consequential regulation in EU financial services. Why: the data is being aggregated across all DORA-regulated entities at ESA level, used to identify systemic concentrations, and shaping the critical ICT third-party designation process. What this means practically: When you populate your register, you're not filing for your own records. You're filing for the European Supervisory Authorities' analytic infrastructure. Quality matters at the EU level, not just at your competent authority level. A poorly populated register doesn't just risk your own enforcement exposure. It risks creating false signals at the systemic level -- and ESAs follow up on suspicious patterns. -> Treat register quality as a systemic obligation, not just a local one.

[riskimmune]

The thing I keep telling NIS2-regulated entities: The supply chain security obligation is not a project to complete. It's a function to operate. A project has a start and end. NIS2 supplier risk has neither. Suppliers come and go, regulations evolve, threats shift, business operations change. The function operates continuously or not at all. The organisations that struggle most have project-shaped engagement: launch the program, declare victory, deprioritise. Six months later the inventory is stale, contracts have drifted, monitoring is unread, and they're surprised when a regulator finds gaps. The organisations that succeed have function-shaped engagement: dedicated capability (in-house or outsourced), continuous operation, periodic management review, sustained investment. -> Decide if you're running a project or a function. The difference shows up at inspection.

[riskimmune]

Most NIS2-regulated entities have one weakness in common: They can describe their incident response plan beautifully. They cannot demonstrate they've ever exercised it for a supply chain incident. NIS2 expects integration of supply chain incidents into incident management. This means: - When a supplier reports an incident, your team has a defined process - Materiality is assessed against your operations, not just the supplier's - Notification obligations are evaluated for your reporting requirements - Customer/counterparty notifications are coordinated where applicable - Lessons are integrated back into your supplier risk processes This integration is testable. Have you had a supplier incident in the last year? How did you actually handle it? What would the regulator see if they reviewed? For most entities, the honest answer is: ad hoc, not integrated, not documented well. -> Tabletop a supplier-originated incident scenario. Find the gaps. Close them.