The standard third-party risk programme sends every vendor the same assessment. A payroll provider holding every employee record and a design tool used by two marketers receive an identical 300-question spreadsheet.
The consequence is predictable. The questionnaire takes two weeks to complete, so vendors delegate it to a sales engineer who answers optimistically. The reviewing team, faced with 300 answers per vendor across 400 vendors, cannot read them properly. Procurement learns that the process adds three weeks and starts routing around it.
Nobody is protected. Everyone is inconvenienced.
Tier by reach, not by spend#
The most common tiering mistake is using contract value. Spend correlates weakly with risk — a ₹40 lakh SaaS contract can hold your entire customer database while a ₹4 crore facilities contract holds nothing.
Tier on four dimensions of reach:
| Dimension | Question |
|---|---|
| Data | What categories of data does the vendor hold, and at what volume? |
| Access | What systems can the vendor reach, and through what mechanism? |
| Privilege | What level of authority does that access carry? |
| Criticality | How quickly would their failure stop your business? |
Score each and take the maximum rather than the average. A vendor with no data but standing administrative access to production is tier one regardless of how the other three score.
Vary the depth genuinely#
Tiering is only useful if the assessment actually differs. The structure we deploy:
Tier 4 — screening (8 questions). Does the vendor hold any personal data? Any system access? Are they in a sanctioned jurisdiction? Confirm and file. Five minutes.
Tier 3 — light (22 questions). Basic security hygiene, sub-processor disclosure, breach notification commitment, data location. No evidence requested. Thirty minutes to review.
Tier 2 — standard (64 questions). Full security questionnaire, certification evidence accepted in lieu of detailed answers, data processing agreement executed, named security contact. Two hours to review.
Tier 1 — deep (142 questions plus evidence). Everything in tier 2, plus: independent audit report reviewed in detail rather than filed, penetration test summary, architecture review, sub-processor chain mapped, business continuity plan and test results, right-to-audit exercised on a sample basis, exit plan documented and tested. One to three days per vendor.
The total effort is lower than uniform assessment and the effort that remains is concentrated where it changes an outcome. One client reallocated 62% of assessment effort from tiers 3 and 4 into tier 1 without increasing headcount.
Read the SOC 2 report properly#
For tier 2 and tier 1 vendors, an independent audit report is usually the highest-value artefact — and it is usually filed unread.
Five checks, twenty minutes:
- Scope. Does the system description cover the service you are buying? Vendors with several products frequently have a report covering one of them.
- Period. Type II reports cover a defined observation period. A report ending fourteen months ago tells you about a control environment that may no longer exist. Ask for a bridge letter.
- Opinion. Is it unqualified? A qualified opinion is not automatically disqualifying but it is a conversation.
- Exceptions. Section 4 lists tested controls and exceptions. Read the exceptions and ask whether any relate to a control you are relying on. An access-review exception matters more to you than a physical-security one if you are buying SaaS.
- Complementary user entity controls. The report will list controls you must operate for the vendor's controls to be effective. Almost nobody reads these, and they are effectively a contract term.
Training procurement teams to run these five checks takes an afternoon and produces more risk reduction than adding fifty questions to the questionnaire.
The AI vendor questions nobody asks#
Traditional security assessments do not ask the questions that matter for AI-enabled vendors. The gaps we see repeatedly:
AI vendor due diligence essentials
- 1Is our data used to train, fine-tune or evaluate your models? If yes, under what basis and can we opt out contractually?
- 2What is the retention period for prompts, inputs and outputs, and is it separately configurable from account data?
- 3Which sub-processors receive prompt content, and where are they located?
- 4What evaluation evidence exists for accuracy, robustness and fairness, and will you share it under NDA?
- 5What notice do we receive before a model version changes, and can we pin a version?
- 6What human review exists over outputs in your own operations, and what is the reviewer capacity per hour?
- 7On termination, what happens to prompt history, embeddings and any derived artefacts?
- 8Under the EU AI Act, are you the provider for this system, and will you supply the technical documentation a deployer requires?
The version-pinning question is the one that surprises people. A vendor silently swapping the underlying foundation model can change your output distribution overnight, which for a regulated decision process is a control failure with no change record.
Concentration and exit#
The final component, and the most often absent: which vendors would be genuinely painful to leave?
For each tier-one vendor, document:
- The realistic substitution options, named.
- The migration effort, estimated in weeks and cost.
- The data extraction mechanism, and whether it has ever been tested.
- What happens to your operations during the transition.
Then test the extraction. Not the migration — just the export. Organisations routinely discover that a vendor's data export produces a format nobody can ingest, or excludes the historical records that matter, or takes six weeks to deliver.
A vendor you cannot leave is a vendor with pricing power and no incentive to improve. That is a commercial risk as much as a security one, which is often the framing that gets it funded.
Move the gate earlier#
None of the above matters if procurement closes contracts before assessment begins. The single structural fix that improves every third-party risk programme is a gate in the procurement workflow that cannot be bypassed — tier determination before contract signature, with tier one requiring completed assessment.
That is an organisational change, not a security control, and it usually needs a CFO rather than a CISO to land.
Monitor the four signals that actually move#
Continuous monitoring products generate enormous volumes of findings, most of which tell you nothing about whether a vendor is becoming more dangerous. Four signals are worth an alert.
Certification lapse. A vendor whose ISO certificate or SOC 2 period has expired without renewal has changed materially, and it is a leading indicator — programmes lapse before incidents happen. Track expiry dates for every tier one and tier two vendor and alert 90 days out.
Breach disclosure. Not the vendor's own announcement, which is late by definition. Regulatory filings, sector CERT advisories and credible reporting. The question on disclosure is never "are they breached" but "what of ours could they reach", which the tiering record already answers.
Financial distress. Funding trouble, layoffs affecting engineering or security, acquisition, auditor change. A vendor cutting costs cuts security first because it is the least visible reduction. This is the signal most security teams do not watch and procurement already has.
Sub-processor change. A new sub-processor in the chain is a new party touching your data. This is only visible if your contract requires notification, which is why the clause matters.
External attack-surface scanning is worth having but rank it fifth. An expiring TLS certificate on a marketing subdomain is not a reason to page anyone, and treating it as one is how teams learn to ignore the feed.
Test the exit before you need it#
The exit plan is the part of every third-party programme that gets documented and never validated.
For each tier one vendor, run the extraction — not the migration, just the export. Request the data, in the format the contract specifies, and see what arrives.
What organisations discover, reliably:
- The export excludes historical records, or metadata, or the audit trail — the parts that make the data usable.
- The format is technically compliant and practically unusable: a proprietary archive, or a CSV with no schema.
- The stated turnaround is measured in weeks, not the days assumed in the continuity plan.
- Nobody at the vendor has performed the export before, and it takes them three attempts.
Better to learn that during a planned test than during a termination dispute. And the test itself changes the commercial relationship in your favour — a vendor who knows you have validated your exit negotiates differently at renewal.
One further note on concentration. A vendor you cannot leave is not merely a resilience risk; it is a pricing risk and a roadmap risk. Where the exit test shows substitution is impractical, that finding belongs in front of the CFO as much as the CISO.
Our Third Party & Supply Chain Risk practice builds these programmes, and the full tiering model with all four question sets and the AI module is published as our Vendor Risk Assessment Kit.
Enterprise & Third-Party Risk
Our risk practice specialises in quantified risk analysis, third-party risk management and operational resilience, with a FAIR-aligned methodology developed across banking, insurance and manufacturing engagements.
- FAIR Analyst
- CRISC
- CISA
Where do you actually stand?
Score your Digital Trust posture in fifteen minutes
Free, no sales call required. Privacy, security, governance, risk and AI readiness scored against sector benchmarks, with a prioritised gap list.

