Third-party risk and cyber due diligence
Two questions look unrelated and are answered with the same method: who are we depending on, and what are we about to buy? Both come down to reading what somebody else can tell you about their own security, and knowing which parts of it are load-bearing.
The short version: the same method, two clocks
Third-party risk work runs continuously and is judged on proportion — the effort spent on a vendor should match what that vendor can reach. Deal diligence runs against a fixed date and is judged on what it surfaces before signing. The reading skill is identical; the output and the tempo are not.
Both are documentary and interview-based. Nothing is scanned and nothing is tested on a third party’s systems.
Vendor tiering: proportionate effort, by reach
Tiering is what keeps a programme alive. Without it, every vendor gets the same long questionnaire, the process becomes universally resented, and within a year it is performed for the largest contracts and skipped for everything else — including the small tool with an administrative token into your production environment.
Tiers are set by what the vendor can reach rather than by what they charge: the data they hold or can see, the access they have into your systems, whether your service stops if theirs does, and whether they can act on your customers in your name. A payroll platform and a design agency are not in the same tier, and neither is a free browser extension with a token.
Where the vendor is delivering or embedding a model, the questions change shape; that is covered on AI use discovery and vendor risk.
Question sets, and how to read the answers
Three question sets rather than one — a short set for the lowest tier, a working set for the middle, and a full set for vendors who hold regulated data or reach production — each mapped to the tier that triggers it and each short enough to be answered honestly.
Reading them is the skill. A confident “yes” to everything is a finding. An answer that describes an intention in the present tense is a finding. The useful follow-up is almost always the same question: what evidence exists, and who produced it? The gap between a policy that asserts a control and an artifact that demonstrates it is the whole game.
Reading a vendor’s SOC 2 report or ISO certificate
These are the two documents vendors offer instead of answering questions, and both are worth reading properly rather than filing.
A SOC 2 report is a report a CPA firm issued about a service organization. Reading somebody else’s report is normal and permitted; this practice never issues one. What matters in it is the scope — which system, which trust services criteria, which period — whether it is a Type 1 or a Type 2, the exceptions the report records, the complementary user entity controls it assigns to you, and the subservice organizations it carves out. A report covering a product you do not use tells you nothing about the one you do.
An ISO/IEC 27001 certificate is issued by an accredited certification body to a defined scope of an information security management system. The scope statement on the certificate is the document: a certificate whose scope names one office or one product line does not cover the rest. Which of the two a vendor holds, and what each actually demonstrates, is compared in SOC 2 versus ISO 27001.
Contractual security positions for your counsel
No. We recommend the security positions a contract should carry and the evidence each one should require; drafting the contract and advising on it is your counsel’s work. The output is a recommended position per topic, with the reasoning, so your counsel can draft language that fits your contract and your jurisdiction.
The topics that usually earn their place: a notification obligation with a defined clock and a defined trigger; a right to receive assurance evidence on a stated cadence; restrictions on subprocessors and on where data may be stored or accessed from; secure return or deletion on termination, with confirmation; minimum control commitments tied to the tier; and cooperation obligations if something goes wrong on their side. Nothing here is legal advice.
Cadence, and an initial register you can actually use
A programme with no review cadence degrades into a folder of documents from the year each vendor was onboarded. The design sets a review interval per tier, the events that trigger an off-cycle review — a breach at the vendor, a change of ownership, a material change in what they hold — and who owns the conversation. How that standing programme is set up and handed to your own staff is described on vendor risk management programme.
The engagement ends with a populated register rather than an empty template: your actual vendors, tiered, with what each can reach, the assurance held, the gaps, and the next review date. Running it afterwards sits naturally with vCISO and security programme work, and the evidence it produces feeds compliance and privacy readiness.
Cyber due diligence in an acquisition
Deal diligence is a different product with the same method and a much harder clock. It covers the target’s posture as described in documents and in interviews with the people who run the systems; the history of known incidents and what was done about them; regulatory and contractual exposure the target carries; the state of its own supplier dependencies; and the integration risk — what connecting their environment to yours would import on day one.
The deliverable is a red-flag memo sized to the timeline: what would change the price, what would change the terms, what must be fixed before the environments are joined, and what can be absorbed into the first hundred days. Alongside it sits an integration risk register that survives the deal and becomes the acquiring organization’s plan.
What diligence does not include
Scanning or testing the target’s live estate. It is not in scope, and a vendor offering it inside a diligence engagement is offering something that needs the target’s own written authorization to be lawful at all.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
How deep should we go on a low-risk vendor?
Proportionately. A vendor that cannot reach your data, your customers or your production environment warrants a short standard question set and a record of the answer, not a full assessment. The purpose of the low tier is to make the high tier survivable: if everything is treated as critical, nothing is.
Can you assess a vendor on our behalf?
Yes. Vendor assessment on your behalf is documentary and interview-based: the vendor supplies evidence, answers questions, and is scored against criteria you have agreed in advance. Where a vendor declines to provide evidence, that response is itself the result, and it is written up as such rather than left as a blank row.
Can you scan the target company?
No. Scanning or testing a target company’s live estate is outside the scope of diligence work here, and without that company’s own written authorization it would not be lawful in any case. What is available without touching their systems — what they publish, what they have told the market, what their own documents claim — is read carefully, and the memo is explicit about the limits of that.
Do you draft the contract clauses?
The practical split is that this practice says what the contract should protect and what evidence to demand; your counsel says how to write it and whether it holds.
Find out what you depend on
Describe the supplier landscape, or the target and the deal timeline. The reply says what the work would cover and what you would receive — see also all security services.