If you read the first article in this series: DORA Compliance for Mobile Teams: Understanding scope and what you need to do, you already have the foundation.

1/ You know your mobile scope, you understand why the release is the natural unit of governance,

2/ You have the one question that keeps DORA compliance practical: Is this mobile app release compliant with our DORA-aligned application security and resilience controls?

Now comes the part where we make that question answerable in a repeatable and auditable way.

This article is about the mechanics of DORA compliance for mobile releases. We will define a minimum controls baseline for mobile, introduce a simple verdict model, and cover how to handle exceptions without turning every release into a governance negotiation.

Let’s start with the reason this is release-shaped work, not generic compliance work.

Why the release is the most practical unit of DORA compliance for mobile

Mobile compliance is hard when you try to make a global claim like “our app is DORA compliant.” That claim mixes organizational governance, third-party oversight, incident processes, and technical controls into one statement that is almost impossible to evidence cleanly from a mobile team’s perspective.

The release is a better unit because it is already how mobile work happens. Every iOS and Android release represents a discrete change. Risk changes with it. Evidence can be collected at the time of the release, not reconstructed later when someone sends an audit request.

When you treat the release as the unit of DORA compliance, three things happen:

• Evidence is collected naturally, as part of shipping.
• Risk decisions are made explicitly, not assumed.
• The compliance story is consistent, release after release.

Next, we will define a baseline that is small enough to maintain and strong enough to be useful.

The DORA compliance baseline for mobile releases

The simplest way to make DORA compliance real for a mobile team is to define a baseline. A baseline is just a list of controls that every release must meet before shipping. Keep it to 10 to 20 controls at most. Any more and it becomes a maintenance burden rather than a governance tool.

A good control has three properties. It is binary or close to binary, meaning you can say pass or fail. It is tied to evidence, meaning you can point to an artifact, report, or ticket. And it has an owner, meaning someone is responsible when it fails.

One reminder before we go deeper. This part can get complicated if you let it. Keep it simple. If the control cannot be evidenced, it is not a control yet.

Below are five categories that cover most of the ground for DORA compliance in a mobile scope.

1) Release integrity and traceability

This category answers whether you know exactly what was shipped and can prove it later. In practice, that means every release artifact is uniquely identified with a version, build number, and fingerprint, and it is signed and produced by an approved pipeline. It also means your security checks run on the exact release candidate artifact, not a developer build or a staging approximation, and you have a provenance record linking the artifact back to a commit, repository, and pipeline run. Finally, the supporting evidence is retained so it can be reviewed later without relying on anyone’s memory.

This is the boring but critical category, because if you cannot identify the artifact, nothing else is attributable.

2) Vulnerability and exposure thresholds

This category answers: is this release within our defined risk tolerance?

Controls that keep teams out of trouble:

• No Critical findings in the release.
• No High findings in mobile-critical categories, typically authentication and session management, cryptography, sensitive data storage, transport security, and insecure configuration.
• No new Critical or High regressions compared to the last approved release.
• Remediation expectations exist for non-blocking findings so risk does not accumulate silently.

The key here is defining thresholds before you apply them. “We will know it when we see it” is not a control.

3) Third-party SDK governance

This category answers: do we know what is in the binary, and do we control how it changes?

Controls that make SDK risk manageable:

• An SDK inventory exists for this release, listing every embedded SDK and library.
• A diff exists showing what changed since the last approved release.
• New SDKs or major version upgrades require explicit approval and an assigned owner.
• Banned SDK classes or known-vulnerable SDK versions are blocked from shipping.
• A process exists for responding to critical SDK advisories quickly, with a defined patch expectation.

Mobile has a unique third-party risk profile because dependencies ship inside the app. An SDK can collect unexpected data, break a journey, or introduce a vulnerability without any change to your own code. This category is where DORA compliance becomes very mobile-specific.

4) Resilience readiness for critical journeys

This category answers: have we tested the failure modes that matter most to customers?

Controls that keep “resilience” from becoming hand-wavy:

• Critical journeys are declared for the app, such as login, step-up authentication, account recovery, and payments.
• Dependency maps exist for each journey, covering identity, OTP and push, APIs, fraud, payments, and remote config.
• Rollback plans, kill switches, and feature flag guardrails exist for high-risk features and have been tested.
• Resilience drill evidence is attached and linked in the release record.

This is the category that separates “we are secure” from “we are resilient.” Security and resilience are related, but they are not the same thing.

5) Incident readiness

