How does vendor risk assessment differ from supplier risk assessment?

Vendor risk assessment and supplier risk assessment refer to substantially the same discipline, with vocabulary varying by market and by industry. Supplier risk assessment is the more common term in UK procurement contexts and in supply chain functions. Vendor risk assessment is the more common term in US security and technology functions. Both cover the same core activities: onboarding assessment, ongoing monitoring, annual review, and event-triggered re-assessment. Both apply the same frameworks (SIG, CAIQ, ISO 27036) and face the same mobile evidence gap this article addresses.

How often should vendor risk assessments be conducted?

Traditional guidance suggests annual for most vendors, more frequent for critical ones, and event-triggered for material changes. The practical reality in 2026 is that annual cadence ages the vendor risk picture across the year that follows, particularly for vendors shipping frequent mobile app updates. Modern TPRM programmes increasingly supplement annual formal reviews with continuous monitoring that flags material changes as they happen, allowing the team to decide whether each change triggers a formal re-assessment or just an updated risk note.

What is the difference between SIG and CAIQ?

SIG (Standardised Information Gathering) is a general-purpose vendor risk assessment questionnaire developed by Shared Assessments, covering roughly 18 risk domains and used across banking, insurance, healthcare, and technology sectors. CAIQ (Consensus Assessments Initiative Questionnaire) is the Cloud Security Alliance's questionnaire specifically for cloud vendors, aligned with the CSA Cloud Controls Matrix. Both are self-report questionnaires that capture what the vendor knows and is willing to disclose. Neither directly reads the vendor's mobile app or verifies that declared controls match shipped reality.

What is a vendor risk assessment template and how should mobile SDKs fit into it?

A vendor risk assessment template is the standardised set of questions and evidence requirements a TPRM team uses across their vendor portfolio, typically built around SIG or CAIQ with organisation-specific additions. Mobile SDK evidence fits into the template as an ongoing evidence input rather than a one-time questionnaire response, because the vendor's mobile app changes across releases while the questionnaire is a point-in-time snapshot. Continuous mobile evidence at store-surface depth feeds the template between formal reviews, and package-level analysis provides deeper evidence for vendors where the risk profile warrants it.

How does continuous vendor monitoring compare to annual assessment?

Annual assessment produces a detailed point-in-time picture of vendor risk that ages across the year that follows. Continuous monitoring produces lighter-touch but current evidence that flags material changes as they happen, feeding into the annual review rather than replacing it. Most mature TPRM programmes now use both: annual assessment for the deep formal review, continuous monitoring for event-triggered re-assessment prompts. For mobile vendors specifically, continuous monitoring addresses the specific challenge that vendors ship new app versions frequently and each release can materially change the risk picture.

Does Appnalysis replace our existing TPRM platform?

No. Appnalysis contributes the specific dimension of mobile evidence that questionnaire-based platforms and security rating services cannot produce. It does not replace SIG or CAIQ questionnaires, TPRM workflow platforms (OneTrust, ProcessUnity, ServiceNow VRM), security rating services (Bitsight, Panorays, UpGuard), or compliance automation tools. It sits alongside these as the mobile evidence layer, contributing the store-surface signals for continuous monitoring and the package-level signals for deeper investigation.

What is vendor risk assessment?

Vendor risk assessment is the process of evaluating the risk a third-party vendor introduces to your organisation, typically before contract signing (onboarding) and continuously across the vendor relationship (ongoing monitoring). Modern vendor risk assessment programmes combine questionnaire-based self-report (SIG, CAIQ), security rating services (Bitsight, Panorays, UpGuard), continuous monitoring for material changes, and periodic deeper review. For mobile vendors specifically, the assessment picture is incomplete without evidence about what the vendor's mobile app actually ships, which is the gap this article addresses.

Vendor Risk Assessment for Mobile SDKs: A Supplier Guide

SIG and CAIQ questionnaires ask vendors what is true. Continuous evidence about what their mobile app actually ships closes the gap between vendor self-report and vendor reality. For third-party risk management (TPRM) and procurement teams, that gap has been the missing dimension of vendor risk assessment for mobile products.

Split illustration showing a completed questionnaire on one side and a mobile app being read directly for evidence on the other.

