A reliable vendor due diligence process does more than collect a SOC 2 report or signed DPA. It connects the vendor’s data access, security controls, contractual commitments, and audit evidence to the risks your organization must manage. This guide provides a repeatable checklist for assessing SaaS and cloud providers, preparing an audit-ready evidence package, and deciding when an existing assessment needs to be refreshed.
Overview
Vendor due diligence should begin before procurement approval and continue throughout the relationship. The objective is not to prove that a provider is risk-free. It is to document the services being purchased, identify the data and systems involved, evaluate relevant safeguards, record any gaps, and assign decisions to accountable people.
Start with a short vendor profile. Record the service name, business owner, technical owner, contract dates, renewal date, environments used, countries involved in processing, data categories, and the vendor’s access level. Classify the relationship by impact. A provider that stores customer health information, payment data, authentication records, or production credentials generally requires more scrutiny than a tool used for non-sensitive internal collaboration.
Use the assessment to support the requirements that apply to your organization. GDPR and other data protection obligations may require a clear controller-processor relationship, documented processing instructions, appropriate security measures, and controls for international transfers. SOC 2 and ISO 27001 assessments can help evaluate governance and control design, but a report does not automatically satisfy every internal requirement. HIPAA-related use cases may require a business associate agreement and safeguards appropriate to the services and information involved. PCI DSS responsibilities depend on the payment environment and the division of responsibilities between your organization and its providers.
Keep these conclusions separate from legal advice. A DPA template, risk assessment template, or control mapping is a starting point for review, not a substitute for confirming obligations with qualified privacy, security, or legal personnel.
What to track
A practical vendor risk record should contain both answers and evidence. Track the following fields consistently across vendors:
- Scope and data: services provided, business purpose, data subjects, data categories, retention needs, locations of processing, and whether the provider can access production systems.
- Security governance: security policies, accountable contacts, risk management, employee training, background screening where relevant, and the process for reporting control changes.
- Identity and access: single sign-on, multifactor authentication, role-based access, privileged access review, joiner-mover-leaver procedures, service accounts, and customer control over administrator access.
- Technical safeguards: encryption in transit and at rest, key management, tenant separation, vulnerability management, secure development practices, logging, monitoring, backups, and recovery testing.
- Resilience and incidents: availability commitments, recovery objectives, incident response procedures, notification timelines, breach communications, and lessons-learned processes.
- Sub-processors and transfers: current sub-processor list, notice and objection procedures, hosting regions, transfer mechanisms where applicable, and deletion or return obligations at termination.
- Assurance evidence: SOC 2 report, ISO 27001 certificate and scope, penetration-test summary, independent assessment, policy excerpts, security questionnaire answers, and remediation plans.
Request evidence that matches the question. For example, a statement that access is reviewed is weaker than a dated access-review record or a clearly described review process. Record the evidence owner, date received, coverage period, scope, exceptions, and expiration or review date. Store the final package in a controlled location with appropriate access restrictions. For guidance on organizing evidence for ISO 27001 and SOC 2, see the PrivateBin audit readiness evidence checklist.
The DPA should be tracked as a control document, not merely a procurement attachment. Check the documented processing instructions, confidentiality duties, security measures, assistance with individual rights, breach communication process, audit or inspection rights, sub-processor terms, deletion or return of data, and international transfer provisions. If standard contractual clauses are used, confirm that the selected modules and annexes reflect the actual processing arrangement and obtain appropriate legal review.
Cadence and checkpoints
Use a risk-based cadence rather than treating every vendor identically. A quarterly review may be appropriate for critical providers, vendors with privileged access, or services handling sensitive regulated data. A semiannual or annual review may be sufficient for lower-impact services, provided there is a trigger-based process for material changes.
At onboarding, complete the full assessment before granting production access or transferring sensitive data. During contract renewal, confirm that the DPA, security commitments, sub-processor terms, service scope, and data locations still match reality. After a major product, ownership, hosting, or architecture change, request updated documentation rather than relying on the previous assessment.
Use a simple checkpoint calendar with these minimum fields:
- assessment owner and business owner;
- risk tier and approval status;
- last assessment and next review date;
- DPA signature date and contract renewal date;
- evidence coverage period and expiration dates;
- open findings, compensating controls, and target resolution dates; and
- events that require an interim review.
Useful interim triggers include a security incident, material control failure, significant change in data processing, new sub-processor, change in hosting region, new regulatory requirement relevant to the service, negative audit finding, or a request to expand the vendor’s access. Your own incident response and secure file-sharing procedures should also be reflected in the vendor record. The PrivateBin incident response runbook illustrates why ownership, escalation, and evidence handling should be defined before an event occurs.
How to interpret changes
Do not treat a completed questionnaire as a risk score by itself. Interpret each answer in context. A vendor may have strong encryption but weak administrative access controls, or a current certification whose scope excludes the service your team plans to use. Read the scope, exceptions, complementary user entity controls, and report period before drawing a conclusion.
Classify findings by impact and likelihood, then document the decision. A gap may be accepted, mitigated with a compensating control, assigned for remediation, or treated as a reason not to proceed. For example, if a vendor cannot support your preferred identity provider, you might restrict administrative accounts, require stronger local controls, monitor access more closely, and set a remediation deadline. The decision should identify who approved the residual risk and when it will be reconsidered.
Map evidence to requirements without overstating what the mapping proves. A questionnaire item about logging may support several internal controls, but it does not by itself establish full SOC 2 readiness, ISO 27001 compliance, GDPR compliance, HIPAA compliance for SaaS, or PCI DSS compliance. A control-mapping table is most useful when it shows the requirement, the vendor commitment, the evidence supplied, the customer responsibility, and any unresolved limitation.
Pay particular attention to shared responsibility. Confirm who configures retention, enables multifactor authentication, reviews logs, manages keys, approves users, responds to alerts, and deletes exported data. Cloud security best practices often fail in practice when a vendor’s capability is mistaken for a customer’s completed configuration.
When to revisit
Revisit the assessment on its scheduled monthly or quarterly checkpoint, at contract renewal, and whenever a material change occurs. An annual content review of your checklist and DPA package is also useful. Update transfer language, privacy requirements, control mappings, and evidence examples when applicable regulatory or framework guidance changes. Refresh questionnaire model answers as common provider capabilities and cloud shared-responsibility patterns evolve.
Before each review, compare the previous assessment with the current service. Ask whether the data categories, processing locations, sub-processors, access model, retention period, and business criticality have changed. Then request only the evidence needed to close the identified uncertainty. This keeps the process efficient while preserving an audit trail.
For a practical next step, create one controlled vendor record and complete it end to end. Attach the signed DPA, questionnaire, assurance reports, risk decision, open findings, and review dates. Use the PrivateBin security questionnaire guide when standardizing questions, and review your own data retention workflow with the PrivateBin data retention and compliance guide. Repeat the process for critical vendors first, then expand it according to risk. That approach turns due diligence from a one-time procurement task into a maintainable part of audit readiness.