This category answers whether, if something goes wrong with this release, you can respond quickly and cleanly. In practice, that means your telemetry supports version-scoped analysis so you can identify which app versions are affected and how the impact changes as mitigations are applied. It also means you have clear incident severity criteria for mobile security events, including fraud and account takeover signals, plus an evidence pack template that can be filled out quickly without manual forensics. Finally, you need a decision log process that records what was decided, by whom, and on what basis, so the incident narrative is consistent and reviewable. Incident readiness is often the last category teams build, but it is the one that matters most when something actually goes wrong.

Once you have a baseline, you also need a consistent way to express the outcome of every release review.

The DORA compliance release verdict model

Once you have a baseline, every release candidate should produce one of three outcomes.

PASS

All controls are met. Evidence is complete and linked to the release record. The release can proceed.

FAIL

One or more blocking controls are not met. The release does not ship until the blockers are resolved or formally handled through an exception.

PASS_WITH_EXCEPTIONS

The release meets the baseline only because one or more controls are waived through a formally approved exception. This is a governed outcome, not a shortcut.

A three-state model is more honest than a binary one. In mobile BFSI, sometimes you need to ship to address a higher-priority risk, and a formal exception with compensating controls is more responsible than pretending everything is fine.

Exceptions are where programs either stay disciplined or slowly drift into “we will fix it later” territory.

How to handle exceptions without slowing everything down

Exceptions get a bad reputation because they are often informal and permanent. A well-governed exception is actually a useful tool. It lets you make a controlled tradeoff explicitly, rather than letting risk accumulate quietly.

A good exception needs five things:

• An ID so it can be tracked across reviews.
• An owner who is responsible for resolving it.
• A risk statement in plain language that explains what the risk is and why it is acceptable for now.
• Compensating controls that reduce the practical impact while the exception is active.
• An expiry that forces a follow-up. If it does not expire, it is not an exception. It is a policy change.

The governance rule is simple. PASS_WITH_EXCEPTIONS is only valid when all five elements are present and approved by the right people, typically Security and Risk together.

Track exceptions as a metric. If exception count is growing and expiry compliance is low, your baseline is not being enforced. It is being bypassed.

Now we connect this back to the release record, because that is what makes audits and reviews much less painful.

The minimum release record fields (so audits are easy)

The release record connects the verdict to the evidence and makes the whole model auditable. Here are the minimum fields every release record should include.

Release identity

• App identifier (bundle id or package name)
• Platform (iOS or Android)
• Version and build number
• Artifact fingerprint or unique build ID
• Source reference (repository, commit SHA, pipeline run ID)
• Release owner

Verdict

• PASS, FAIL, or PASS_WITH_EXCEPTIONS
• Controls summary, which passed, which failed
• Blockers list if FAIL, finding or issue ID, owner, and remediation target
• Exception list if PASS_WITH_EXCEPTIONS, exception ID, control waived, expiry, approver

Evidence links

• Security test report linked to the artifact
• Findings export with severities and categories
• SDK inventory and diff
• Drill evidence and runbook links for critical journeys
• Approval trail and exception register entries

If you have these fields, an auditor can review a release decision later without asking the team to reconstruct everything from scratch. That is the practical value.

Last piece, rollout. The goal is for this to feel like normal shipping, not a new ceremony.

How to roll this out without breaking the release train

The biggest mistake teams make is trying to enforce everything at once. That creates blockers, slows releases, and makes the baseline feel like an obstacle rather than a tool.

A better approach is to start narrow and expand.

Start with one hard gate

Pick the single most important control and enforce it as a blocker. A good first choice is “no Critical findings.” Everything else can be measured, but non-blocking for the first few releases.

Add controls gradually

As teams get comfortable with the model, add controls one or two at a time. The goal is for the baseline to feel like a normal part of shipping, not a separate compliance exercise.

Automate evidence collection early

The earlier you automate evidence generation, the less painful the model becomes. Start with scan reports tied to artifacts, then add SDK diffs, then add drill and runbook checks.

Make exceptions visible from day one

Even if you rarely use exceptions at first, make them trackable and time-bound from the start. It is much harder to add governance to exceptions after they have been informal for months.

Outro

A control baseline does not need to be perfect to be useful. It needs to be consistent, evidence-backed, and enforced. When every iOS, Android, or HarmonyOS release produces a verdict and a linked evidence pack, DORA compliance stops being a quarterly scramble. It starts being a natural output of how mobile ships.

In the next article, we will move from release controls to operational resilience. We will cover the simplest drill library for BFSI mobile journeys, what evidence each drill should produce, and how to close the loop between drill outcomes and release controls.

Next up: Mobile Operational Resilience Under DORA: The simplest drill library for BFSI journeys