I have been building and shipping mobile apps professionally since 2010, first at Coderus and now with Appnalysis, where we read what mobile apps ship as outside-in evidence. One thing I know from fifteen years on the building side: how SDK decisions actually get made inside mobile teams. The version that would surprise most third-party risk management (TPRM) programmes assessing those teams as vendors.

A developer picks an SDK to solve a specific problem in the current sprint. Analytics, crash reporting, monetisation, feature flagging, a payment provider, an ad network, attribution. The developer adds it and gets it working. Then they show peers. Peer review happens after the SDK is already integrated, not before. Three outcomes typically follow. Worst case, the SDK gets pulled and the team picks something else, which means the integration work gets thrown away and the release slips. Best case, peers agree the choice is fine and the release ships on time. In between, peers raise concerns, the team has a big discussion, the release is delayed while the concerns get worked through, and the final outcome varies.

And commercial, licence, legal, and security considerations typically come last in that decision workflow, or later still. The developer picked the SDK for the technical fit. Peer review checked the technical decision. The commercial questions (does this fit the budget), the licence questions (what do the SDK terms let us do), the legal questions (does this introduce compliance risk), and the security questions (does this introduce vulnerability exposure) get properly examined afterwards. Sometimes long afterwards. Sometimes not before the release ships.

That workflow varies by team maturity. Better developers and more experienced teams concern themselves with commercial, licence, legal, and security dimensions earlier because they have been through the pulled-SDK cycle before and know the cost of leaving those questions until later. Junior teams learn the hard way. Even mature teams cannot fully close the gap because release cadence and technical problem-solving cannot always wait for full multi-dimensional review before integration. But the range of practice is real, and TPRM assessments benefit from understanding where on the maturity spectrum a vendor's mobile team actually sits.

There is also more shaping the SDK decision than the developer alone. Developers have SDKs they are trained on and default to for specific functions, which means the choice is often pre-decided by expertise before the current problem arrives. The architecture may commit to specific SDK choices for consistency, so individual decisions get constrained by architectural decisions made earlier by someone else. In agency work, the client may have specified SDK choices explicitly or implicitly, meaning the developer is executing a decision the client already made, whether or not it is technically correct. And when the resulting app or pattern gets used in enterprise contexts, SDK choices that worked at agency scale may not work at enterprise scale, sometimes requiring the SDK to be substituted out entirely. There are forces on both sides of the decision, what is straightforward for the development team versus what is needed for the wider context. Once development is engaged, time pressures compound and the tension between straightforward and correct gets messy.

That is not carelessness. It is how modern mobile development works when release cadence is measured in weeks and the team has autonomy to ship. The vendor's TPRM function completes a Standardised Information Gathering questionnaire (SIG) or Consensus Assessments Initiative Questionnaire (CAIQ) once a year, or on onboarding, describing the SDK footprint and subprocessor list as they understood it at the moment of completion. Between then and the next questionnaire cycle, the mobile team ships six, ten, twenty releases. Each release can add SDKs, remove SDKs, change permissions, shift data handling. The questionnaire response is a snapshot that ages the moment it is filed.

This article is vendor risk assessment content for TPRM readers, written from the mobile engineering side. The gap between what mobile teams do and what vendor questionnaires capture is real, it is structural, and it is where continuous mobile evidence closes the space that SIG and CAIQ cannot reach on their own. Supplier risk assessment (the term used more commonly in UK procurement contexts) faces the same gap. Whether your programme calls it vendor risk or supplier risk, the mobile SDK dimension is the piece questionnaire-based assessment cannot see directly.

There is a specific and important framing worth naming up front. This article is not about mobile app security testing or penetration testing. Both of those require code access and explicit vendor engagement. This article is about compliance comparison: reading what a vendor's mobile app publicly ships and comparing that against what the vendor declared, what compliance frameworks require, and what platform stores allow. Different job than testing. Complementary to it.

The rest of the article covers what SIG and CAIQ actually capture for mobile SDKs, what a questionnaire cannot see, the vendor risk assessment framework for mobile apps built around continuous evidence, how this fits into ongoing vendor risk management and vendor security assessment alongside platforms like OneTrust, UpGuard, Bitsight, and Panorays, how the mobile evidence dimension complements your wider third-party risk assessment programme, and how Appnalysis specifically fits into the workflow.

