Vendor Security Due Diligence: A Practical Guide

Vendor security due diligence is the research you do before a third party touches your data, systems or clients. You verify who the vendor is, how it protects information, and what happens when something goes wrong. Then you decide whether to sign, sign with conditions, or walk away. Do it the same way for every supplier, scale the depth to how critical the vendor is, and repeat it after the contract is signed.

This guide is for managing partners, IT directors and compliance leads at law firms, energy companies and other regulated mid-sized businesses. It covers what to check, in what order, which evidence to request, and where reviews usually break down.

TL;DR

• Start with a consistent, desktop-based baseline for every vendor, then go deeper only where the vendor is critical or handles sensitive data.
• Check five things: ownership and control, provenance, resilience, supply chain tiers and foundational cyber practices.
• Ask for evidence, not assurances: SOC 2 reports, policies, incident response plans, and written answers on data location and subcontractors.
• Put security requirements into the contract with enforceable consequences, then reassess on a schedule.
• Treat vendor review as a lifecycle, not a one-time approval.

Table of Contents

• Why vendor security reviews matter more than they used to
• What vendor due diligence actually includes
• Step 1: Inventory and tier your vendors
• Step 2: Run the desktop baseline
• Step 3: Ask for evidence on the security fundamentals
• Step 4: Look past the vendor to its vendors
• Step 5: Write security into the contract
• Step 6: Score, decide and document
• Step 7: Keep reviewing after you sign
• Common mistakes in vendor security due diligence
• Our perspective: what we see in regulated organizations
• When to bring in outside help
• FAQ
• Sources

Why vendor security reviews matter more than they used to

Your security perimeter now includes every vendor that stores, processes or can reach your data. The American Bar Association's Cybersecurity Legal Task Force notes that many security breaches stem from third-party vendor vulnerabilities. It also stresses that due diligence is not a one-and-done task.

Law firms feel this sharply. A 2024 legal operations survey cited by the ABA found that 54% of law firm respondents see security concerns as a significant barrier to adopting new legal technology. Budgets worried 40%. Both numbers point the same way: firms want the tools, but they lack a repeatable way to judge the risk.

Oil and gas and energy operators face a different version of the same problem. Operational technology suppliers, field software vendors, managed service providers and cloud hosts all sit between you and your regulators, your insurers and your customers. A weak link in that chain becomes your incident.

What vendor due diligence actually includes

Terms get blurred, so here is a working distinction. Due diligence is the front-end investigation. A full vendor security assessment goes deeper and is reserved for suppliers that warrant it.

NIST's Due Diligence Assessment Quick-Start Guide (SP 1326, July 2026) defines due diligence research as the investigative process of researching all available, pertinent information about a supplier or product so informed decisions can be made. The guide itself organizes the work into five components:

1. Foreign Ownership, Control, or Influence (FOCI): who owns the vendor and who can direct its decisions.
2. Provenance: where the product, code or service comes from.
3. Resilience: whether the vendor can keep operating through disruption.
4. Supply chain tiers: who the vendor depends on in turn.
5. Foundational cyber practices: the basic security controls the vendor runs.

NIST positions this as the minimum level of reasonable investigative rigor for ICT suppliers. It is often desktop research, applied to most suppliers regardless of criticality, before any deeper review.

That last point matters for mid-sized organizations. You cannot audit every vendor exhaustively, and you should not try. You need a defensible process that is the same every time.

Step 1: Inventory and tier your vendors

You cannot review what you have not listed. Build a vendor inventory from accounts payable, IT admin consoles, single sign-on logs and department heads. Expect surprises: shadow IT tools adopted by one practice group or one field office are common.

Then tier each vendor by what happens if it fails or is breached. A simple three-tier model works:

NIST makes the same point: set the depth of your diligence according to your resources and the criticality of the acquisition. The goal is to reach good decisions quickly without drowning in data.

Step 2: Run the desktop baseline

Before you send a single questionnaire, spend an hour on public research. For each vendor, record:

• Legal entity name, headquarters, ownership and any parent company.
• Years in business, financial stability signals and any acquisitions underway.
• Public breach history, regulatory actions and litigation.
• Published security certifications and the date of the latest report.
• Where the service is hosted and which cloud providers it uses.
• A security or trust page, and a named contact for security issues.

