Vendor Risk Assessment and Data Processing Agreement Checklist for Third Parties

Overview

Third-party risk management works best when procurement, security, privacy, legal, and the business owner review the same facts. Start by documenting what the vendor will do, what information it will handle, where processing will occur, and how important the service is to your operations. A vendor that stores customer records requires a different review from a tool that only handles public marketing content.

Use a tiered process rather than sending every supplier the same lengthy questionnaire. A practical classification can include:

• Low risk: The service handles no confidential or personal data, has limited business impact, and does not connect to sensitive systems.
• Moderate risk: The vendor processes internal, personal, or business-sensitive information, or connects to selected production or corporate systems.
• High risk: The service processes regulated or mission-critical data, has privileged access, supports an essential business process, or could materially affect customers if unavailable or compromised.

Risk classification should determine the depth of review, the evidence requested, the approval level, and the reassessment interval. Record the decision in a vendor register alongside the business owner, contract dates, data categories, approved purpose, security contact, subprocessors, and open risks.

For a broader control and evidence program, pair this process with the audit evidence collection checklist and the compliance control testing checklist.

Checklist by scenario

1. Before onboarding a new SaaS vendor

1. Identify the business owner and document the service purpose.
2. List the data involved: account data, contact details, payment information, credentials, telemetry, support content, or other confidential material.
3. Confirm whether the vendor acts as a processor or service provider, an independent controller, or occupies different roles for different processing activities.
4. Map integrations, authentication methods, API permissions, administrative access, and data export paths.
5. Classify the vendor’s inherent risk before considering its controls.
6. Send a proportionate third-party security questionnaire and evidence request.
7. Check for unresolved exceptions, contract limitations, unsupported assurances, and dependencies on other providers.
8. Complete a privacy review, including the processing purpose, legal basis or business purpose as applicable, retention, individual rights support, and international transfers.
9. Obtain approval from the required security, privacy, legal, procurement, and business owners.
10. Record residual risk and any compensating controls before production access is granted.

2. Third-party security questionnaire and evidence request

Ask questions that can be verified and tied to the service in scope. For a moderate- or high-risk vendor, request the following where relevant:

• A current independent assurance report or certification, with its scope, coverage period, exceptions, and complementary customer responsibilities.
• Information about encryption in transit and at rest, key management, backup protection, and tenant isolation.
• Identity and access management practices, including multifactor authentication, privileged access review, joiner-mover-leaver controls, and administrative logging.
• Vulnerability management, penetration testing, secure development, dependency management, and remediation targets.
• Security monitoring, incident escalation, investigation, and customer notification procedures.
• Business continuity, disaster recovery, backup restoration testing, and service availability commitments.
• Employee screening where appropriate, security awareness, acceptable-use requirements, and confidentiality obligations.
• Data location, retention, deletion, return procedures, and the use of subprocessors.
• Contact details and a route for urgent security or privacy notifications.

Do not treat a certification or report as a complete answer. Confirm that the document covers the product, environment, and period relevant to your purchase. Map important findings to your own controls and record evidence links, dates reviewed, owners, and follow-up actions. Organizations preparing for SOC 2 or ISO 27001 work may find the SOC 2 and ISO 27001 control mapping guide useful when comparing evidence to internal requirements.

3. Data processing agreement checklist

A DPA should describe the actual processing arrangement, not merely repeat broad privacy language. Review whether it clearly addresses:

• Roles and scope: The parties, documented instructions, processing purposes, data categories, affected individuals, and duration.
• Confidentiality: Duties for personnel and anyone authorized to access the data.
• Security measures: Technical and organizational safeguards that are specific enough to evaluate, with a process for handling material changes.
• Assistance: Support for access, deletion, correction, investigations, impact assessments, audits, and other applicable obligations.
• Incident cooperation: How the vendor escalates suspected or confirmed incidents, what information it provides, and how the parties coordinate communications.
• Subprocessors: The authorization model, notice of additions or replacements, objection process, flow-down obligations, and a current list or location for the list.
• International transfers: The transfer mechanism, supplementary safeguards where relevant, transfer assessment responsibilities, and the process for changes in transfer arrangements.
• End of service: Return, deletion, backup handling, retention exceptions, certification or evidence of deletion, and access termination.
• Audit and verification: Reasonable information, audit, or assessment rights and clear limits that do not make verification impractical.
• Precedence: Which document governs if the DPA conflicts with online terms, a security exhibit, or the master services agreement.

