Third-Party Risk: Make Your Suppliers Audit-Ready

The number has doubled. Recent analyses show that nearly 30% of all reported data breaches involve third parties, an increase from 15% the year before. In the first half of 2025 alone, 79 supply chain attacks were responsible for security incidents at 690 organisations. And this trend is not going to ease up in 2026.

The result: supplier risk management has been promoted from a side topic to a mandatory discipline. NIS2, DORA and ISO 27001 force organisations not just to know their third-party dependencies, but to document, assess and continuously monitor them.

This article shows you how to build a structured supplier risk management programme and document your entire vendor landscape in an audit-ready way.

Why third-party risk is escalating in 2026

The reasons sit on two levels: technical and regulatory.

On the technical side: third parties are not isolated islands. They are integrated into your systems, have access to your data, and run critical functions. A security breach at a supplier quickly becomes your breach too. The average cost of a third-party breach is around 4.91 million dollars globally. That is 40% higher than the cost of internal security incidents.

Particularly insidious: breaches involving supply chain compromise take 267 days to be detected and remediated. That is longer than for any other attack vector. If your supplier has been hacked, you may not notice it until far too late.

On the regulatory side: NIS2, DORA and ISO 27001 (in the 2022 revision) have made supply chain risk management a mandatory area of audit. A vague trust in your suppliers is no longer enough. You have to be able to demonstrate that you know who they are, what risks they bring, and how you mitigate those risks.

For 98% of all organisations, the following holds true: at least one of their suppliers has already been affected by a data breach. The statistic is a wake-up call. You need a system that you control yourself.

What NIS2 and DORA specifically require of you

NIS2: the ten minimum measures

The NIS2 directive explicitly names "supply chain security" as one of its ten minimum measures. That means: you have to document that you have identified your suppliers and service providers, assessed their risks, and that your contracts with them include appropriate security requirements.

NIS2 is technology-neutral. It does not prescribe exactly how you have to do this. That gives you flexibility, but it also makes you accountable for implementation. An auditor will ask:

• Do you have a procedure for classifying suppliers?
• Are critical suppliers (those running critical functions) documented?
• Which security requirements are contractually fixed?
• How is compliance monitored?

DORA: detailed and sector-specific

DORA is primarily aimed at the financial sector, but it sets a precedent. Under DORA, third-party risk management is not just a topic, it is one of the pillars of the entire governance model.

Concrete requirements:

• Supplier register. You have to document not only your direct suppliers, but also disclose their subcontractors. This must be entered into a dedicated information register that is available to financial supervision.
• Criticality thresholds. If a supplier or subcontractor is "critical" (because at least 10% of all supervised financial institutions use it), it is subject to additional oversight.
• Contract clauses. Security obligations must be written into every contract with third parties. This is not optional.

DORA explicitly requires financial institutions to manage the risks of outsourced critical functions and third-party providers and to ensure the resilience of the supply chain.

Building a vendor risk management programme

A structured VRMP has four phases.

Phase 1: Inventory and classification

First, you need to know who you depend on. That sounds trivial, but it is often the bottleneck.

Inventory: create a complete list of all third-party service providers. This includes software vendors, hosting providers, consultants, service providers, and yes, even the cleaning service if it has access to sensitive areas. A common mistake is to capture only "IT-relevant" providers and forget the rest.

Classification: not all suppliers are equally critical. Develop a classification scheme based on:

• Data access: does the supplier have access to sensitive or personal data?
• System criticality: do critical business processes depend on this supplier?
• Substitutability: how easily can you switch suppliers?
• Regulatory criticality: is the supplier essential for compliance requirements?

A simple classification might be: critical, medium, low. Later, in monitoring and due diligence, your requirements scale with this class.

Documentation: store this inventory in a central database or spreadsheet. It is the foundation for everything that follows.

Phase 2: Due diligence and risk assessment

Before signing a contract or during regular reviews, you have to assess the supplier's security posture.

Security questionnaire: a structured questionnaire system (often CAIQ, the Consensus Assessments Initiative Questionnaire, or your own format) helps you ask in a standardised way:

• Are certifications in place (ISO 27001, SOC 2, etc.)?
• Is the incident management process documented?
• Are encryption standards implemented?
• Are backup and disaster recovery plans in place?

The advantage of a standardised questionnaire: it is reproducible and comparable. The downside: suppliers can fill in the form in a way that does not reflect reality. That is why the next point is important.

Certifications and audits: request evidence. An ISO 27001 certificate is no guarantee, but it is a strong indicator. If the supplier is not certified, ask for SOC 2 Type II audit reports (especially relevant for cloud services). For cloud services, ISO 27001 control A.5.23 plays a central role; suppliers should understand the shared responsibility model and communicate transparently which controls they take care of.

