Sumsub’s transparency rebuttal shows the governance gap in vendor due diligence

At a glance

What this is: Sumsub’s response is a transparency and governance rebuttal that centers on ownership, operating history, data residency, and disclosure practices.

Why it matters: It matters because vendor due diligence for identity programmes depends on verifiable control, legal structure, and data-handling evidence, not just assurances.

👉 Read Sumsub’s response to allegations about ownership, transparency, and data handling

Context

Vendor transparency becomes an identity governance issue when procurement, audit, and security teams have to decide whether an organisation’s ownership, control structure, and data-processing claims are independently verifiable. In regulated environments, those claims shape third-party risk decisions just as much as access controls do, especially when the supplier handles sensitive identity data.

Sumsub’s article is a rebuttal to public allegations about beneficial ownership, Russia-linked exposure, and data-transfer practices. The practical question for practitioners is not whether any one allegation is persuasive, but what evidence a supplier must produce when its trust posture is being challenged.

The topic sits at the intersection of vendor due diligence, compliance evidence, and trust validation. For teams running IAM, IGA, or NHI programmes, the lesson is that trust is not a statement. It is an evidence trail that must survive scrutiny.

Key questions

Q: How should security teams assess a vendor’s ownership claims during due diligence?

A: Security teams should require verifiable corporate records, not just a written statement. Look for beneficial ownership filings, control disclosures, board links, and jurisdictional records that can be reconciled with the supplier’s own trust documents. If the story changes across sources, treat that as a governance issue until it is resolved through evidence.

Q: Why do data residency claims matter in third-party risk reviews?

A: Data residency claims determine where personal or regulated data can be stored, processed, and accessed, which affects legal exposure and operational control. If a vendor cannot clearly identify hosting regions, sub-processors, and contractual restrictions, security teams cannot judge whether the service fits the organisation’s compliance boundary.

Q: What do security teams get wrong about Trust Centers?

A: Teams often treat a Trust Center as proof rather than evidence. A Trust Center is only useful when its certifications, policies, processor lists, and audit artefacts are current and consistent with the vendor’s actual operating model. Otherwise, it is just a curated summary that still needs independent validation.

Q: Who should own vendor transparency decisions when allegations arise?

A: Procurement, legal, security, and risk owners should share the decision, because transparency disputes are both contractual and operational. The key is to define who can pause onboarding, who can demand evidence, and who can approve exceptions before the supplier becomes embedded in sensitive workflows.

Technical breakdown

Vendor ownership evidence and control structure

Ownership claims matter because they determine who can exercise control, who must be disclosed, and who may influence operational decisions. In regulated procurement, ultimate beneficial ownership, PSC records, and holding-company structure are part of the evidence set used to test whether a supplier is independently governed or indirectly controlled. When those facts are disputed, the technical issue is not branding but whether the control chain can be verified through public records, legal filings, and corroborating disclosures.

Practical implication: require documented ownership evidence, not narrative assurances, before allowing a supplier to process identity or secrets data.

Data residency, sub-processors, and trust centre evidence

Data residency is only meaningful when paired with processor location, sub-processor disclosures, and contractual restrictions on where personal data can flow. A Trust Center is useful only if it contains specific artefacts such as certifications, privacy terms, and current processor information that can be checked against the vendor’s stated hosting model. For identity teams, this is part of supplier control validation, not a legal formality.

Practical implication: map supplier data flows and sub-processors to your third-party risk criteria before approving sensitive identity workloads.

Compliance claims and due-diligence artefacts

Compliance posture should be evaluated through auditable artefacts, not broad statements about transparency. Certifications, attestations, public filings, and regulator-facing disclosures help establish whether a vendor’s control environment is stable enough to support regulated use cases. The question is whether the evidence is current, consistent, and sufficient for the sensitivity of the service being consumed.

Practical implication: align procurement checkpoints to artefact review, and fail closed when the evidence set is incomplete or inconsistent.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor transparency is a governance control, not a communications function. When a supplier handles identity-adjacent or other sensitive data, its ownership structure, operating jurisdiction, and disclosure record become part of the risk posture. Security teams that treat these as reputational issues miss the control point entirely. The practitioner conclusion is that due diligence must test evidence quality, not narrative confidence.

