Defence Lab
what we protect
PeopleCode & deliveryInfrastructure & cloudDevicesOfficesGovernance & compliance
services
DevShieldSOCvCISOPenetration testingISO 27001 & SOC 2 readinessCompliance readinessSecurity health checkSecurity posture assessmentDevSecOpsThird-party riskDORA readinessCRA readinessAll 18 services
products
PhishAttackSec AwarenessPhish GuardManaged Security Gate vendors blog about us book a consultation

Third-party risk

Know what a vendor brings with it before you depend on it

We assess the vendors and software your business runs on: who stands behind a tool, where your data goes, what its terms leave you with, what it can reach inside your systems, and what is inside the code you build on. Then we tell you what to keep, limit or replace.

  • Vendors
  • Vendor access
  • Libraries in your code

Five ways the vendor question arrives

A vendor was breached, and nobody knew how far it reached

Your IT provider or a supplier with remote access was attacked, and for days nobody could say whether the attackers came through to you.

A team found a cheaper tool

Someone wants to bring in a new service, it costs less than the current one, and nobody has looked at who is behind it.

A regulator or auditor asked for your supplier list

NIS2 or DORA applies to you, and the list of vendors, what they do for you and what each one puts at risk has to exist.

A customer asked what your product is built from

Their security review wants the list of components and versions in your software, and nobody keeps one.

An open-source component was compromised

The alert came out, and the team spent days searching repositories by hand to find out whether you were affected.

Book a consultationSound like you? Start with a short call.

A vendor is judged by what happens to you if it fails

A security questionnaire tells you what the vendor says about itself. We look at two more things: what its situation means for your business, and how far it can reach into your systems.

A questionnaire-based reviewHow we assess a vendor
The question

Does the vendor say it has the right controls?

What happens to you if this vendor is breached, changes its terms or closes?

The vendor's side

Its answers and certificates

Who built the product and where the company is registered, where your data is stored, what its terms say about liability, whether it is in legal disputes

Your side

Rarely looked at

The conditions for using the tool safely: where it runs, what is switched off, who has access. For vendors already connected to you: remote support tools, integration accounts and shared logins, and where an attacker could go from each

What you get

A risk score

A rating by category, each finding quoted from the vendor's own terms or privacy notice, and a verdict: approved, approved with conditions, or replace, with an owner for each condition

The vendor's side comes from its own documents and the public record. Access already inside your environment is checked with your permission.

The services you buy, and the code you build on

Vendors and service providers

The risk
A vendor is breached, misuses your data or disappears, and its access becomes the attacker's
What we need
The vendor list you have, and access to see how vendors connect to you
What you get
An assessment per vendor, and a map of vendor access into your systems
When it is redone
When a vendor is breached or changes its service

Libraries in your code

The risk
A component someone else wrote carries a vulnerability or a compromised update into your product
What we need
Read access to your repositories and build pipeline
What you get
A software bill of materials (SBOM) for each product, including the dependencies nobody chose on purpose
When it is redone
Automatically in every build, once it is set up

You can start with either level, or take both.

What NIS2, DORA and your customers ask about vendors

SourceApplies toWhat it asks
NIS2Essential and important entities in the sectors it coversSecurity in the relationships with direct suppliers and service providers, taking each supplier's weaknesses into account
DORAFinancial entities, since 17 January 2025A register of all contracts for ICT services from third-party providers
Your customers' contractsSuppliers to companies under those rulesQuestionnaires, clauses and evidence passed down the chain, increasingly including an SBOM

Being a supplier to a company under NIS2 does not bring you into scope by itself. The requirements reach you through your customer's contract.

From a list of names to a decision about each vendor

  1. Scope

    The vendors in question, what each does for your business, and which repositories and products are included.

  2. Mapping

    Every vendor with access into your systems, and where an attacker could move from each one.

  3. Assessment

    Each vendor checked through its public record, terms and data location; the riskiest ones assessed in depth.

  4. Recommendation

    A ranked list of what to keep, limit or replace, with an owner and a deadline for each item.

  5. Fixing and watching

    Vendor access routed through one controlled entry point if you want it, contracts updated, assessments redone after a vendor incident.

