Who is accountable when a mobile app weakness affects DORA compliance?

Accountability usually sits with the business owner of the service, supported by AppSec, risk, and compliance teams. The key is to define ownership before the audit, because DORA expects financial entities to demonstrate control, testing, and oversight rather than treating mobile risk as an isolated engineering issue.

Why This Matters for Security Teams

Mobile app weaknesses often look like a product defect, but under DORA they can become an operational resilience issue with clear accountability implications. The question is not only whether the vulnerability exists, but whether the financial entity can show who owns the risk, who approved the control set, and how testing and remediation were governed. That expectation aligns with the broader control logic in the NIST Cybersecurity Framework 2.0, which emphasises governance, identification, protection, detection, response, and recovery across business services.

In practice, auditors and regulators rarely accept “the developer owned it” as a complete answer. Accountability usually lands with the service or business owner because that role owns the service outcome, while AppSec, engineering, risk, and compliance carry delegated responsibilities. DORA expects financial entities to demonstrate oversight, not just technical activity, so the ownership model has to be explicit before an issue becomes a finding. In practice, many security teams encounter ownership gaps only after a control failure has already been exposed by testing, rather than through intentional governance design.

How It Works in Practice

In a DORA context, accountability should be mapped to the business service that depends on the mobile app, then supported by a control chain that shows who designs, tests, approves, and remediates security measures. The service owner is typically accountable for risk acceptance and prioritisation, while engineering and AppSec are responsible for implementing secure development and verification activities. Risk and compliance teams provide challenge, escalation, and evidence management. That split is practical, but it must be documented because DORA is concerned with demonstrable control over ICT risk, not informal team conventions.

A useful way to structure the answer is to separate ownership, execution, and assurance:

• Ownership: the business or service owner accepts residual risk and signs off on remediation timelines.
• Execution: product, mobile engineering, and AppSec fix flaws, harden builds, and validate releases.
• Assurance: risk, compliance, and internal control functions verify that testing and exception handling are complete.

The control expectation is reinforced by the detail in NIST SP 800-53 Rev 5 Security and Privacy Controls, which gives concrete examples of how organisations assign responsibility for access control, secure configuration, assessment, and continuous monitoring. For mobile apps, that usually means tying findings to SDLC gates, release approval criteria, and evidence of vulnerability remediation. If the app handles payments, customer identity, or other regulated functions, the same ownership model should also connect to data handling, logging, and third-party dependency oversight. These controls tend to break down when the mobile app is developed by a separate product squad, hosted through multiple vendors, and released without a single service owner who can approve risk acceptance.

Common Variations and Edge Cases

Tighter accountability often increases governance overhead, requiring organisations to balance faster delivery against clearer sign-off, evidence capture, and escalation paths. That tradeoff becomes sharper when the mobile app is customer-facing, white-labelled, or built by an external vendor, because accountability still sits with the regulated entity even if delivery is outsourced.

Best practice is evolving for hybrid operating models, but current guidance suggests the regulated firm should retain named ownership for the service, not the supplier. If a vulnerability sits in shared code, SDKs, or a third-party auth layer, the service owner still remains accountable for remediation tracking and regulator-facing evidence, while supplier management handles contractual follow-up. Where the app supports critical or important functions, boards and senior management may also need visibility into the issue lifecycle because DORA places emphasis on governance and resilience at the organisational level. The same is true where the mobile app touches identity journeys, authentication, or customer onboarding, because those controls are often part of a broader trust chain rather than a single application team’s remit. For governance mapping, many teams align this with ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls, especially where responsibility, supplier oversight, and corrective action tracking need a formal management system. The question becomes harder in highly decentralised product organisations because accountability fragments across squads unless one named owner can reconcile risk, remediation, and audit evidence.

Related resources from NHI Mgmt Group

• Who is accountable when an upstream vendor compromise affects a mobile app release?
• Who is accountable when hidden AI processing in a mobile app causes compliance issues?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?