What SIG and CAIQ Actually Cover for Mobile SDKs

The Standardised Information Gathering (SIG) questionnaire is the industry-standard vendor risk assessment artefact used across banking, insurance, healthcare, and technology sectors. It covers vendor self-reported controls across roughly 18 risk domains including information security, privacy, compliance, third-party governance, business continuity, and incident response. The Consensus Assessments Initiative Questionnaire (CAIQ) is the Cloud Security Alliance's equivalent for cloud vendor assessment, covering control domains aligned with the CSA Cloud Controls Matrix.

Both are foundational to modern vendor risk assessment. Both are what vendors and customers actually exchange during onboarding and annual review. Neither should be replaced by anything this article describes.

What SIG covers for mobile specifically includes questions about mobile device management, mobile application security controls, and mobile data handling practices. What CAIQ covers includes the cloud-hosted mobile backend questions. Both are asking the vendor to self-report on their mobile posture. Both accept the vendor's answer as evidence.

What neither questionnaire can do is read the vendor's mobile app. Neither verifies that declared SDKs match shipped SDKs. Neither checks that stated data handling matches runtime behaviour. Neither tracks changes between the version the vendor was shipping when they completed the questionnaire and the version currently in production. That is the specific evidence gap this article addresses.

A concrete example makes this tangible. A vendor completes SIG in January stating they use three analytics SDKs, one payment SDK, and no third-party ad networks, with subprocessors X, Y, and Z. In April they ship a new version bundling a fourth analytics SDK for a specific market expansion, and the fourth SDK brings subprocessor W. The SIG response is now inaccurate but the questionnaire will not be revisited until the annual review in the following January. That is nine months where the vendor risk assessment does not reflect what the vendor's app actually contains. Continuous mobile evidence closes that gap by tracking the change as it happens.

Timeline showing a vendor questionnaire response accurate in January drifting from reality as the vendor ships new SDK versions across the year.

What a Questionnaire Cannot See

A well-run vendor risk assessment questionnaire captures what the vendor's compliance function knows about their own posture and is willing to disclose. That is a lot of information and it is genuinely valuable. What it cannot capture is any of the following, because the vendor's compliance function is often being asked about decisions the mobile team made without routing through them, or asked at a moment that does not reflect the current mobile app reality.

The SDK inventory the vendor's mobile app actually ships. Which third-party libraries are bundled in the current production version, at what versions. Vendors sometimes do not know their own current SDK footprint because different mobile team members added different libraries across different sprints, and none of those decisions routed through the compliance function that later completed the questionnaire. This is not the vendor being evasive. This is the workflow reality of how mobile SDK decisions happen.

The subprocessor mapping those SDKs imply. Each SDK typically brings its own data processor and sub-processor relationships. If the vendor's SDK footprint includes Firebase, Segment, Mixpanel, and AppsFlyer, the subprocessor list should reflect Google, Twilio, Mixpanel, and AppsFlyer at minimum. Questionnaire subprocessor lists often miss these because the mobile team added the SDK to solve a technical problem, without necessarily thinking through the subprocessor implications, and the compliance function later filling in the questionnaire may not know which SDKs are shipping now versus which shipped six months ago.

The data flow verification against declared handling. What the app actually transmits when installed and run, versus what the privacy notice and Data Safety declarations describe. The privacy notice was drafted by legal, sometimes by an external law firm. The Data Safety declaration was completed by whoever the vendor put on that task, sometimes at pressure from the store publish deadline. The runtime behaviour was shaped by what SDKs the mobile team integrated. Three different people, three different moments, three different sources of truth. Divergence is not deception. It is the natural consequence of decisions made in parallel by different functions.

The permission scope the app actually requests. What the app requests permission to access at runtime versus what the compliance narrative describes. Permission scope creep across versions is often invisible to the vendor's own compliance team because the mobile team adds permissions when a specific feature needs them, particularly for permissions that seem functionally minor at the time of the release. The compliance conversation about that permission may happen later. It may not happen at all before the release ships.