A list of vendors assessed once, or kept under watch

One-time assessment

Suits
A company after a vendor incident, choosing a tool, or preparing for an audit
Covers
An agreed list of vendors, an access map, SBOMs built once, or any of these
Ends with
A ranked list of risks with owners and deadlines

Managed, over a year

Suits
A company with many vendors or frequent releases, or one under NIS2 or DORA
Covers
Everything in the one-time assessment, plus new vendors as they come in, reassessment after a vendor incident, and SBOMs kept current
Ends with
A record that stays current through the year

Price follows the number of vendors. A package covers an agreed number, and each vendor beyond it is added separately.

Checking how a vendor's API is connected to your product is a narrower piece of work, closer to a penetration test of that integration, and is scoped on its own.

Two engagements, and what an assessment looks like

ResultAll vendor access moved behind one controlled entry point within 60 days.A hospital group, after its IT provider was hit by ransomwareRead the engagement

For several days nobody could say whether the attackers had used the provider's access to reach hospital systems. We mapped every vendor with access, then assessed the riskiest in depth. We found remote support tools left running on clinical workstations, one admin account shared by three vendors, and a supplier connecting from an unpatched laptop without two-factor login. Within 60 days all vendor access ran through one controlled entry point with two-factor login and session logs, the shared accounts were gone, and contracts set deadlines for vendors to report incidents.

ResultChecking exposure to a compromised component now takes minutes, not days.A software company, after a compromised open-source componentRead the engagement

The team had spent two days searching repositories by hand to find out whether it was affected. We built SBOMs for each part of the product and found more than 1,400 indirect dependencies, several unmaintained packages with known vulnerabilities, and pipeline tokens with far more rights than they needed. SBOMs are now built in every release, so the next check takes minutes, and the company sends them to customers on request.

Explore the sample vendor assessment

A real assessment with the vendor and every identifying detail changed: where the data goes, what the vendor's own documents disagree on, and the conditions for use.

Sample

Sample vendor assessment

A desktop application for internal security testing. Vendor and identifying details changed.

Read the assessment
ASSESSMENTVERSIONPREPARED FORCLASSIFICATION
Initial vendor assessment1.0Security team, on request from the testing teamInternal, published as a sample

This is a sample. It is based on a real assessment; the vendor, its documents and every detail that would identify it have been changed. The wording of the vendor's documents is paraphrased.

VERDICT Approved with conditions, for internal testing only. The tool can be used on a dedicated, isolated machine with cloud sync switched off. Used any other way, the risk is higher than the benefit.

Scope

ItemDetail
ToolA desktop application a client's testing team wanted to use
Intended useInternal security testing by a small, named team
What was reviewedThe vendor's privacy notice, licence agreement and FAQ; the company register entry; independent reviews of the tool; public records of breaches, malware reports and regulatory action
What was not reviewedThe vendor's infrastructure and source code. The vendor publishes no audit report, so its technical claims could not be verified

Summary by category

CategoryLevelWhyRef.
Data the tool reads on the deviceMediumIt works with passwords, cookies and browsing history on whatever machine it is installed onF-01
Independent verificationMediumNo certification or audit; the security claims rest on the vendor's wordF-02
Liability under the licenceMediumAll legal responsibility for use sits with the customerF-03
Cloud syncMediumIf switched on, local data goes to the vendor and stays after the subscription endsF-04
Company transparencyLowRecently registered company, little public information about who builds the productF-05
Procurement recordLowNon-standard payment method, no ordinary invoice trailF-06
Breach and incident recordLowNothing found in public sources—

No overall score is given. Each category is read on its own, and the verdict follows from the conditions below.

Where the data goes

DataStays on the deviceSent to the vendor
Account email—At registration
Device and usage data—Yes, described by the vendor as anonymised
Saved passwords, cookies, browsing historyYes, used by the tool locallyNo
Payment details—No: a payment processor handles them, the vendor receives a confirmation only
Support messages and attachments—Only if you contact support
All local data above, if cloud sync is switched on—Yes, and kept after the subscription ends

