Compliance

Vendor & Third-Party Risk

Intermediate

Every vendor we rely on (identity providers, payment processors, cloud services, libraries, SaaS tools) becomes part of our security and compliance posture. Their breach can be our breach. Their failure can be our outage. This is the governance side of third parties: due diligence before we adopt them, contracts that protect data, and ongoing review. It works alongside the technical integration rules.

Third-Party Integrations covers how to connect to a vendor safely in code. This topic covers whether, and on what terms, we should rely on them at all. When a vendor processes personal data on our behalf, GDPR makes them our processor and us accountable for them. That means due diligence, a data processing agreement (DPA), knowing where they store data, and tracking sub-processors.

For a regulated platform this is a real obligation and a certification requirement (see Marketplace & Certification Readiness), not box-ticking. Regulators and enterprise customers will ask who we share their data with, and how we satisfy ourselves about those vendors.

Choose vendors deliberately

DoDo due diligence in proportion to the risk before adopting a vendor that touches our systems or data: security posture, certifications (SOC 2 / ISO 27001), data location, and reliability.
DoPut the right contracts in place when a vendor processes personal data: a Data Processing Agreement covering security, sub-processors, breach notification, and data return/deletion.
DoKnow and record where each vendor stores and processes our data, to meet data-residency obligations (see Privacy & Data Protection, Azure & Cloud Platform).
DoGive vendors the least access and least data they need to do their job (see Managed Identity & Least-Privilege).
AlwaysHave any new vendor or data-sharing arrangement that touches customer/personal data reviewed and approved through the proper process before it goes live. Do not onboard one on your own.

Manage the relationship over time

DoKeep an inventory of vendors and what data and access each one has, and review it regularly. Vendor risk is not a one-time check.
DoTrack vendors' own sub-processors and major changes. Treat a vendor's security incident as possibly our incident too (see Incident Readiness).
DoHave an exit plan: be able to get our data back and offboard a vendor (revoke access, delete data) if we leave them.
AvoidRelying on a single vendor with no alternative for a critical function, where you can. It leaves you unable to switch (see Third-Party Integrations).
NeverShare customer or personal data with a third party without an appropriate agreement and a lawful basis for doing so.

Self-review checklist

AskHas this vendor been through due diligence, and is there a DPA if it handles personal data?
AskDo we know where it stores our data, and is that compliant with residency rules?
AskDoes it have the least access and data it needs — and could we offboard it and get our data back?
AskAm I about to share customer data with a third party without approval and an agreement?

Why it matters: We are accountable to our customers and regulators for the third parties we trust with their data. Their weakness becomes our breach, and "a vendor did it" is not a defence. Careful selection, proper contracts, and ongoing review keep our wider supply chain as trustworthy as the parts we build ourselves.