Third-Party Privacy & Security Reviews

Third-Party Privacy and Security Reviews

Modern products are assembled from other companies' services: cloud platforms, payment processors, email providers, analytics, support desks, observability tools, AI APIs, and dozens of SaaS apps adopted by individual teams. Each one may receive customer data, connect to internal systems, or hold credentials. A breach at a vendor is still your breach in the eyes of customers and regulators, and a vendor that cannot delete data or let you leave cleanly becomes a long-term liability.

A third-party review answers, before data flows: what will this vendor receive, how will they protect it, who else will they share it with, how long will they keep it, what access do they get to our systems, and how do we get out? Done proportionately — light for low-risk tools, deep for critical processors — it protects users without blocking every purchase.

TL;DR

Keep an inventory of vendors with owners, data categories, and integrations; tier them by risk.
Map data flows: what data goes where, for what purpose, and how it returns or is deleted.
Collect evidence proportionate to risk: SOC 2 Type II reports, ISO 27001 certificates, penetration test summaries, questionnaires.
Put data processing agreements, subprocessor lists, retention and deletion terms, breach notification timelines, and data residency commitments in contracts.
Review access: SSO, MFA, least-privilege roles, API scopes, OAuth permissions, and webhook security.
Ask AI-specific questions, monitor vendors continuously, and plan the exit before you sign.

Quick Example

A review record kept with the vendor inventory:

Core Concepts

Inventory and Risk Tiers

You cannot review vendors you do not know about. Combine procurement records, expense data, SSO application lists, OAuth grants, and network logs to find tools in use. Tier each vendor:

See SaaS Management.

Data Flow Mapping

Document what data each vendor receives, the purpose, the legal basis where relevant, where it is stored and processed, which of the vendor's own subprocessors (fourth parties) receive it, and how it is returned or deleted. Data flow maps feed privacy records of processing and make incident response faster. See GDPR Engineering.

Evidence

Read reports rather than filing them: the scope may exclude the product you are buying, and "complementary user entity controls" list responsibilities that fall on you. See SOC 2 Compliance.

Contracts and Privacy Terms

Data processing agreement (DPA) defining the vendor as processor, permitted purposes, and security obligations.
Subprocessor lists with advance notice of changes and a right to object.
Retention and deletion commitments, including backups, and deletion on termination.
Breach notification timelines that support your own legal obligations.
Data residency and international transfer mechanisms where required.
Audit rights, liability, and insurance proportionate to risk.

See Data Retention.

Access and Integration Security

Vendors often receive access to your systems as well as data. Require SSO and MFA for vendor tools, automatic deprovisioning (for example through SCIM), least-privilege admin roles, narrowly scoped API keys and OAuth scopes, signed webhooks, and IP restrictions where supported. Review OAuth apps that request broad access to email, files, or code repositories.

AI and Machine Learning Vendors

Ask whether your inputs and outputs are used for training, how long prompts and files are retained, whether retention can be disabled, which models and subprocessors process the data, where processing happens, how outputs are filtered, and what happens to data in logs used for abuse monitoring. Prefer contractual commitments over marketing statements.

Continuous Monitoring and Exit

Reassess on a schedule by tier, at renewal, and when scope or data changes.
Monitor breach news, status pages, subprocessor changes, and certification renewals.
Review access regularly: remove unused integrations, rotate credentials, and check admin lists.
Plan the exit: data export formats, migration effort, deletion confirmation, and dependencies to unwind — before signing, while you still have leverage.

Best Practices

Make the Review Proportionate

Fast, lightweight reviews for low-risk tools keep teams from routing around the process; save depth for high-risk vendors.

Minimize What You Share

The cheapest risk to manage is data that never leaves. Send only the fields a vendor needs, pseudonymize where possible, and avoid free-text fields that collect sensitive data. See Privacy by Design.

Involve Engineering in Integration Design

Security and privacy reviewers should see how the integration works — keys, scopes, webhooks, data synchronization — not just the vendor's questionnaire.

Record Decisions and Owners

Every approved vendor has an owner, a review record, accepted risks with justification, and a next review date.

Common Mistakes

Filing SOC 2 Reports Unread

Over-Sharing Through Integrations

No Exit Plan

FAQ

What is a third-party security review?

An assessment of a vendor or service before and during its use, covering what data and access it receives, how it protects them, its subprocessors, contractual commitments, and the risks of depending on it.

What evidence should we ask vendors for?

Proportionate to risk: SOC 2 Type II reports or ISO 27001 certificates, penetration test summaries, completed questionnaires, data processing agreements, subprocessor lists, and documentation of encryption, access controls, and incident response.

What is a subprocessor?

A third party that a vendor uses to process your data, such as its cloud hosting provider or email service. Contracts should require a current list and advance notice of changes.

How often should vendors be reassessed?

By risk tier: annually for high-risk vendors, at renewal or every few years for lower tiers, and whenever the scope, data, or integration changes significantly or the vendor has an incident.

What should we ask AI vendors specifically?

Whether your data is used for training, how long prompts and outputs are retained, which models and subprocessors process them, where processing occurs, and whether contractual terms guarantee these answers.