A vendor with no trust page, no named security contact and no certifications is telling you something. It does not have to be disqualifying for a low-tier vendor. It should be disqualifying for one that will hold client files.

Step 3: Ask for evidence on the security fundamentals

For important and critical vendors, move from research to requests. CISA's vendor question guidance, written for state and local officials but useful anywhere, points to the areas a thorough review covers: cybersecurity governance such as dedicated security staff, compliance with frameworks like SOC 2 and ISO 27001, data handling and encryption, and documented incident response and business continuity plans. It also recommends asking where data is housed and routed, and how the vendor identifies its own third-party risks.

Turn that into a request list:

Governance

• Who is accountable for security at the vendor? Is it a dedicated role or a side duty?
• Is there a written information security policy, approved by leadership and reviewed on a schedule?

Assurance

• Current SOC 2 Type II report or ISO 27001 certificate. Read the scope, the audit period and any exceptions, not just the cover letter.
• Results of the most recent independent penetration test, or a summary letter with remediation status.

Data protection

• How is data encrypted in transit and at rest, and who holds the keys?
• Where is data stored and processed, and where are the people with access located?
• How is your data separated from other customers' data?
• What happens to your data when the contract ends?

Access control

• Is multifactor authentication enforced for employees and administrators?
• How quickly is access removed when someone leaves?

Incident response and continuity

• A documented incident response plan, with a commitment on how fast you will be notified.
• Backup, recovery and continuity plans, with recovery time objectives and the date of the last test.

Ownership and workforce

• Ownership structure, board makeup, and any foreign ownership or control. CISA's guidance lists foreign ownership and the physical location of the workforce and data among the questions to raise.

How to read the answers

Questionnaires reward vendors who are good at questionnaires. Weight documents over statements. A policy that exists and is dated beats a "yes" in a spreadsheet cell. Look for specifics: named tools, named timelines, named owners. Vague answers, and answers that change between calls, are findings in their own right.

If your vendor holds a framework report, check that the scope covers the actual service you are buying. A SOC 2 report for a vendor's corporate office does not tell you much about the product that will host your matter files.

Step 4: Look past the vendor to its vendors

A frequent blind spot is fourth-party risk: the security of the suppliers your vendors rely on. CISA's ICT SCRM Essentials guidance suggests probing how a supplier manages its own supply chain, including whether it assesses its subcontractors and passes security requirements down in its own contracts.

Ask three direct questions:

1. Which subprocessors will handle our data, and in which locations?
2. How do you assess them before and after onboarding?
3. Will you notify us before adding or replacing a subprocessor that touches our data?

NIST's fourth component, supply chain tiers, covers the same ground. You do not need to audit the vendor's vendors yourself. You need to know that your vendor does, and that the obligation is written down.

Step 5: Write security into the contract

Diligence that never reaches the contract is just reading. CISA suggests leadership treat security as a procurement metric on par with cost, schedule and performance. The same CISA publication notes that organizations often fail by not setting specific, enforceable security requirements in service-level agreements, such as penalties for missing defined security metrics.

A working contract checklist:

• Minimum security controls named in an exhibit, not just referenced as "industry standard."
• Breach notification deadline and the information the vendor must provide.
• Right to receive updated assurance reports each year.
• Subprocessor notification and flow-down obligations.
• Data return and deletion terms at exit, with written confirmation.
• Defined remedies when security metrics are missed.

For attorneys, the ABA Cybersecurity Legal Task Force's Vendor Contracting Project checklist is aimed at solo and small firm lawyers and frames the contractual issues in plain terms. Have your own counsel or ethics advisor confirm what your state bar expects when client confidences are involved.

Step 6: Score, decide and document

A decision needs a record. Use a consistent scorecard so two reviewers looking at the same vendor reach similar conclusions. If you are buying software, this walkthrough on using a scorecard to evaluate software vendors before signing shows one way to weight criteria across a procurement.

Whatever method you use, record:

• The vendor's tier and why.
• What evidence you reviewed and its date.
• Open risks and who accepted them.
• Conditions attached to approval, such as remediation deadlines.
• The date of the next review.

