Third-party vendor management is a super important part of security and compliance. Much of the work starts with the onboarding assessment, when you’re deciding whether a vendor meets your requirements and whether you can accept the risk of bringing them into the organisation. Once they’re onboarded, ongoing management becomes another part of the job. You don’t want to just forget they’re there and let everything slide. The decisions you make during the initial review give you something to work from throughout that relationship.
Define the review and its owners
Vendor reviews typically focus on technology providers that will integrate with internal systems or process confidential information on behalf of the organisation. The assessment is designed to verify that vendors meet information security, privacy, and legal obligations.
In the EU, Article 21(2)(d) of the NIS2 Directive (Directive (EU) 2022/2555) makes supply chain security, including relationships with direct suppliers and service providers, one of the measures that essential and important entities must take under each Member State’s national law. EU financial entities have been subject to the ICT third-party risk rules in Articles 28 to 30 of DORA (Regulation (EU) 2022/2554) since 17 January 2025.
The review generally brings together compliance, legal, IT, security, and procurement teams, who collectively evaluate the vendor’s suitability and alignment with existing systems and requirements. In the EU, where a data protection officer is designated, Article 38(1) of the GDPR requires that they are involved, properly and in a timely manner, in issues relating to the protection of personal data, which includes reviews of vendors that will process it.
The review generally depends on risk. A high-risk vendor should get more scrutiny than a lower-risk one. A production system vendor and a marketing events manager may warrant very different reviews, depending on which systems and data they touch and the sensitivity of the information being shared. You need to understand what data they’re accessing and what systems they’re going into. Those differences can make the reviews look very different, even when the vendors go through the same overall process.
Coordination among internal stakeholders is essential. Each team (compliance, security, IT, legal, and procurement) brings distinct requirements to the evaluation process. Agreeing collective requirements at the outset shortens the review and keeps vendor assessments both thorough and efficient.
A standardised process for vendor assessments promotes consistency and fairness, with variations justified only by differences in data sensitivity, access risk, or processing activities. Coordinating across teams minimises redundant requests and gives vendors clear expectations. The review team needs a full understanding of both the requirements and the vendor’s risk to make an informed decision.
Match the assessment to the risk
Early risk assessment speeds up the review by aligning the level of scrutiny with the vendor’s risk profile. Lower-risk vendors may be subject to a streamlined review, while functional requirements must still be addressed. Where multiple vendors are under consideration, comparative risk analysis informs selection. Distinguish between non-negotiable requirements and risks that may only become apparent during further engagement with the vendor.
Risk assessment should start alongside the business case for engaging the vendor. As the review progresses, it becomes clearer which systems the vendor will access and how sensitive the information to be processed is. Initial risk classifications may be adjusted as further details are established, but high-risk vendors are typically identified early and managed accordingly. Risk discussions should start early and continue throughout the review.
Engaging a vendor to process data subject to HIPAA in the US, or health data and the other special categories of personal data in Article 9(1) GDPR in the EU, is a higher-risk scenario that calls for comprehensive due diligence. Where the processing is likely to result in a high risk to individuals’ rights and freedoms, Article 35(1) GDPR also requires a data protection impact assessment before it starts. Conversely, vendors providing services with limited access to sensitive information, such as marketing platforms without access to customer data, may be classified as lower risk and reviewed accordingly, unless further assessment indicates otherwise.
Start with the vendor’s evidence
With that context in place, you can look at the information vendors commonly provide. In the US, there used to be a lot of requests for the Standardized Information Gathering (SIG) questionnaire, including SIG Lite and SIG Core. SIG Lite is sometimes described as the free option and SIG Core as the paid one. Shared Assessments, the US consortium that publishes the SIG, describes Lite and Core as different scopes of its SIG questionnaire, with the scope chosen according to the depth of assessment required. Its current FAQ, however, states that the SIG is not free to download and is available to members or through an annual subscription.
It’s also common to ask for a US System and Organization Controls (SOC) 2 report or an international ISO/IEC 27001 certification. US companies often treat those as interchangeable for a vendor review. We would personally put more weight on ISO/IEC 27001: the standard changed substantially with its 2022 edition, and we consider an ISO/IEC 27001 programme a lot harder to maintain than keeping up with SOC 2. The documents provide different forms of assurance. A SOC 2 report comes from a CPA’s examination of a service organisation’s controls against the AICPA Trust Services Criteria, while ISO/IEC 27001 sets requirements for an information security management system. Outside the US, SOC 2-type reports are also issued under the IAASB’s international ISAE 3000 (Revised) standard. Cloud vendors selling in Germany or France may also hold Germany’s BSI C5 attestation, whose C5:2026 catalogue applies from 1 June 2027, or France’s ANSSI SecNumCloud qualification.
You can also ask for the Consensus Assessments Initiative Questionnaire (CAIQ) from the Cloud Security Alliance’s Security, Trust, Assurance and Risk programme, usually called CSA STAR. It can provide a good amount of baseline information about a vendor’s security controls and cover privacy considerations as well. These materials give you a way to start the review with information the vendor may already have documented.
The review process should begin with the vendor’s standard documentation package, which often includes standardised questionnaires such as SIG or internally developed equivalents. The review team should assess whether the provided materials satisfy organisational requirements. Where gaps remain, a supplementary questionnaire can cover the outstanding information. Starting from existing documentation saves time and avoids duplicated effort.
The standard package may still leave you with specific documents to request. You may want privacy notices, terms of use, cyber insurance, business continuity and disaster recovery plans, or cyber incident response plans. Specific policies and insurance information are often things you have to ask for separately. The same goes for penetration testing results. A SOC 2 often covers a penetration test only in the sense that the auditors check whether one was done. If you actually want to see the results, you usually need to request them.
In the EU, where a vendor will process personal data on your behalf, also ask for its data processing agreement (the contract Article 28(3) GDPR requires), its list of subprocessors and where they process data, and the mechanism it uses for any transfer outside the EEA under Chapter V GDPR. For US vendors, check whether they rely on certification under the EU-US Data Privacy Framework or on standard contractual clauses under Article 46(2)(c). The EU General Court upheld the Framework’s adequacy decision on 3 September 2025 in Latombe v Commission (T-553/23), and an appeal is pending before the Court of Justice of the EU (C-703/25 P).
Those requests can become part of the team’s standardised list of things it wants to see. Whether or not the vendor has those documents, the team can talk through which ones it absolutely needs and what any gaps mean for the review. Some of this depends on the vendor and the information involved. Putting documents on a trust portal behind a nondisclosure agreement can make it easier to give prospective customers the information they ask for. More sensitive material, such as insurance policies and penetration testing results, may still come through additional requests after the first package.
For vendors, providing a centralised portal for due diligence documentation can speed up the review considerably. Larger vendors often maintain such portals, where documents are shared under a nondisclosure agreement. Smaller vendors may not have one yet and may provide documentation on a more ad hoc basis.
Agree how to close compliance gaps
Where a required solution is only available from a smaller or less mature vendor, assess the current state of the vendor’s security and compliance programme and evaluate any remediation plans for identified gaps. Where a vendor is still obtaining ISO/IEC 27001 certification or a SOC 2 report, the organisation may consider interim risk mitigation measures while the vendor works towards full compliance.
On the vendor side, a company may need HITRUST, a certification that grew out of US healthcare, or a specific ISO standard for a prospective customer before it has one. If it is the right deal, it can negotiate milestones and keep reporting to that customer on what it has just completed and what comes next. Showing the roadmap and continuing to make progress can secure those deals. That is a reason to ask a smaller company what it’s doing now, what its plan is to remediate its gaps, and how transparent it can be about its shortcomings.
The organisation must decide whether the vendor’s remediation plan is acceptable. That may mean restricting data access or limiting information sharing until specific milestones are achieved. Open communication with the vendor makes it easier to find workable interim arrangements. In some cases, organisations may proceed with a vendor that demonstrates ongoing progress towards compliance, provided that risk is appropriately managed.
Negotiation is often more flexible with smaller vendors or startups, which may be more responsive to customer requirements. Where specific certifications such as HITRUST are required, organisations should seek clear commitments and timelines for obtaining them, written into the contract. Commercial terms may also be adjusted to reflect any compliance gaps during the engagement period.
Even with flexibility in negotiations, vendors may only partially meet organisational requirements. Evaluate how significant each gap is and prioritise the critical ones. Where functional requirements are comparable, non-functional requirements such as security and compliance become decisive. Each team should clearly distinguish between negotiable and non-negotiable criteria during the selection process.
How much flexibility the review allows depends on the vendor’s risk profile and system access. Lower-risk vendors may be subject to a simplified review, while vendors with access to critical systems or sensitive data need a stricter evaluation. The review team must be satisfied that the vendor can safeguard the data entrusted to it.
Record decisions and accountability
All decisions, including vendor rejections, should be thoroughly documented, with clear justification for each outcome. This makes the process repeatable and transparent, keeps future evaluations consistent, and saves time because evaluators can refer back to earlier decisions and their rationale.
At this stage, multiple documents and departmental inputs must be consolidated. Effective reviews use structured mechanisms, such as workflow management systems or shared documentation, to capture concerns, decisions, and required actions. Assigning responsibilities to specific teams and documenting their inputs gives accountability and traceability throughout the review.
This structured approach makes the review audit-ready, because it gives clear attribution of decisions and a documented decision trail. Maintaining records (whether in workflow systems, spreadsheets, or other formats) lets the organisation demonstrate compliance and accountability during audits.
A common pitfall is a decision made in a meeting that is never properly written down, which makes it hard to justify risk classifications or point to the supporting material later. Records should give the rationale for each decision so that the same criteria can be applied consistently in future cases.
Documentation of risk decisions is part of the wider risk management framework. Risks may be accepted, remediated, or mitigated, but in all cases, the rationale and planned response should be clearly recorded. For accepted risks, documentation should specify the justification and any contingency plans, so that the organisation can respond if the risk materialises.
Put commitments into the contract
Once the review process is complete and the team has reached consensus, risk acceptance and mitigation measures should be formally documented. They should be written into the contract, with reference to the risk register where appropriate. Ideally, all relevant issues are addressed before legal negotiations begin.
At this stage, all material issues should be identified and addressed. The legal team should have reviewed and flagged any contractual terms requiring negotiation. Security and data breach requirements must be clearly defined and documented within the contract. For EU financial entities, Article 30(2) of DORA sets the minimum content of every contract for ICT services, and Article 30(3) adds further provisions where the service supports critical or important functions. Where SOC 2, ISAE 3000 or similar assurance reports are required, the contract should explicitly require the relevant examinations so that the obligation is clear and enforceable.
Standard terms, especially terms published online, deserve attention here. The legal team needs to look for the requirements that matter to the organisation and make sure the breach response obligations are actually codified. Document those obligations in the terms of service or, for US health data, in a business associate agreement (BAA) agreed later. The purpose is to have them documented somewhere the legal team can rely on if there’s an incident. In the US, where HIPAA requires a BAA, the agreement needs to be in place before the vendor handles protected health information on behalf of a covered entity or another business associate (45 CFR 164.502(e)).
In the EU, the counterpart is the contract that Article 28(3) GDPR requires whenever a vendor processes personal data on your behalf, including the vendor’s duty to assist you with breach notification. Article 33(2) requires the processor to notify you without undue delay after becoming aware of a personal data breach, and Article 33(1) gives you 72 hours, where feasible, to notify the supervisory authority.
Monitor the relationship
After signature, ongoing monitoring checks that the vendor meets its agreed commitments. Review frequency depends on the criticality of the vendor and the nature of the services provided, with annual reviews common and more frequent assessments for high-risk vendors. The cadence should align with the organisation’s risk management strategy and the specific controls being monitored.
Annual reviews give finance a chance to verify contractual billing arrangements and compliance a chance to confirm that the required information and evidence are maintained. Schedule regular reviews that cover both the onboarding criteria and any changes that have occurred since vendor approval.
Product evolution, such as the introduction of artificial intelligence, new cloud functionalities, or additional subprocessors, can alter the risk profile of the vendor relationship. Ongoing management means watching for such developments and assessing what they mean for organisational systems and data. The initial assessment is the baseline for evaluating later changes. In the EU, under Article 28(2) GDPR, a processor working under a general written authorisation must tell you about any intended addition or replacement of subprocessors, which gives you the opportunity to object. For software products sold in the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847) has required manufacturers since 11 September 2026 to report actively exploited vulnerabilities and severe incidents and to inform impacted users (Article 14). Most of its other obligations apply from 11 December 2027.
Review the vendor’s use of AI
AI tools raise specific questions in the review. Key questions include whether organisational data is used for model training and how such data is managed and protected. If a processor uses your personal data to train its own models beyond your instructions, it determines the purposes and means of that processing, and in the EU, Article 28(10) GDPR treats it as a controller in respect of that processing. The overall review framework stays the same, but AI warrants additional scrutiny for its specific risks.
Organisations should request AI usage statements from technology vendors, detailing the tools employed, whether customer data is used for model training, and whether models are internal or external. Adding these questions to the standard vendor review gives you transparency and a sound basis for assessing the risk of the vendor’s AI use. If the tool is a high-risk AI system under the EU AI Act (Regulation (EU) 2024/1689), your organisation also carries the deployer obligations in Article 26. Under the Digital Omnibus on AI (Regulation (EU) 2026/1744), those obligations apply from 2 December 2027 for high-risk systems listed in Annex III and from 2 August 2028 for those covered by Annex I.
Vendor reviews may feel routine, but working closely with tool managers and setting clear responsibilities makes them faster and more consistent. Standardised processes, aligned with vendor risk and criticality, keep reviews predictable and manageable. Clear requirements and a regular review schedule let every stakeholder know what to expect and keep the compliance function efficient.