Legal and privacy owners should confirm that the agreement fits the jurisdictions and processing activities involved. A checklist supports review; it does not replace legal advice or a documented privacy analysis.

4. Subprocessor and cross-border review

Build a small subprocessor table with these columns: provider name, service provided, data accessed, processing location, transfer mechanism or safeguard, approval status, notification method, and last review date. Ask the primary vendor how it maintains the list and whether it will notify you before a change or only after one occurs.

For cross-border processing, identify the exporter, importer, data flow, applicable transfer instrument, and any supplementary measures. Recheck the arrangement when the vendor changes hosting regions, adds a subprocessor, or changes its legal terms. See the cross-border data transfer review guide for a focused workflow.

5. Renewal or material change

At renewal, compare the current service with the original assessment. Reconfirm data categories, integrations, user permissions, subprocessors, hosting locations, security evidence, open exceptions, breach history or notices, and deletion commitments. A major product change, acquisition, new data use, privileged integration, or security incident should trigger an out-of-cycle review rather than waiting for the annual renewal.

What to double-check before approval

Use a short decision record to prevent a completed questionnaire from being mistaken for approval. Confirm each item below:

• The service owner has approved the intended use and understands the vendor’s limitations.
• The privacy owner has validated the controller-versus-processor analysis and documented the relevant processing activities.
• The DPA, security terms, service agreement, and order form do not contradict one another.
• Security evidence is in scope, current enough for the decision, and accompanied by an explanation of exceptions.
• Critical findings have owners, due dates, compensating controls, or a formally accepted residual risk.
• Access is limited to the minimum required, with a plan for periodic review and prompt removal.
• Incident contacts and escalation paths are usable outside normal business hours when appropriate.
• Exit requirements are technically achievable, including exports, deletion, backup handling, and migration support.
• The vendor is represented in the organization’s risk register, data inventory, and—where applicable—records of processing activities.

If the vendor will support personal-data requests, test the operational path rather than accepting a contractual promise. Send a controlled test request or walk through how the vendor will locate, export, correct, restrict, or delete relevant records. The DSAR compliance checklist can help connect vendor responsibilities to your internal workflow.

Common mistakes

• Using one questionnaire for every vendor: Long forms create noise and do not necessarily improve decisions. Match questions to data, access, and business impact.
• Accepting a badge without checking scope: A certification may cover only a product, region, or period. Read the boundaries and customer responsibilities.
• Reviewing the DPA separately from the architecture: Contract language should reflect actual data flows, hosting, access, retention, and subprocessors.
• Ignoring the exit plan: Determine how data will be returned or deleted before the relationship becomes urgent.
• Approving exceptions informally: Record who accepted the risk, why it is acceptable, what reduces it, and when it expires.
• Failing to monitor change: A vendor can become higher risk when it adds an integration, changes subprocessors, expands processing, or experiences an incident.
• Assuming procurement owns the whole process: Procurement can coordinate, but security, privacy, legal, IT, and the business owner each have distinct decisions.

When to revisit

Set a review date when the vendor is approved, then use risk-based intervals rather than relying on memory. Higher-risk vendors generally warrant more frequent evidence checks; lower-risk vendors may be reviewed less often if their scope remains unchanged. Define the interval in your policy and apply it consistently.

Start an interim review when any of these events occurs:

• The vendor adds or replaces a subprocessor.
• Processing locations, transfer mechanisms, or contract terms change.
• The service gains access to new systems, privileged credentials, or more sensitive data.
• The vendor reports a security incident, material control failure, or significant service change.
• Your organization enters a new jurisdiction, product line, or regulated use case.
• Your privacy, security, retention, or incident response policies change.
• A seasonal planning or budget cycle creates an opportunity to clean up expired approvals and open exceptions.

To put this checklist into operation, create a vendor register today, classify every active third party, assign an owner, attach the current DPA and evidence, and flag missing approvals. Next, select one high-risk vendor for a complete walkthrough: trace its data flows, verify its subprocessors, test its incident contacts, and document the renewal date. Repeat the process whenever workflows or tools change, so vendor risk assessment remains an operating control rather than a one-time procurement form.