Trust Center content only reduces risk when it is specific, current, and independently checkable. A certifications page or sub-processor list does not prove control by itself. It becomes meaningful when procurement, security, and legal teams can reconcile it with filings, residency claims, and contractual obligations. The practitioner conclusion is that supplier trust evidence should be cross-verified, not accepted at face value.

Third-party risk for identity programmes is really lifecycle governance for vendors. Suppliers enter, change, and exit the environment just like service accounts do, but many organisations never formalise offboarding, reassessment, or scope review for them. The practitioner conclusion is that vendor lifecycle controls should be managed with the same discipline as privileged access reviews.

Opaque ownership claims create an evidence gap that compliance teams cannot absorb with policy language alone. The article’s central problem is not merely allegation versus denial, but whether the organisation can produce a coherent record that stands up to regulator, auditor, and customer scrutiny. The practitioner conclusion is that procurement teams need a defined standard for proof, not an ad hoc response to controversy.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly supplier opacity becomes an identity governance problem when delegated access is involved.
• That visibility gap is why teams should pair due diligence with lifecycle controls, as covered in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Vendor trust will keep moving from procurement language into identity governance language. As regulated organisations expand their dependency on third parties, they will need repeatable proof for ownership, data residency, and control structure, not just a one-time review. The practical signal is that supplier onboarding and access approval are converging into a single governance workflow.

Opaque providers create compounding risk because the evidence gap sits upstream of access decisions. If teams cannot verify who controls a supplier or where data is processed, they should not assume downstream access reviews will compensate. This is especially true where identity data, verification workflows, or secrets handling are part of the service.

The broader pattern is that third-party risk is becoming a lifecycle problem. Organisations will increasingly need to review vendor control changes, offboard providers cleanly, and maintain auditable records in the same way they do for privileged internal identities.

For practitioners

• Require ownership proof during supplier onboarding Collect UBO records, PSC filings, and corporate structure documents before any supplier receives access to regulated identity, fraud, or trust data. Revalidate the record when ownership, jurisdiction, or control changes occur.
• Tie vendor approval to current trust artefacts Review certifications, attestation reports, privacy notices, and sub-processor lists as a single evidence pack. Do not approve a supplier if the artefacts conflict with its stated data-residency or processing model.
• Build offboarding checks for third-party providers Treat suppliers as governed identities with entry, review, and exit states. Remove access, contract rights, and data-processing permissions when the relationship changes, then archive the evidence for audit.
• Escalate unresolved transparency gaps to risk owners If public disclosures, private assurances, and contract terms do not align, route the case to legal, procurement, and security leadership before the relationship expands or renews.

Key takeaways

• This article is about supplier transparency disputes, but the governance lesson is that ownership and control evidence are part of the security model.
• The most relevant risk is not a single allegation but the possibility that procurement accepts narrative assurances where it should demand verifiable artefacts.
• Teams should treat vendor due diligence as a lifecycle process with onboarding, review, and offboarding checkpoints tied to evidence, not opinion.

Key terms

• Ultimate Beneficial Owner: The person or people who ultimately control or benefit from a company, even if that control is held through layers of legal entities or trusts. In security and compliance reviews, UBO evidence helps determine who can influence operations, contracts, and risk decisions.
• Trust Center: A vendor-published collection of security, privacy, and compliance artefacts used to support customer due diligence. It is only useful when the information is current, specific, and consistent with contractual and operational reality, rather than being a marketing summary.
• Sub-processor: A downstream third party that processes data on behalf of a primary processor. For regulated identity services, sub-processor visibility matters because it defines where data may flow, who can touch it, and whether the supplier’s assurances match its actual processing chain.
• Third-Party Risk: The security and compliance exposure created by dependence on external suppliers, contractors, or service providers. In identity programmes, third-party risk includes ownership opacity, data residency uncertainty, access scope, and offboarding failures that can outlive the business relationship.

Deepen your knowledge

Vendor ownership and trust verification are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme depends on third-party identity or sensitive data handling, it is worth exploring.

This post draws on content published by Sumsub: a rebuttal of public allegations about ownership, Russia ties, data handling, and transparency. Read the original.