Updated: 18 August 2026
What is third-party risk in cybersecurity, and why has it become the dominant breach vector? Third-party service provider (TPSP) risk is the exposure arising when external organisations have access to your data, systems, or infrastructure. MOVEit Transfer (May 2023) – a single vulnerability in a trusted file-transfer tool – affected over 2,700 organisations globally, with Emsisoft estimating aggregate losses above USD 15 billion. SolarWinds (2020) – a compromise of one vendor’s build pipeline – infected 18,000 clients through a digitally signed, legitimate software update.
Both incidents share the same logic: attackers target trusted suppliers because entering through a trusted front door is simpler than breaking down the target’s own defences. PCI DSS v4.0.1, NIS2 and DORA now impose specific, enforceable obligations for supplier security management – and auditors verify each one individually.
Third-party risk management – at a glance:
- Verizon DBIR 2024: breaches involving a third party accounted for 15% of all incidents – a 68% year-on-year increase, making supply chain the fastest-growing attack vector
- PCI DSS v4.0.1 Requirement 12.8 imposes six distinct obligations: maintain a TPSP list, require written agreements, conduct pre-engagement due diligence, monitor compliance annually, maintain a Responsibility Matrix, and manage payment-page scripts – each verified separately by the QSA
- NIS2 Article 21(2)(d) requires supply chain security as one of ten mandatory risk management measures for essential and important entities, covering the security of supplier relationships and procurement practices
- DORA Article 28 mandates detailed contractual provisions for critical ICT third-party providers: audit rights, exit clauses, data localisation, sub-contracting restrictions, incident notification, and exit strategies
- An annual security questionnaire sent once and not followed up does not satisfy the “annual monitoring” requirement of PCI DSS 12.8.4 – a current AOC or equivalent is required for each in-scope TPSP
- Patronusec, as an accredited QSA and vCISO partner, builds TPSP risk programmes satisfying PCI DSS 12.8, NIS2 and DORA simultaneously – from supplier inventory through Responsibility Matrix to annual monitoring.
Table of Contents
What do MOVEit and SolarWinds reveal about the true shape of supply chain risk?
Before 2020, standard supplier due diligence typically meant asking “Do you hold ISO 27001?” – and that was often where the process ended. Both incidents demonstrated that a supplier’s security certificate provides no protection against an attack that flows through that supplier.
MOVEit – anatomy of a supply chain attack
Progress Software disclosed a critical SQL injection vulnerability (CVE-2023-34362, CVSS 9.8) in MOVEit Transfer on 31 May 2023. The Cl0p ransomware group had been exploiting it as a zero-day for several weeks prior. Organisations maintaining a product inventory – not merely a list of supplier names – were able to assess their exposure within hours. Those without one took days or weeks to discover it.
Operational lesson
TPSP management must include an inventory of specific supplier products in use, not only a list of company names. Knowing you work with Progress Software is insufficient – you need to know you are running MOVEit Transfer version X to assess exposure to CVE-2023-34362 within hours of public disclosure.
SolarWinds – anatomy of a compromised software supply chain
Attackers infiltrated SolarWinds’ build environment and injected malicious code into a legitimate Orion platform update. The update carried a valid SolarWinds digital signature – signature verification provided no protection. Approximately 18,000 organisations installed the compromised version between March and June 2020. Attacker dwell time was roughly nine months before detection.
Operational lesson
A supplier’s ISO 27001 or SOC 2 certificate provides no assurance about the security of their software build pipeline. A TPSP risk programme must include questions on build pipeline security, software update integrity, and monitoring of changes in supplier products deployed in your environment.
Patronusec Insight: In TPSP reviews conducted as part of our vCISO engagements, we consistently find that organisations maintain a list of supplier certificates (ISO 27001, SOC 2, PCI DSS AOC) but have no mapping of which supplier can access which system, through which technical channel, and which data they can reach. That dependency map – TPSP by access scope by data classification – is the prerequisite for meaningful risk prioritisation. Without it, every supplier incident requires a full assessment from scratch. We build this map as the first deliverable of every TPSP risk engagement.
What does PCI DSS 12.8 require from a supplier management programme?
PCI DSS v4.0.1 Requirement 12.8 contains five sub-requirements, numbered 12.8.1 to 12.8.5. Each addresses a different aspect of TPSP management and is assessed separately. Payment-page script management is addressed by Requirement 6.4.3 and is not part of Requirement 12.8.
12.8.1 – TPSP list
The organisation maintains a list of TPSPs with which account data is shared or that could affect the security of account data, including a description of the services provided.
12.8.2 – Written agreements
Written agreements with TPSPs include an acknowledgement of the provider’s responsibility for the security of account data that it stores, processes or transmits on the customer’s behalf, or for the extent to which its service could affect the security of the customer’s environment.
12.8.3 – Due diligence
The organisation implements and follows an appropriate due-diligence process before engaging a TPSP.
12.8.4 – Compliance-status monitoring
The organisation monitors each TPSP’s PCI DSS compliance status at least once every 12 months. A current AOC covering the service used is common evidence, but where no AOC is available, other evidence or direct assessment of the applicable requirements may be necessary.
12.8.5 – Allocation of responsibilities
The organisation maintains information about which PCI DSS requirements are managed by the TPSP, which are managed by the organisation and which are shared. This is often documented in a Responsibility Matrix, although the standard does not prescribe a particular document name.
| Requirement | PCI DSS 12.8 | NIS2 Art. 21 | DORA Art. 28 |
|---|---|---|---|
| Supplier register | ✅ Mandatory | ✅ Mandatory | ✅ Mandatory (critical ICT register) |
| Written agreement with security clauses | ✅ Mandatory (12.8.2) | ✅ Mandatory | ✅ Detailed mandatory clauses |
| Pre-engagement due diligence | ✅ Mandatory (12.8.3) | ✅ Risk assessment required | ✅ Mandatory |
| Annual compliance monitoring | ✅ Mandatory (12.8.4) | ✅ Continuous monitoring | ✅ Annual reviews |
| Right to audit supplier | ❌Not explicit | ✅ Optional | ✅ Mandatory for critical providers |
| Exit clause / exit strategy | ❌Not required | ❌Not required | ✅ Mandatory |
Not sure whether your TPSP programme satisfies PCI DSS 12.8, NIS2 and DORA simultaneously?
Patronusec conducts TPSP programme reviews and delivers a gap report mapping each regulation to your current state. After a free scope-assessment call, we provide a fixed-price quotation.
Book a free scope-assessment call
How do you build a three-layer TPSP risk programme that satisfies all three regulations?
A robust TPSP programme operates across three layers simultaneously: inventory, assessment, and ongoing monitoring. All three must function on a recurring cycle – not as one-off activities.
Layer 1 – Inventory and classification
Every supplier with access to your CDE or regulated data must be identified (a complete register, not just “major vendors”), categorised by risk tier (Tier 1: direct CDE or sensitive data access; Tier 2: indirect access; Tier 3: minimal risk), and assigned a named internal owner.
Common blind spot: SaaS tools procured by the marketing team without IT’s knowledge (shadow IT) are Tier 1 if they process customer data – and they are frequently invisible to the TPSP programme entirely.
Layer 2 – Assessment at onboarding and at material changes
Before deploying any Tier 1 supplier: collect the current AOC or ISO 27001 certificate plus SOC 2, sign a Responsibility Matrix, assess technical controls (encryption in transit, access management, logging), and include contractual clauses covering security requirements, audit rights, incident procedures, and breach notification timelines.
Layer 3 – Annual monitoring
For Tier 1 suppliers annually: collect a refreshed AOC or certificate, review the Responsibility Matrix (have the services changed?), review any incidents at the supplier during the past year, and verify the patch status of supplier products deployed in the CDE.
Patronusec Insight: The most expensive element of a TPSP programme is not building it – it is sustaining it. Organisations that built a TPSP register and assessed suppliers at onboarding but did not implement annual monitoring arrive at audit with AOCs that are 18 months old – which immediately becomes a QSA finding. The highest-leverage operational change is assigning a named owner for each Tier 1 supplier, with an annual documentation-renewal task in their calendar. The cost of this change is negligible; the risk of not having it is not. In our vCISO model, we manage this cycle as an ongoing function – collecting AOCs, reviewing matrices, and flagging expiries before they become audit findings.
FAQ – Third-Party Risk Management
Does an annual security questionnaire satisfy PCI DSS 12.8.4 monitoring?
Not on its own. Requirement 12.8.4 requires confirmation that each TPSP maintains PCI DSS compliance. The preferred evidence is a current AOC. A questionnaire may supplement this for TPSPs without an AOC, but it must address PCI DSS controls specifically – not generic security questions. A “yes” checkbox without a verifiable basis is insufficient; the QSA will ask how that response was validated.
How often should we collect AOCs from our suppliers?
At minimum annually (PCI DSS 12.8.4). Best practice: set calendar alerts 60 days before each AOC expiry date. Also collect a refreshed AOC after any material change in the supplier’s services, following any security incident at the supplier, or when the previous AOC expires mid-cycle.
What is a Responsibility Matrix and who produces it?
A Responsibility Matrix maps each applicable PCI DSS requirement to one of two parties: the supplier or the client. Typically the supplier produces it and shares it with the client; the client verifies that the supplier’s stated responsibilities are covered by their AOC. If the supplier does not have a standard template, you can draft one from their AOC and service scope and ask them to confirm it in writing.
Does DORA apply to our public cloud infrastructure providers?
Yes. AWS, Azure and GCP may qualify as “critical ICT third-party providers” under DORA. If the absence of a specific provider could disrupt a financial entity’s critical operations, it should be treated as critical. DORA requires contracts with such providers to include specific audit, exit, and continuity clauses – which standard cloud agreements typically do not include without negotiating Enterprise-tier terms.
What should we do if a key supplier cannot provide a current AOC?
Options: (1) conduct your own assessment of the supplier’s controls (time-intensive but defensible to a QSA), (2) request a certification roadmap from the supplier with a board-approved temporary risk acceptance, (3) minimise the supplier’s access to CDE to the technical minimum, or (4) replace the supplier. Ignoring an absent AOC is a PCI DSS 12.8.4 finding at the next assessment.
How much does a TPSP programme review cost with Patronusec?
The cost depends on the number of Tier 1 suppliers, the regulatory scope (PCI DSS, NIS2, DORA, or a combination), and the current state of your documentation. After a free 30-minute scope-assessment call, we provide a fixed-price quotation with a defined scope and delivery timeline. For clients in our vCISO model, TPSP monitoring is part of the ongoing engagement.
How long does building a TPSP programme from scratch take?
For a mid-market organisation, a complete inventory and initial Tier 1 assessment typically takes 3 to 5 weeks with external support. Implementing the ongoing monitoring cycle takes a further 2 to 4 weeks. The full programme – inventory, assessments, Responsibility Matrices, and monitoring cadence – can be operational within 8 to 12 weeks.
Third-party risk management – free consultation
Patronusec, as an accredited QSA and vCISO partner, builds and maintains TPSP risk programmes for organisations in fintech, e-commerce, and financial services – satisfying PCI DSS 12.8, NIS2 and DORA simultaneously, without unnecessary duplication of documentation.
In a free 30-minute consultation we will help you:
- Assess whether your current TPSP programme satisfies PCI DSS 12.8, NIS2 and DORA
- Identify the Tier 1 suppliers whose verification is most urgent from an audit perspective
- Plan the implementation of a TPSP register and annual monitoring process
- Choose between a one-off review and ongoing management in the vCISO model
Free consultation | vCISO service | PCI DSS certification | Gap analysis | NIS2 compliance