Contractual requirements: write the security requirements into the contract. Do not rely on assurances that you cannot enforce later. Under ISO 27001 control A.5.20 this is explicitly required. The contract should cover:

• Data protection and compliance (GDPR, local laws)
• Security standards (encryption, access control)
• Incident notification obligations (within what time must a breach be reported?)
• Audit and inspection rights (is your company allowed to perform security checks?)
• Subcontracting policy (is the supplier allowed to use further subcontractors? Under what conditions?)

Phase 3: Continuous monitoring and review

ISO 27001 control A.5.22 obliges you to ongoing monitoring, review and change management of supplier services. This is not a one-off process.

Risk dashboards: establish metrics to continuously monitor your suppliers' security posture. These can be:

• Security ratings (e.g. based on vulnerability scanning if the supplier offers a SaaS product)
• Incident history: has the supplier had public security incidents?
• Certification status: is the ISO 27001 certification still current?

Periodic reassessments: based on classification, you should reassess suppliers at regular intervals. Critical suppliers at least annually, medium-criticality suppliers every two to three years, low-criticality suppliers every three to five years. A simple tracking table with reassessment dates is your friend.

Incident monitoring: subscribe to security feeds that alert you when one of your suppliers is affected by a publicly known vulnerability or breach. Tools like Google Alerts, patch management services, or specialised third-party risk platforms help here.

Fourth-party risk: the often-forgotten risk

This is where it gets tricky. Your direct supplier (third party) uses its own supplier (fourth party). You probably do not know that one. But it could hit you.

The classic example: CrowdStrike in 2024. A faulty software update affected not only CrowdStrike's direct customers, but also their customers and their customers. The impact was global.

Only 13% of organisations review their direct suppliers, and only 7% investigate fourth-party risks. That is a significant gap.

What can you do?

Subcontractor requirements in contracts: require your direct suppliers to disclose their own subcontractors and to run their own third-party risk management. That is the DORA approach: cascade requirements.

Create visibility: you cannot directly control all fourth parties, but you can ask:

• Which critical subcontractors does the supplier use?
• How does the supplier monitor them itself?
• What security obligations are contractually agreed with them?

Resilience through diversification: where possible, avoid excessive dependence on individual critical suppliers or their suppliers. Single points of failure are a security risk.

ISO 27001 integration: five controls for third-party risk

ISO 27001 in the 2022 revision groups supplier management under five controls: A.5.19 to A.5.23. This is your reference framework for many audits.

A.5.19: Information Security in Supplier Relationships This is the core control. It requires from you:

• A documented supplier management procedure that covers the full lifecycle: identification, assessment, mitigation of risks before, during and after the end of the relationship.
• Supplier vetting and due diligence before contract signing (security questionnaires, certification verification).
• Supplier segmentation. Not all suppliers are equally critical. Your controls should match the risk.

A.5.20: Addressing Information Security within Supplier Agreements Security requirements must be anchored contractually. This is non-negotiable.

A.5.21: Managing Information Security in the ICT Supply Chain This is specifically aimed at ICT suppliers. It requires the management of security risks across the entire ICT supply chain, including governance and compliance requirements.

A.5.22: Monitoring, Review and Change Management of Supplier Services You have to continuously monitor the security of your suppliers and review it regularly. Changes in the supplier's configuration, services or policies must be known to you.

A.5.23: Information Security for use of Cloud Services A separate control, because cloud services have their own pitfalls. Shared responsibility model, data residency, service level agreements, exit strategies. All of this has to be clear.

An ISO 27001 auditor will want to see:

• The supplier catalogue.
• Due diligence documentation for each supplier.
• Examples of contracts with security clauses.
• Monitoring and review logs (who reviewed what, when?).
• Incident log: have there been security incidents and how were they handled?

Without this documentation you will not pass an ISO 27001 certification or reassessment.

Fines and liability: the financial consequences

The regulations are not only a compliance topic. It is about money.

NIS2: violations can be sanctioned with fines of up to 10 million euros or 2% of global annual turnover (whichever is higher). For larger organisations this is significant.

DORA: similar scale. Violations of third-party risk management requirements can lead to fines.

Liability: in addition to fines, injured parties (e.g. when your supplier was hacked and the hack compromised your system) can claim damages. If you were negligent in selecting or monitoring the supplier, you may be liable yourself.

Example: your hosting provider gets hacked. Your customer data leaks. The customer sues you. Your defence might be: "I did everything I could to vet this provider. I could not have foreseen this gap." But this only works if you can document that you ran a structured risk management process. Otherwise your liability is hard to limit.

Practical documentation template: audit-ready setup

Here is a minimal set of documents you need:

1. Supplier register (spreadsheet or database)

