98% of organisations have been breached through their third-party vendor network (SecurityScorecard, 2023). Verizon's Data Breach Investigations Report found that third-party supply chain breaches more than doubled year-over-year in its most recent edition. The perimeter is not your firewall — it is the sum total of every vendor you've given access to your systems.
The compliance obligation is equally clear. ISO 27001 clauses 5.19–5.23 explicitly govern information security in supplier relationships. SOC 2 CC9.1 covers vendor management. HIPAA requires Business Associate Agreements for all business associates. GDPR Article 28 requires Data Processing Agreements for all data processors. Every major security framework treats vendor management as a first-class security control, not an optional best practice.
This guide is a 10-step vendor onboarding checklist covering risk classification, security due diligence, DPA/BAA/SIG Lite documentation, access provisioning, ongoing monitoring, and vendor offboarding — structured for IT managers, security leads, and procurement teams who need to build or improve their vendor management programme.
Why Vendor Onboarding Is a Security Priority
Vendors represent one of the most significant and most undermanaged attack surfaces in enterprise security. 98% of organisations have been breached through their vendor network (SecurityScorecard). Verizon's DBIR noted that supply chain attacks more than doubled in the most recent reporting period — attackers have learned that it is easier to compromise a small vendor with weaker security controls than to attack a large enterprise directly, then use that vendor's legitimate access as the entry vector.
The average organisation uses more than 200 SaaS applications and works with dozens of vendors who have some form of access to internal systems. Each vendor relationship is a trust relationship — and each trust relationship is a potential attack path. A vendor who has broad, unscoped access to your systems and who lacks basic security controls (MFA, encryption, access logging) represents a material risk regardless of how long and trusted the relationship has been. The problem is not malicious vendors; it is vendors whose security posture has not been assessed, whose access has not been scoped, and whose ongoing security is not monitored.
Every major security framework treats vendor management as a required control. ISO 27001 clauses 5.19–5.23 cover information security for supplier relationships. SOC 2 CC9.1 covers the selection and monitoring of service providers. HIPAA requires Business Associate Agreements with all vendors who handle PHI. GDPR Article 28 requires Data Processing Agreements with all data processors. Vendor onboarding is where these compliance requirements are operationalised — not in a policy document, but in a structured process that is followed every time a new vendor relationship begins.
- 98% of organisations breached via third-party vendors (SecurityScorecard, 2023)
- Supply chain breaches doubled year-over-year (Verizon DBIR)
- ISO 27001 clauses 5.19–5.23 govern information security in supplier relationships
- SOC 2 CC9.1 covers vendor selection and monitoring
- HIPAA Omnibus Rule requires BAA for all business associates
- GDPR Article 28 requires DPA for all data processors
Vendor Risk Tier Matrix
Before any due diligence steps begin, every new vendor must be assigned to a risk tier. The tier drives the depth of due diligence required, the contract documents that are mandatory, and the frequency of ongoing review. Applying maximum scrutiny uniformly to all vendors is operationally unsustainable; applying minimum scrutiny uniformly is a security risk. The tier matrix solves this by making due diligence proportional to actual risk.
| Risk Tier | Vendor Category | Data Access | System Access | Due Diligence | Review Frequency |
|---|---|---|---|---|---|
| Tier 1 — High Risk | SaaS platforms with PHI, PII, or financial data; cloud infrastructure providers; security vendors; any vendor with privileged system access | Sensitive regulated data (PHI, PII, financial, IP) | Privileged or broad | Full security review: SIG or SOC 2 Type II, pen test review, reference checks, site visit (optional) | Annual + event-triggered |
| Tier 2 — Medium Risk | Internal tools with access to non-regulated internal data; vendors with limited system access | Internal non-regulated data | Limited, scoped | Standard security questionnaire, contractual security requirements, insurance verification | Annual |
| Tier 3 — Low Risk | Vendors with no access to internal systems or data (office supplies, facilities, print vendors) | No data access | No system access | Standard contractual terms | At contract renewal |
Assign every new vendor to a tier as the first step in the onboarding process. The tier assignment determines which subsequent steps are required. A Tier 3 vendor requires a contract and standard due diligence. A Tier 1 vendor requires the full 10-step process. The tier is assigned by IT security or the designated vendor risk owner — not by the business owner requesting the vendor, who has an inherent interest in moving quickly. This separation ensures that risk classification is independent of commercial pressure.
Steps 1–2: Business and Procurement Approval
Business Justification and Procurement Request
Every new vendor relationship begins with a formal business justification: what is the vendor being engaged for, what problem does it solve, what alternatives were considered, and what is the commercial scope (one-time, recurring, contract value)? The procurement request should capture: vendor name and product or service, business owner and department, intended data access scope (what data will the vendor access?), intended system access scope (what systems will the vendor connect to?), and the approximate start date.
This step exists to catch vendor engagements before they happen, not after. Shadow procurement — individual team members signing up for SaaS tools without IT or security visibility — is one of the primary sources of unmanaged vendor risk. A lightweight procurement request process creates the visibility that enables vendor risk management. It does not need to block or slow legitimate vendor engagements; it simply ensures every vendor relationship enters the risk management pipeline from day one.
Initial Risk Tier Assignment
Using the risk tier matrix from the previous section, assign the vendor to a tier based on the information in the procurement request. The tier assignment is made by IT security or the designated vendor risk owner — not by the business owner requesting the vendor. The tier assignment determines: which due diligence steps are required, which contract documents are mandatory, and how long the full onboarding process will take. Communicating the expected timeline to the business owner at this stage sets appropriate expectations — a Tier 1 vendor onboarding typically takes two to four weeks; a Tier 3 vendor may be onboarded in days.
Steps 3–4: Security Due Diligence
Security Questionnaire or Certification Review
For Tier 1 and Tier 2 vendors, review the vendor's security posture before finalising the contract. The depth of review depends on the tier.
For Tier 1 vendors: request the vendor's most recent SOC 2 Type II report — not Type I. Type II covers operational effectiveness over a period of time (typically six to twelve months), providing evidence that controls were actually working, not just designed to work. Review the report for any qualified opinions or exceptions, particularly in the Access Control, Availability, and Confidentiality trust service categories relevant to your data. If the vendor cannot provide a SOC 2 Type II report, ISO 27001 certification is the international equivalent. If neither is available, require the vendor to complete a SIG Lite questionnaire. See the SIG Lite section for details on when and how to use it.
For Tier 2 vendors: a security questionnaire covering the vendor's key controls — MFA enforcement, data encryption at rest and in transit, patch management, incident response capability, and subprocessor chain — is the minimum standard. Document the due diligence results regardless of outcome. If the vendor passed review, document what was reviewed and when. If exceptions were found, document them and the risk acceptance decision or the remediation requirement before go-live.
Verify Security Certifications and Insurance
Confirm that the SOC 2 Type II report is within the last twelve months. Reports older than twelve months should trigger a request for an updated report or a bridge letter from the vendor's auditor confirming that no material changes to the control environment have occurred since the report date. Confirm that the ISO 27001 certificate is current and that its scope covers the specific services being provided to your organisation — a certificate that covers the vendor's data centre operations but excludes their SaaS platform is not evidence that the platform you're using is in scope.
Verify that cyber liability insurance is in place with coverage limits appropriate for the data access scope: typically $1–5M for Tier 2 vendors and $5–10M or more for Tier 1 vendors handling regulated data. Request the certificate of insurance directly — do not accept verbal confirmation. Verify that your organisation is listed as an additional insured where required by the contract.
Steps 5–6: Legal and Contract Documentation
Execute Required Contract Documents
The required contract documents depend on the vendor's risk tier and data access scope. No Tier 1 or Tier 2 vendor should begin work or receive system access until all applicable documents are signed. See the Required Vendor Contract Documents section for details on each document type.
At minimum, every vendor requires a signed service agreement or Master Service Agreement (MSA). Additional requirements apply based on the vendor's data access: if the vendor will process personal data of EU data subjects, a Data Processing Agreement is required under GDPR Article 28; if the vendor will create, receive, maintain, or transmit Protected Health Information on behalf of a HIPAA-covered entity, a Business Associate Agreement is required under the HIPAA Omnibus Rule; for all Tier 1 vendors, an NDA (if not already included in the MSA) and a security addendum specifying minimum security control requirements, breach notification SLA, and right-to-audit. For vendors with subprocessors who will handle your data, require the vendor to flow down contractual security requirements to their subprocessors and provide a current list of those subprocessors.
Confirm Contractual Security Requirements
Beyond the legal documents themselves, confirm that the contract includes the operational security provisions that define what the vendor must do — not just what they have agreed to. These provisions should specify: minimum security control requirements (MFA enforcement, encryption standards for data at rest and in transit, access logging), breach notification SLA (the vendor must notify you within a defined timeframe — 24 to 72 hours is the standard for Tier 1 vendors; GDPR requires notification within 72 hours, so vendor notification to you should be faster to allow time for regulatory reporting), data handling and retention requirements (how long the vendor retains your data, in what format, and how it is destroyed or returned at contract end), right to audit (your right to assess the vendor's security controls, either directly or through a third-party assessor), and subprocessor requirements (how the vendor manages its own subprocessors and how it notifies you of changes to that list).
Steps 7–8: Access Provisioning and Integration Setup
Provision Scoped, Least-Privilege Access
Grant the vendor the minimum access required for the defined engagement — not the maximum access they request. Access scoping principles for vendors: least privilege (access to exactly what the engagement requires, nothing more), time-limited access where possible (just-in-time access for one-time or project-based engagements), network segmentation (if the vendor requires on-premise access, place them in a dedicated VLAN isolated from internal systems they don't need to reach), and named accounts (no shared credentials — each vendor user must have their own named account for audit trail purposes). Shared credentials cannot be attributed to an individual, which means they cannot support access reviews, incident investigation, or compliance evidence.
Document the access grants: what systems, what level, what timeframe, and the business justification for each access grant. This documentation is required evidence for SOC 2 CC9.1, ISO 27001 A.5.19, and HIPAA access controls. Without it, the access grant cannot be demonstrated to have been authorised and scoped appropriately.
Verify Integration Security and Configure Monitoring
For vendors with API connections or data integrations, verify that all data in transit is encrypted using TLS 1.2 at minimum, that API authentication uses token-based or OAuth-based authentication (not basic auth with username and password over a persistent connection), that API access is logged and auditable, and that rate limiting and IP restriction are configured where applicable.
Configure monitoring for the vendor's access: alert on unusual access patterns (access outside expected hours, access from unexpected IP ranges, access to systems beyond the vendor's expected scope). Add the vendor's access to the identity governance review schedule — vendor access should be reviewed in every quarterly access review cycle, not only at the annual vendor review. Vendor access that drifts beyond its original scope between annual reviews is a common finding in post-incident investigations.
Steps 9–10: Compliance Verification and Go-Live
Confirm Compliance Requirements Are Met
Before the vendor begins accessing your systems or data, complete a pre-go-live compliance checklist: all required contract documents are signed and filed (MSA, DPA if applicable, BAA if applicable, NDA, security addendum), security due diligence review is complete and documented, access provisioning is complete and scoped per the least-privilege requirement, monitoring and alerting are configured, and the vendor has completed any required security awareness training or attestations specific to your environment.
For regulated environments, confirm that the vendor's go-live does not introduce a compliance gap. Adding a new data processor without a signed DPA is a GDPR violation from the first data processing action — the regulation does not provide a grace period for documentation to catch up with operations. Similarly, adding a new business associate without a signed BAA is a HIPAA violation from the moment the vendor first handles PHI. Both issues are entirely avoidable by making the compliance sign-off step a hard gate in the onboarding process.
Onboarding Sign-Off and Record Creation
Complete the vendor onboarding sign-off with: the date of go-live, the name of the vendor owner (the internal person responsible for managing the ongoing relationship and annual review), the next scheduled review date based on the tier (typically twelve months for Tier 1), and a complete record of all due diligence steps completed and documents executed. This record is the audit evidence for SOC 2 CC9.1, ISO 27001 A.5.19, and HIPAA's third-party access management requirements. Without it, the onboarding process cannot be demonstrated to have been completed — the access grant exists, but the control evidence does not.
Document Your Vendor Onboarding for SOC 2 and ISO 27001
CheckFlow's vendor onboarding checklist creates a timestamped, auditable record of every due diligence step, contract document, and access grant — the evidence your SOC 2 and ISO 27001 auditors will ask for.
Browse Compliance TemplatesRequired Vendor Contract Documents
The contract documents required for a new vendor depend on the vendor's risk tier and the nature of the data they will access. The table below maps each document to the conditions under which it is required and the primary regulatory or compliance driver.
| Document | When Required | Primary Regulatory Driver |
|---|---|---|
| Master Service Agreement (MSA) or Service Agreement | All vendors | Commercial / legal baseline |
| Non-Disclosure Agreement (NDA) | All Tier 1 and Tier 2 vendors (if not included in MSA) | IP and confidentiality protection |
| Data Processing Agreement (DPA) | Vendors processing personal data of EU/UK data subjects | GDPR Article 28 / UK GDPR |
| Business Associate Agreement (BAA) | Vendors creating, receiving, maintaining, or transmitting PHI | HIPAA Omnibus Rule |
| Security Addendum | All Tier 1 vendors; recommended for Tier 2 | SOC 2 CC9.1; ISO 27001 A.5.20 |
| Subprocessor Agreement / Flow-Down | Vendors who use subprocessors for your data | GDPR Article 28(4) |
| Insurance Certificate | All Tier 1 and Tier 2 vendors | Risk management |
The DPA and BAA are the most frequently missing documents in vendor management programmes. Organisations routinely onboard SaaS vendors who process EU personal data without a signed DPA, and healthcare IT vendors who handle PHI without a signed BAA. Both omissions are regulatory violations that can result in enforcement action even if no data breach occurs — the violation is the absence of the required contractual framework, not a downstream harm. The rule is simple: if the vendor processes personal data of EU data subjects, get the DPA before data flows begin. If the vendor handles PHI, get the BAA before the vendor touches any patient data.
The security addendum should specify as a minimum: MFA enforcement requirements, encryption standards for data at rest and in transit, breach notification timeline (24–72 hours recommended for Tier 1 vendors), data retention and deletion requirements, right-to-audit provision, and incident response cooperation obligations. Without a security addendum, the vendor's security obligations exist only in their own policies — which they control and can change — rather than in the contract.
The SIG Lite Questionnaire
The Standardized Information Gathering (SIG) questionnaire is a standardised vendor security assessment tool developed by the Shared Assessments organisation. The SIG Lite is the abbreviated version — covering approximately 130 questions across 18 security domains — designed for use with third-party vendors who cannot provide independent certification such as SOC 2 Type II or ISO 27001.
The SIG Lite is appropriate for Tier 1 vendors who do not have SOC 2 Type II or ISO 27001 certification, or as a supplement when reviewing certifications that are outdated or have a scope that does not cover the services being provided. It is not a substitute for independent certification. A vendor who passes a self-completed SIG questionnaire has not been independently verified — they have attested to their own controls. Use the SIG Lite as a risk assessment input, not as a certification equivalent. For Tier 1 vendors where the SIG Lite is the only available evidence, consider a right-to-audit clause in the contract that allows your organisation to verify the questionnaire responses.
The SIG domains most relevant for SaaS and technology vendors are: Information Assurance (IA), Asset and Information Management (A), Human Resources Security (H), Physical and Environmental (PE), IT Operations Management (IT), Access Control (AC), Application Security (AS), Cybersecurity Incident Management (IR), Privacy (P), Third-Party Management (TP), and Business Continuity and Disaster Recovery (BC). When reviewing completed questionnaires, look for three things: completeness (questions marked N/A without explanation should be investigated — a meaningful percentage of N/A responses in Access Control or Application Security for a SaaS vendor is a red flag), consistency (answers that conflict with other information you have about the vendor), and gaps in critical domains (a vendor with no documented access control programme or no incident response process represents a significant risk regardless of their scores in other areas).
Vendor Offboarding
Vendor offboarding is the mirror image of vendor onboarding — and it is executed significantly less consistently in most organisations. When a vendor relationship ends, all access granted at onboarding must be revoked. All data the vendor holds must be returned or destroyed per the contractual data handling requirements. All integration credentials (API keys, service accounts, OAuth tokens) must be rotated.
The most dangerous failure mode in vendor offboarding is not a deliberate oversight — it is the assumption that deactivating the vendor's named user accounts is sufficient. Named accounts in your identity provider are one access vector. API keys issued to the vendor for integrations are a second. Service accounts created for the vendor's on-premise access are a third. OAuth tokens authorised by a vendor user before their account was deactivated may remain active. Each of these vectors must be explicitly revoked, not assumed to expire. See the offboarding checklist guide for the parallel process applied to internal users.
A complete vendor offboarding checklist covers: revoke all system access (named accounts, API keys, OAuth tokens, network access credentials), confirm revocation with the vendor in writing, rotate any credentials the vendor had shared access to, retrieve or confirm destruction of any data the vendor holds per the contractual data handling requirements, obtain the vendor's data deletion certificate (required for GDPR DPA evidence and SOC 2 audit purposes), archive the vendor's contract and due diligence documentation for the applicable retention period (typically seven years for contracts; six years for HIPAA-related records), update the vendor registry to reflect the offboarded status, and remove the vendor from the quarterly access review schedule. For vendors with a defined contract end date, initiate offboarding 30 days before contract expiry — the goal is for access to be revoked simultaneously with contract expiry, not weeks after.
Ongoing Vendor Management
Vendor onboarding is a one-time process. Vendor management is a continuous programme. The table below defines the recurring tasks that should be scheduled for each vendor tier, ensuring that the due diligence performed at onboarding remains current and that vendor access is reviewed regularly.
| Frequency | Task | Applies To |
|---|---|---|
| Continuous | Monitor for vendor breach notifications; review vendor access logs for anomalies | All Tier 1 vendors |
| Quarterly | Vendor access review — confirm access scope still matches the business need | All Tier 1 vendors |
| Quarterly | Review subprocessor changes notified by Tier 1 vendors | Tier 1 vendors with DPA |
| Annually | Full vendor risk reassessment — renew or update risk tier classification | All Tier 1 vendors |
| Annually | Renew or confirm SOC 2 Type II / ISO 27001 certification currency | All Tier 1 vendors |
| Annually | Review and renew DPA / BAA as applicable | All Tier 1 vendors with DPA/BAA |
| Annually | Renew insurance certificate | All Tier 1 and Tier 2 vendors |
| At contract renewal | Full Tier 2 vendor review — questionnaire, contract refresh, access review | Tier 2 vendors |
| Event-triggered | Vendor security breach or incident — immediate access scope review | All tiers |
| Event-triggered | Vendor acquisition or ownership change — re-assess risk tier | Tier 1 and Tier 2 |
| Event-triggered | Significant change in data access scope — update due diligence | All tiers |
| At contract end | Vendor offboarding — access revocation, data deletion, documentation archival | All tiers |
Annual reviews should not be scheduled for the same calendar period for all vendors — stagger them across the year to distribute the workload across IT, security, and legal teams. Use a vendor management system or checklist platform that can automatically trigger review tasks based on the vendor's review date, contract end date, or event triggers. Manual tracking in spreadsheets fails at scale: reminders get missed, ownership is unclear, and there is no audit evidence that the review was completed when the next SOC 2 assessment arrives.
Build a Scalable Vendor Management Programme
Stop tracking vendor reviews in spreadsheets. CheckFlow schedules and assigns your annual reviews, quarterly access checks, and offboarding tasks — with the completion records needed to prove your vendor programme is running.
Start Free TrialCommon Vendor Onboarding Failures
Failure 1: No vendor registry — vendors are onboarded invisibly. Individual departments sign up for SaaS tools, engage service providers, and grant API access without any central IT or security visibility. The vendor onboarding checklist cannot be applied to a vendor that IT doesn't know about. The fix is a formal procurement request before any vendor is granted access to systems or data — not to block legitimate engagements, but to ensure every vendor relationship enters the risk management pipeline from day one.
Failure 2: Risk tier assignment is skipped. All vendors receive the same level of due diligence — either all receive maximum scrutiny (operationally unsustainable) or all receive minimum scrutiny (a security risk). The fix is to classify every vendor into a risk tier at the start of the onboarding process and apply due diligence proportional to that tier. Maximum scrutiny for Tier 1, standard process for Tier 2, minimal process for Tier 3.
Failure 3: DPA or BAA is not executed before data flows begin. The vendor is provisioned and begins receiving data before the legal team has reviewed and signed the required DPA or BAA. The organisation is in regulatory violation from the first data processing action. The fix is to make the compliance sign-off step a hard gate in the onboarding checklist — the vendor cannot access systems or data until all required documents are signed and filed.
Failure 4: Access is not scoped — the vendor receives broad access "to be safe". The vendor is granted admin-level access or access to systems beyond the scope of the engagement because it is easier than having a conversation about the minimum access required. The fix is to define the minimum access required for the engagement before provisioning begins. Any request for broader access requires a business justification and security review, not a default approval.
Failure 5: API keys and shared credentials are not rotated at offboarding. The vendor relationship ends. Named accounts are deactivated. The API key the vendor used for their integration — which was never rotated — remains active. Six months later, the former vendor uses that API key to access data. The fix is to include API key rotation and credential rotation explicitly in the vendor offboarding checklist, treated as separate action items from IdP account deactivation.
Failure 6: No event-triggered review process. A Tier 1 vendor announces a significant data breach. The organisation finds out from the news. There is no defined process for assessing the impact or reviewing the vendor's access scope. The fix is a defined vendor incident response process: subscribe to vendor security communication channels, and maintain a checklist that triggers when a breach notification is received — covering access scope review, containment steps, and post-incident documentation.
Failure 7: SOC 2 reports are accepted at face value without review. The vendor provides a SOC 2 Type II report and the procurement team marks the security review complete without reading it. The report contains qualified opinions in the Access Control criteria. The fix is to assign a security reviewer to read every SOC 2 report, specifically looking for the type of opinion (qualified vs. unqualified), the trust service criteria covered, and any exception descriptions or complementary user entity controls that place obligations on your organisation.
Failure 8: Vendor reviews are scheduled but not completed. The annual review task is created in a spreadsheet or task tracker. It is never completed because no one owns it and there is no consequence for missing it. The fix is that every vendor must have a named internal owner — the person responsible for the relationship — who owns the annual review and is accountable for its completion. Build the review into the vendor owner's objectives, not just into a task list no one checks.
Frequently Asked Questions
A complete vendor onboarding checklist covers: risk classification (assigning the vendor to a risk tier based on the data they access, systems they connect to, and regulatory context), security due diligence (reviewing the vendor's security controls via questionnaire, reviewing available certifications such as SOC 2 Type II or ISO 27001, penetration test reports if applicable), legal and contractual documentation (vendor agreement, DPA for GDPR, BAA for HIPAA, NDA, and data handling addenda as required), access provisioning (scoping and granting system access using least-privilege principles, VLAN segmentation for on-premise vendors, just-in-time access where applicable), integration and technical setup (confirming security requirements for any API connections or data flows), compliance verification (confirming the vendor meets applicable compliance requirements before go-live), and ongoing monitoring triggers (setting annual review dates, event-based review triggers, and offboarding procedures at contract end).
A vendor risk tier matrix classifies vendors into risk categories based on the sensitivity of data they access, the criticality of systems they connect to, and their regulatory context. A standard three-tier model: Tier 1 (High Risk) — vendors with access to sensitive data (PII, PHI, financial data, intellectual property) or with privileged system access, requiring full security due diligence, signed DPA/BAA as applicable, SOC 2 or equivalent evidence, and annual reviews. Tier 2 (Medium Risk) — vendors with access to internal data or systems, but not sensitive regulated data, requiring standard security questionnaire, contractual security requirements, and annual reviews. Tier 3 (Low Risk) — vendors with no access to internal systems or data (e.g., office supplies, physical facilities services), requiring standard contractual terms and minimal due diligence. The tier matrix determines how much due diligence is required before onboarding and how frequently the vendor is reviewed. Not all vendors require the same level of scrutiny — applying maximum due diligence uniformly is operationally unsustainable.
A Data Processing Agreement (DPA) is a legally binding contract between a data controller (the organisation that determines the purpose of data processing) and a data processor (a vendor that processes personal data on the controller's behalf). Under GDPR Article 28, a DPA is mandatory whenever a controller uses a processor that will process the personal data of EU data subjects. The DPA must specify: the subject matter and duration of processing, the nature and purpose of processing, the type of personal data and categories of data subjects, the obligations and rights of the controller, and security and breach notification requirements.
Cloud service providers, SaaS platforms, analytics tools, and any software that processes employee or customer personal data on your behalf typically require a DPA. Failure to have a DPA in place is a GDPR violation — the supervisory authority does not need to prove data misuse to issue a penalty.
The minimum security certification to require from vendors who access sensitive data is a SOC 2 Type II report — not Type I. Type II covers a period of time (typically 6–12 months) and provides evidence that the vendor's controls were operating effectively throughout that period, not just at a point in time. For healthcare data, require a SOC 2 Type II and evaluate whether the vendor has a HITRUST r2 Certification, which specifically maps to HIPAA Security Rule requirements. For vendors operating in highly regulated environments, ISO 27001 certification is the international standard equivalent to SOC 2.
For vendors who cannot provide any independent certification, require them to complete a SIG Lite questionnaire and consider a right-to-audit clause in the contract. Never accept a vendor's self-assessment as a substitute for independent certification or a completed SIG questionnaire for Tier 1 vendors.
Vendor risk assessments should be reviewed on two triggers: scheduled (annual review for all Tier 1 vendors; bi-annual for Tier 2; once at onboarding and at contract renewal for Tier 3) and event-driven (the vendor experiences a security breach, the vendor changes ownership or is acquired, the vendor significantly expands or changes the scope of their access to your systems or data, a new regulation becomes applicable to their data processing activities, or a change in your own regulatory status affects the requirements for vendor management).
Event-driven reviews should be triggered automatically when the relevant event is detected — a breach notification from a Tier 1 vendor should immediately trigger a review of their access scope and incident response actions, not wait for the next scheduled annual review.