If you've been following this series, you now have:

• A scope that defines your mobile risk surface (Article 1: Understanding DORA Compliance for Mobile Teams)
• Release‑level controls that produce a clear verdict per build (Article 2: DORA Compliance for Mobile Releases)
• Resilience evidence tied to real mobile failure modes (Article 3: DORA Mobile Resilience Drills)

The remaining area is third‑party risk.

Mobile applications ship with embedded SDKs and depend on external providers at runtime. Under DORA, that exposure is still your responsibility and must be governed at the release level. This is often overlooked in mobile programs, because “vendor risk” gets treated as paperwork instead of something that lands directly in the binary and in the customer journey.

1) Why is mobile third-party risk different

Structurally, a mobile app is a packaged artifact, similar to a Docker image or a Java WAR. You bundle your code with third party libraries and ship a specific version. That part is not unique.

What is unique is what happens after you ship. Backend teams can usually patch and redeploy centrally on infrastructure they operate. Mobile teams ship through app stores onto customer devices, and patch adoption depends on store processing, rollout decisions, device constraints, and user updates. That means older versions stay active in the wild, often for weeks or longer.

There are two distinct risk types you need to govern.

Embedded SDKs
These ship inside the binary and execute with app privileges. When an SDK has a vulnerability, policy issue, or breaking change, remediation is release-shaped. You fix it by shipping a new app version and then waiting for adoption. The practical result is prolonged exposure across multiple concurrently running app versions.

Runtime providers
External services like identity, OTP, push, fraud, and payments can degrade, partially fail, or behave differently across environments. That instability shows up directly in critical mobile journeys on real devices and real networks. When it fails, customers see it immediately.

The governance implication is simple and strict. Third party risk in mobile must be release scoped, runtime relevant, and evidence driven.

2) SDK governance model (release‑scoped)

The goal is to control what third‑party code is allowed to ship in each release, in a way that can be proven later. The model starts with inventory, then makes change visible, then attaches decision records so the release verdict is defensible.

Begin with an SDK inventory per release. Treat it as a baseline, not a one‑off report: for every release record, you should be able to show the SDK name, exact version, source/origin, functional role, and (where you have it) a risk note or classification. This inventory becomes the anchor for approvals, bans, patch SLAs, and audit retrieval.

Then require a diff per release. For each new release, you should be able to say what SDKs were added, what versions changed, and what was removed, compared to the previous approved release. This is what turns “we think nothing changed” into “we can show what changed.”

Once you can see change, you can control it. Define approval rules so that new SDKs and major upgrades require an explicit review decision, while routine patch upgrades can follow a lighter path as long as they remain inside your approved version policy. Alongside that, maintain a banned list for deprecated SDKs, vulnerable versions, or non‑compliant providers so known risks cannot re‑enter the app through dependency drift.

Finally, define patch SLAs that align to your risk policy, and measure time‑to‑patch per SDK vulnerability. The key is not perfection; the key is that when patching is delayed you can show a time‑boxed decision rather than an uncontrolled backlog.

Field	Description
SDK name	Library or vendor name
Version	Exact version included in build
Source	Vendor, repository, or origin
Role	Analytics, auth, payments, etc.
Risk note	Known risk, classification, or rationale

3) SBOM‑style evidence for mobile

DORA does not require a perfect SBOM for mobile. It requires dependency visibility that is release‑specific, defensible, and tied to operational governance.

A minimum viable SBOM for mobile is the SDK inventory (name + version) for that release, plus any dependency references your build tooling can provide, plus vulnerability context linked to that exact release. The requirement is that it is version‑scoped and linked to the release record, so you can answer “What dependencies were present in version X?” without reconstructing from source control, old CI logs, or tribal knowledge.

4) Release‑level controls

To make third‑party governance operational, express it as release controls that produce clear outcomes. You are not trying to create more documentation; you are trying to produce a release verdict that remains valid under scrutiny.

A practical minimum is to ensure each release has an SDK inventory, an SDK diff against the previous release, explicit approval or exception for new SDKs and major upgrades, and a check that banned SDKs and versions are not present. Each release should also show a vulnerability posture that is either within SLA or covered by a time‑boxed exception. On the runtime side, the release should link to a provider dependency map for critical journeys and reference defined degradation and fallback decisions for those journeys.

If you already have an Article 2: DORA Compliance for Mobile Releases verdict pipeline, these become the third‑party inputs into that same verdict. The release record remains the single place where the decision and the evidence links live.

5) Audit‑ready evidence packs (per release)

At this point, evidence converges at the release level. An evidence pack is not “everything you have,” it is the minimal set of artifacts that explain why the release was acceptable when deployed.

A release evidence pack should include:

• Release identity (app id, version, build reference, artifact fingerprint)
• SDK inventory and diff
• Approvals and exceptions
• Provider mapping per critical journey
• Degradation and fallback definitions
• Control results from Article 2: DORA Compliance for Mobile Releases
• Resilience evidence from Article 3: DORA Mobile Resilience Drills

The difference between "we have evidence" and "we are audit‑ready" is retrieval, so maintain a simple index that is organized by release version and points to the pack contents.

To avoid exceptions becoming gaps, standardize an exception record. It should identify the scope (SDK or provider), the affected release or releases, the rationale, the accountable risk owner, compensating controls, an expiry or review date, and the approval timestamp. This transforms “we couldn’t patch” into “we made a time‑boxed decision with ownership and controls.”

Retention then becomes straightforward: keep the release record, the evidence pack, and the index in line with your internal and regulatory policies. The important property is that evidence stays version‑scoped, indexed, and retrievable on demand.

6) Leadership reporting (trend focus)

At leadership level, the goal is trend visibility rather than re‑litigating each release. Three metrics tend to work well. Exception aging shows whether risk decisions are being revisited or becoming permanent. Time‑to‑patch for SDK vulnerabilities shows whether your mobile supply chain is responsive. SDK change rate per release shows dependency churn, which correlates strongly with review load and surprise risk.

Start small, then expand

Implement progressively without breaking the release train. Begin with SDK inventory and per‑release diffs, because visibility creates leverage. Then add approvals for new SDKs and major upgrades, followed by banned list enforcement and patch SLA tracking with time‑boxed exceptions.

Once SDK governance is stable, map provider dependencies per critical journey and document fallback decisions. Finally, formalize an evidence pack index and retention so retrieval becomes routine rather than a special project.