The version and vulnerability tracking across the vendor's release history. Which known-vulnerable SDK versions the vendor is still shipping. Which platform policy violations are in flight. Which store review clusters indicate technical or security issues the vendor has not disclosed. Which developer response patterns suggest the vendor is or is not actively addressing issues raised by their user base. The mobile team is often aware of these dimensions but the vendor's compliance function may not be, because the reporting relationship between mobile engineering and vendor compliance is often informal and event-driven.

This is not vendor fault-finding. This is the specific evidence gap questionnaire-based assessment produces because of how modern mobile development actually works, and closing that gap is what makes ongoing vendor risk assessment defensible in 2026 rather than a snapshot that ages across the year.

The Vendor Risk Assessment Framework for Mobile Apps

This framework is designed to complement existing SIG or CAIQ-based assessment, not replace it. It also complements your vendor due diligence checklist rather than duplicating it. The signals below are added to the vendor risk profile alongside the vendor's self-reported answers, and reviewed together during onboarding and ongoing monitoring cycles.

The signals split naturally into two groups by what evidence they require. Store-surface signals can be tracked continuously across the vendor's release cadence because they read what the vendor publicly declares to the app stores. Package-level signals require reading the app package itself and are typically used for deeper investigation on vendors where the risk profile warrants it. Both are legitimate parts of a mature vendor risk assessment programme; the split reflects the practical reality that continuous monitoring at store-surface depth scales more affordably than continuous package-level analysis of every vendor in scope.

Store-surface signals for continuous monitoring:

Release cadence and version tracking. How often the vendor ships new versions of their mobile app, on which platforms, with what stated changes. Release notes reveal what the vendor decided mattered enough to communicate publicly. Cadence patterns reveal whether engineering discipline has changed since the last assessment. Divergence between iOS and Android release timing reveals platform prioritisation.

Data Safety and privacy label declarations. What the vendor declares to Google Play's Data Safety section and Apple's App Store privacy labels, and how those declarations change across releases. Declaration changes are a direct compliance-relevant signal, particularly when they occur outside the vendor's annual questionnaire review cycle.

Permission requests as declared at store level. What permissions the vendor's app requests, as visible in the app store metadata, and how those requests change across versions. Store-declared permission scope drift is the earliest signal that runtime permission scope may have drifted too.

Review sentiment patterns and clusters. How the vendor's app is being received by its user base, with particular attention to one-star review clusters that name specific issues. Reviews clustering around data handling concerns, permission unexpected behaviour, or security issues are diagnostic of problems the vendor may not have disclosed through formal channels.

Developer response cadence and quality. Whether the vendor is actively responding to negative reviews, particularly those raising security or data handling concerns. Response patterns reveal customer engagement discipline and the maturity of the vendor's incident response for user-visible issues.

Store standing changes over time. Ratings distribution, review count, category positioning, and store metadata changes across the vendor's release history. Material shifts in any of these are event-triggered assessment prompts.

Package-level signals for deeper investigation:

SDK inventory verification. Reading the vendor's mobile app package to identify which third-party libraries are actually bundled, at what versions, on both platforms. This is what verifies whether the vendor's declared SDKs match shipped SDKs.

Subprocessor mapping from shipped SDKs. Deriving the actual subprocessor implications from the identified SDK footprint, and comparing against the vendor's declared subprocessor list. Gaps between derived and declared are direct compliance-relevant findings.

Deep permission analysis at binary level. Reading what the app requests at runtime versus what the store metadata declares versus what the vendor's privacy narrative describes. Three-way divergence is the highest-signal compliance finding.

Data flow verification against declared handling. Confirming that the app's actual data transmission matches the vendor's stated data handling. Requires binary-level analysis and typically forms part of periodic deeper review rather than continuous monitoring.

Read together, the store-surface signals provide the continuous evidence layer that keeps a vendor risk assessment current between formal reviews. The package-level signals provide the deeper investigative capability for vendors where the risk profile, incident, or contract review warrants it. Neither replaces the SIG or CAIQ questionnaire process. Both make the vendor risk picture materially more accurate than the questionnaire alone can produce.

Two-layer diagram showing store-surface signals for continuous monitoring on the top layer and package-level signals for deeper investigation on the bottom.

How This Fits Into Ongoing Vendor Risk Management

Most TPRM teams already have their assessment cadence dialled in. Annual reviews for most vendors, more frequent for critical ones, event-triggered for material changes. This article is not proposing to change that cadence.