Findings

F-01 The tool reads sensitive data on the machine it runs on Medium

The issue. To do its job, the tool works with saved passwords, cookies, local storage and browsing history. The privacy notice lists all of them. The risk is not that the tool reads them, but that it reads them on whatever machine it is installed on, including one used for everyday work. Required control. Install it only on a dedicated machine that holds no passwords, sessions or cookies from production systems and is not used for anything else. Source: Privacy notice, section on the data the tool processes.

F-02 No certification and no independent audit Medium

The issue. The vendor publishes no ISO 27001 certificate, SOC 2 report, penetration test summary or any other independent check. Its FAQ calls the product "the most secure tool of its kind", which is a claim nobody has verified. What weighs the other way. No breach, malware report or regulatory action involving the vendor was found in public sources, and independent reviews confirm that locally stored data is encrypted. That is the only security claim confirmed by someone other than the vendor. Net view. The vendor's claims cannot be confirmed, and there is no evidence against them. On an isolated machine with cloud sync off, the remaining risk is low. Source: The vendor's website and FAQ; public records of breaches, malware reports and regulatory action; two independent reviews.

F-03 All liability sits with the customer Medium

The issue. The licence agreement makes the customer solely responsible for how the tool is used and requires the customer to cover the vendor's legal costs in any related dispute. This is common for tools of this kind. What it means. If anyone uses the tool outside the approved testing scope, the organisation carries the legal and financial consequences, not the vendor. Required control. Access limited to named people, on an approved list, with the permitted use written down. Source: Licence agreement, sections on liability and indemnification.

F-04 Cloud sync sends local data to the vendor Medium

The issue. With cloud sync on, everything in the table above, including passwords and session history, is uploaded to the vendor's servers. What the vendor's documents disagree on. The licence agreement says synced data is kept for at least a year after the subscription ends. The privacy notice says six months. The longer period is treated as the one that applies. Required control. Switch cloud sync off before the first launch, and check that it stays off. This is a condition of use. Source: Licence agreement, section on data after termination; privacy notice, section on retention.

F-05 Little public information about the company Low

The issue. The company that sells the tool was registered recently, and public sources say little about who develops the product or where. What it means. On its own this does not block use. Combined with F-04, it is the main reason cloud sync must stay off. Source: Company register entry; the vendor's website.

F-06 Non-standard payment method Low

The issue. The vendor accepts payment only through a processor that does not produce an ordinary invoice trail. Required control. Note the payment method in the procurement record and keep the processor's confirmation. Source: The vendor's website, pricing and payment page.

What counts in the vendor's favour

ObservationSource
Session data is stored locally by defaultPrivacy notice
Local data is encrypted at restIndependent reviews
Cloud sync is optional and can be switched offPrivacy notice
The vendor is subject to a data protection authority and names itPrivacy notice
Transfers outside the country are covered by standard contractual clausesPrivacy notice
No breach, malware report or regulatory action foundPublic sources
A refund period is offeredLicence agreement

Conditions for use

#ConditionPriorityOwner
1Runs only on a dedicated machine with no access to production systemsMandatoryIT
2That machine is on a network segment separated from production and the corporate networkMandatoryIT
3Cloud sync switched off before first launch, and checked to stay offMandatoryTesting team lead
4No production passwords, sessions or cookies on that machineMandatoryTesting team lead
5Access limited to named people, on an approved listMandatoryTesting team lead
6Payment method noted in the procurement record, with the processor's confirmation keptRequiredFinance
7Reviewed once a year: is the tool still needed, and has anything new been published about the vendorRequiredSecurity team

Sources reviewed

The vendor's website, privacy notice, licence agreement and FAQ; the company register entry; two independent reviews of the tool; public records of breaches, malware reports and regulatory action; the list of EU adequacy decisions. In a client report, each source is listed with its full address.

Send the names of the vendors you are unsure about

A short call about what is driving this (a vendor incident, a new tool, an audit, a customer's question), roughly how many vendors you depend on, and whether your own code is in scope. We come back with a scope and a price.

Book a consultation

Did not find the service you need? Contact us.