Supplier ID	Name	Category	Classification	Reassessment Due	Certifications	Status
SUP001	CloudProvider XYZ	Cloud Services	Critical	Q2 2026	ISO 27001, SOC 2 Type II	Approved
SUP002	Office Cleaning Service	Facility Services	Low	Q4 2026	None	Approved

2. Supplier risk assessment template

Supplier ID: SUP001
Name: CloudProvider XYZ
Assessment date: 2026-01-15
Evaluator: IT security team

Due diligence checklist:
[ ] Security questionnaire completed
[ ] ISO 27001 certificate verified
[ ] SOC 2 audit report requested
[ ] Privacy policy reviewed
[ ] Security policies documented
[ ] Subcontractors disclosed

Overall risk rating: Medium
Justification: ISO 27001 certified, but limited visibility into subcontractor structure.

Mitigation measures:
1. Conduct annual reassessments.
2. Anchor audit rights in the contract.
3. Make incident notification mandatory (48 hours).

Approved by: Chief Information Security Officer

3. Supplier agreement security addendum

SECURITY ADDENDUM TO THE SUPPLIER AGREEMENT

3.1 Security standards
The supplier commits to implementing and maintaining at least the controls from
ISO 27001 Annex A (current version), to the extent applicable to its services.

3.2 Incident notification
The supplier commits to notifying the customer in writing of any security incident
affecting the provided services within 48 hours.

3.3 Audit and inspection rights
The customer has the right to perform security audits, or have them performed by
third parties, at least once per year, with reasonable advance notice.

3.4 Subcontractors
The supplier may only engage subcontractors with the written consent of the customer.
A list of all subcontractors must be maintained and made available to the customer on request.

3.5 Data protection
The supplier commits to complying with all applicable data protection laws,
in particular GDPR and local data protection regulations.

3.6 Termination and data return
Upon termination of the contract, the supplier will return all customer data in a
secure format or securely destroy it, demonstrably, within 30 days of contract end.

4. Monitoring and review log

Supplier ID: SUP001
Monitoring period: 2026 Q1

Date | Activity | Result | Performed by
2026-01-10 | Vulnerability scan of cloud platform performed | 3 low-criticality findings, vendor confirmed patch plan | Security Team
2026-02-15 | Annual reassessment started | Questionnaire sent | Compliance Officer
2026-03-05 | Reassessment response received | Positive, no material changes | Compliance Officer
2026-03-20 | Certification status checked | ISO 27001 still valid until 2027-01 | GRC System

Conclusion: No elevated risk identified. Approval continues.

Common mistakes when building a VRMP

Mistake 1: only inventorying IT suppliers Non-IT suppliers (facility services, recruitment, consulting) can carry just as much risk. A cleaner with access to server rooms is a third-party risk.

Mistake 2: taking the questionnaire as the final truth Questionnaires are a starting point, not end-state assurance. A supplier can fill out a form and still have security gaps. Certifications and external audits are stronger.

Mistake 3: treating due diligence as a one-off Security is not a one-time event. A supplier can be certified today and hacked tomorrow. Regular reassessments are necessary.

Mistake 4: no risk hierarchy If you treat all suppliers with the same rigour, you waste resources. An office furniture supplier does not need the same scrutiny as a security service provider.

Mistake 5: ignoring fourth-party risk You cannot ignore it. The question is not whether your third parties also use fourth parties, but how you protect yourself against them.

Implementation roadmap: 6 months to full coverage

Month 1-2: inventory and classification

• Capture all third-party relationships.
• Define a classification scheme.
• Conduct an initial risk assessment.

Month 3: due diligence

• Send security questionnaires to critical and medium-criticality suppliers.
• Request certifications.
• Review contracts for security clauses.

Month 4: contract adjustment

• Develop security addenda for existing contracts.
• Renegotiate with critical suppliers.
• Onboard new suppliers automatically with the security addendum.

Month 5: monitoring setup

• Establish monitoring tools or processes.
• Assign monitoring responsibilities.
• Run the first quarterly review.

Month 6: documentation and audit readiness

• Centralise all documents (GRC system or file repository).
• Conduct an internal audit.
• Set up governance meetings (at least quarterly).

This roadmap is compressed. Larger organisations with hundreds of suppliers will need longer.

Conclusion: documentation as a defensive wall

Third-party risks are not going away. They are growing. With 30% of all data breaches going back to suppliers, it is clear: you need a system. Not to eliminate every risk (that is impossible), but to show that you know the risks, assess them, and actively manage them.

That is exactly what NIS2, DORA and ISO 27001 require of you. A structured, documented vendor risk management programme.

The good news: it is all doable. It does not require exotic tools (spreadsheets are enough to start), but it does require discipline. An inventory, an assessment process, monitoring, regular reviews. And documentation. Always documentation.

Whoever has these four things is audit-ready. And that is the goal.