What this article proposes is a specific insertion point in the existing workflow. When a vendor ships a new version of their mobile app, the risk picture may have changed. Store-surface signals flag the material changes as they happen, feeding into the existing TPRM workflow rather than replacing it. The team then decides whether the change triggers a re-assessment, an event review, or just an updated risk note in the vendor file.

That is a small procedural change with a large accuracy benefit. The vendor risk register describes a vendor's current posture rather than the vendor's posture at the moment of the last questionnaire. Ongoing monitoring platforms already track security rating changes, breach notifications, and regulatory events. Continuous mobile evidence adds the specific dimension that neither questionnaires nor security ratings can produce: what the vendor's app actually ships across its release cycle.

For deeper investigation on specific vendors, package-level analysis produces the SDK inventory verification, subprocessor mapping, and permission analysis that closes the gap between vendor self-report and vendor reality on the questions where it matters most. That deeper work is typically triggered by an event (new critical vendor, contract renewal, incident, regulatory finding, planned expansion) rather than being run continuously for every vendor.

Appnalysis contributes to the wider evidence layer that mobile-first vendor risk assessment increasingly runs on, alongside governance, risk, and compliance (GRC) platforms for workflow and record-keeping, security rating services for public-posture indicators, compliance automation tools for control tracking, and questionnaire platforms for the SIG and CAIQ exchange itself. Each does a different job in the same programme.

How Appnalysis Fits Into a Third-Party Risk Management (TPRM) Workflow

We built Appnalysis because I could see this gap from both sides. On the mobile engineering side I knew how SDK decisions actually got made and how quickly the reality moved between formal reviews. On the vendor risk assessment side I saw teams doing serious work with SIG and CAIQ and getting answers that did not reflect what the vendor's mobile app was actually shipping. Nobody was closing that gap because nobody was reading the app packages directly and comparing them against what the questionnaire said.

Appnalysis does that specific job. Two categories of evidence for TPRM readers, and it is worth being specific about what each does.

App Store Intelligence covers the continuous monitoring layer described above. Release cadence and version notes, Data Safety and privacy label declarations, permission requests as declared at store level, review patterns and sentiment shifts, developer response behaviour, and store standing changes over time. These are the signals a TPRM team reads to keep vendor risk assessment current between formal reviews.

App Intelligence covers the deeper investigation layer. SDK inventory verification, subprocessor mapping from shipped SDKs, deep permission analysis at binary level, and data flow verification against declared handling. These require reading the vendor's app package directly and are typically used for the vendors and moments where the risk profile warrants deeper analysis.

Being straight about what Appnalysis does not do. It does not replace SIG or CAIQ questionnaires. It does not replace the TPRM platform's workflow and record-keeping. It does not replace security rating services like Bitsight or Panorays. It does not replace the vendor conversation itself. It contributes the specific dimension of mobile evidence that questionnaire-based assessment, security ratings, and vendor self-report cannot produce because that evidence requires reading the vendor's mobile app directly.

For TPRM teams using AI-assisted workflows (Claude Code, Cursor, Codex, Gemini in Android Studio, or JetBrains AI Assistant with MCP configured), Appnalysis is available as a knowledge specialist that agents can query directly during vendor assessment work. That pattern is covered in more depth in Your AI Coding Agent Only Sees Half the Picture, which explains how knowledge-domain MCP servers extend AI workflows beyond training data into current app evidence.

Try Appnalysis Against a Vendor You Are Assessing

The fastest way to see whether continuous mobile evidence closes a meaningful gap in your vendor risk assessment is to try it on a specific vendor you are currently evaluating or monitoring. Bring the vendor's mobile app and ask Appnalysis for the signals that map to your existing questionnaire responses.

For store-surface evidence (release history, permission requests, Data Safety declarations, review patterns, developer responses, store standing) the App Store Intelligence tier is designed for the continuous monitoring cadence a TPRM programme needs.

For deeper investigation (SDK inventory verification, subprocessor mapping, deep permission analysis, data flow verification) the App Intelligence tier provides the package-level depth that the vendors and moments where risk warrants it.

Frequently Asked Questions

[FAQ_START]

[FAQ_END]