What DORA Actually Requires From Your App

DORA applies to all ICT services a financial institution relies on, and that includes your mobile app under Article 8, and the Software Development Kits (SDKs) inside it. Your financial app uses third-party SDKs - believe us, it definitely does - and the vendor of that SDK is, in regulatory terms, an ICT third-party service provider. Articles 28 and 30 apply. Right now, most of this lives in a gap between engineering and compliance where nobody has complete visibility.

However, this means that you should assess, register, govern, and monitor your app and its third-party components. A 2MB library buried in your codebase might carry the same obligation as a data center contract, what matters is whether it processes data, affects operational continuity, or could be used against you. And the exposure is real: more than 60% of mobile banking apps lack basic code protection, leaving their architecture readable to anyone who downloads them.

The Hidden Risk Inside Your App

In the Nordics context, a typical banking and financial services app contains 11 SDKs on average. SDKs are pre-built code libraries that developers embed in an app to handle specific functions (analytics, push notifications, crash reporting, fraud detection). Often without a formal ICT vendor assessment ever happening. Your developer added it. Nobody told compliance. Sound familiar?

And the risk isn't theoretical. In 2024, the Polyfill.io attack hijacked a JavaScript library used by thousands of financial sites, injecting malicious code through a trusted third-party script. And while this was a website focused incident, the same can happen to your mobile app. Many apps use JavaScript third-party libraries in the form of SDKs.

Permissions Matter too - and they are connected

There's another angle here that doesn't get enough attention: what permissions your app requests. Camera, microphone, location, contact list, photo library, each permission is a potential data flow. An SDK can initiate a network call and send the data somewhere unexpected.

This is such a familiar pattern. 80% of fraud events now occur through online or mobile platforms. The mobile finance app is no longer one of many attack surfaces; it is the largest and most lucrative one. The Poste Italiane case is what happens when the controls embedded in that app go wrong. An app owner integrates something for a legitimate reason. That something does more than expected. Nobody has a full picture. And the customer pays the price, not just in data, but in trust. Under DORA, this kind of third-party oversight gap isn't just a GDPR problem. It directly maps to your ICT risk assessment obligations, your contractual requirements under Article 30, and your ability to demonstrate operational control over the vendors embedded in your app.

The App Itself, Not Just What's Inside It

SDKs are the most concrete entry point into DORA mobile app compliance, but the app itself is also an ICT asset. The rest of DORA still applies.

DORA's expectations for your financial services app are threefold:

• Security and integrity expectations: certificate validation, secure storage of tokens and credentials, anti-tampering checks, signed builds, and a documented change process FOR EVERY RELEASE.
• Detection obligations: crash spikes that hint at exploitation, abnormal API patterns, signs of a rooted or jailbroken device, app behavior drifting from what you shipped.
• Operational resilience testing program: vulnerability scans, open-source library analysis, network security assessment, source-code review where feasible, end-to-end testing and performance testing, all on a risk-based cadence.

And then there's business continuity. DORA's resilience expectations are built around a simple test: if your app fails for an hour, can your customers still reach their money? Push notifications go down, fraud alerts still need to land. The authentication provider has an outage, payment approval needs a fallback path. None of this survives unless it's designed, tested and documented before it's needed.

Don't overlook legacy. DORA's legacy-system requirements should make you ask whether older app versions, legacy APIs or unsupported mobile components still available to customers remain part of your ICT risk surface. If you migrated most customers to a new app but never decommissioned the old one, you have a finding waiting for the next supervisory dialogue.

Not All Apps, and Not All SDKs Are Equal

DORA is built on proportionality. Assessment depth should match the risk profile. A payment approval app and a branch-locator app are not the same exercise. A behavioral biometrics engine and a UI library are not the same risk either.

When it comes to third-party SDKs, governance should be proportionate to what they can actually do. Here's a capability-based model that both compliance and engineering teams can actually use:

Five Practical Steps to Get Compliant

Here's a structured approach that compliance teams can stand behind and engineering teams can follow without it becoming a bottleneck:

1. Generate an inventory of every SDK: You can't govern what you can't see. Automate it in your CI/CD pipeline so it updates with every build. No more manual lists.
2. Classify Every SDK Using the Capability Model: Map each SDK from your inventory against the criticality table above. One-time exercise, ongoing maintenance. Engineering fills in a one-page intake form per SDK. Compliance assigns the criticality tier. Both teams sign off. Done.
3. Register HIGH and MEDIUM SDKs in Your ICT Third-Party Register: DORA Article 28 requires a register of all ICT third-party arrangements. Every HIGH and MEDIUM SDK supplier belongs in it: service description, data flows, criticality rating, contractual status. LOW criticality SDKs? Inventory entry only. Don't over-engineer this.
4. Review Contracts Against DORA Article 30: Most SDK vendors - including the big ones like Google - give you standard terms that don't meet DORA out of the box. That's your problem to fix. For HIGH criticality SDKs you need: clear SLAs, security incident notification within 24 hours, audit rights, data residency commitments, and exit provisions. US-hosted vendor? You also need valid GDPR transfer mechanisms (SCCs or DPF certification) documented and current.
5. Build Ongoing Monitoring Into Engineering Practice: DORA isn't a one-time assessment, it requires continuous monitoring. Automated CVE alerts, mandatory changelog review before any update goes in, quarterly network traffic checks to verify data minimization, and a tested kill switch for every HIGH criticality app and SDK. If you can't disable it within hours, that's a gap.

What Regulators Will Look For

When supervisory authorities, like Finanstilsynet, BaFin, the CSSF or the Banque de France, look at your DORA posture, they're not just ticking a vendor list. For your app, the questions will get specific, and if you can't answer them, that's a finding:

• Can you produce a complete inventory of all third-party code running in your mobile finance app?
• How do you know what data each SDK is transmitting, and where to? Not just on paper, but for real.
• What is your process for reviewing SDK updates before they reach production?
• If a critical SDK were compromised tonight, how quickly could you disable it?
• Do your contracts with critical SDK vendors meet DORA Article 30 requirements?
• How do you identify and manage fourth-party risk, the vendors behind your vendors?
• Which versions of your app are still available to customers, and when did they last get a risk assessment?

If you can't answer most of these today, that's where to start. The documentation matters, but what really separates a well-prepared institution from a paperwork-compliance one is being able to show actual operational control over what's running in your app.

You can find more information on how Peak Privacy can help you achieve DORA compliance for your mobile apps here.