Three outcomes are normal: approve, approve with conditions, or decline. A "conditional approval" with no owner and no deadline is how risk becomes permanent.

Step 7: Keep reviewing after you sign

The ABA describes cybersecurity due diligence as a constant arena of change rather than a one-time project. Firms that do this well build it into a lifecycle: procurement, contract negotiation, then periodic reassessment after the contract starts.

A practical rhythm:

These intervals are our recommendation, not a regulatory standard. Adjust them to your risk appetite and any rules that apply to you.

Common mistakes in vendor security due diligence

• Treating approval as permanent. A clean report from two years ago says little about today.
• Reviewing everything equally. Exhaustive audits for every vendor burn your team out. Tiering fixes this.
• Accepting a certificate without reading the scope. The logo is not the evidence.
• Ignoring subcontractors. Fourth-party exposure rarely appears in a standard questionnaire.
• No exit plan. If you cannot retrieve and delete your data, the vendor holds leverage.
• No owner. If nobody is accountable for the vendor register, it decays within a year.

Our perspective: what we see in regulated organizations

We work with law firms, oil and gas companies, energy operators and other compliance-sensitive mid-market organizations. The pattern is consistent. Vendor review is rarely skipped on purpose. It is skipped because nobody owns it, the intake process is inconsistent, and the questionnaire arrives after the contract is already negotiated.

Our advice is to fix the process before you buy more tools. Pick one intake path, one tiering model, one scorecard, and one person accountable. A modest process applied to every vendor beats a heroic review of one.

We also advise leaders to map vendor evidence to the frameworks they already answer to. If you are working toward SOC 2, HIPAA, PCI DSS or CMMC, your vendors' controls are part of your own audit story. Collecting their evidence once, in a structure auditors recognize, saves repeated work later.

Finally, ask the board-level question: which five vendors could cause us the most harm if breached, and what do we know about each? If the answer takes more than a day to assemble, that is your first project.

— vCISO

When to bring in outside help

If your firm has no dedicated security leader, vendor reviews often fall to an IT generalist or an office manager. That works for low-tier vendors. It struggles when you must interpret a SOC 2 exception, negotiate security terms or judge a critical supplier's incident response plan.

CISOSafe provides virtual CISO services, security risk assessments, compliance program management and audit and certification readiness for regulated organizations, along with a platform that supports compliance assessments across 50+ frameworks. A vCISO can design your vendor tiering model, run the deeper reviews on critical suppliers and report the results to leadership in plain terms. See the services we offer or start at cisosafe.com.

FAQ

What is included in vendor security due diligence?

It covers the vendor's ownership, provenance, resilience, supply chain dependencies and foundational cyber practices, per NIST's five components. In practice that means public research, assurance reports such as SOC 2 or ISO 27001, data handling and encryption answers, and incident response and continuity plans. Depth depends on how critical the vendor is.

What is the difference between due diligence and a vendor security assessment?

Due diligence is the baseline investigation you apply to most suppliers before a purchase, often from public information. A vendor security assessment is deeper and evidence-based, usually reserved for vendors that handle sensitive data or support critical operations. Many organizations run the first for every vendor and the second only for higher tiers.

How often should we reassess a vendor?

There is no single required interval. A common approach is annually for critical vendors, every one to two years for important ones, and at renewal for low-risk vendors, with early reviews after a breach, acquisition or major scope change. Check any contractual or regulatory obligations that set your schedule.

Do small firms need a formal process?

Yes, but a proportionate one. NIST's guidance recommends a consistent, defensible process starting with basic desktop research, scaled to your resources. A one-page tiering rule, a standard request list and a shared vendor register is enough to start.

Who should own vendor security due diligence?

One named person should be accountable, whether that is a CISO, a vCISO, an IT director or a managing partner's delegate. Procurement, legal and IT all contribute, but without one owner the register and the reassessments tend to lapse.

Sources

• NIST SP 1326: Due Diligence Assessment Quick-Start Guide (PDF)
• NIST publication page for the Quick-Start Guide
• ABA Cybersecurity Legal Task Force
• ABA Law Technology Today: How to Secure Your 2025 Legal Tech
• CISA: Questions to Ask Vendors
• CISA: ICT SCRM Essentials
• ABA Vendor Contracting Project: Cybersecurity Checklist