When your supplier gets breached: three European cases and an Incident Response Playbook

This is concentration risk. For the attacker, one compromise yields many victims. For each customer, the incident is outside its control, yet the consequences — notification duties, customer trust, operational disruption — are its own.

The Ribon case adds a further layer. The compromised credentials belonged to an app, and the app’s credentials were exposed through a compromise at its parent company, Fastr. Most supplier inventories stop at the first tier. The exposure did not.

A supplier incident does not mean the customer’s infrastructure has been compromised. It does mean the customer must establish, with its own evidence, whether its data, access paths or operations have been affected.

Before the incident: what makes the response possible

Most of the playbook below depends on work done before any supplier calls. Four preparations carry most of the weight:

• An inventory of data shared with suppliers, including non-production copies: test sets, migration extracts, support exports. Where real personal data is not required for testing, minimise or pseudonymise it. The PKZH case shows what a migration dataset can expose.
• Supplier credentials with owners and scope. Every API key, service account and app permission should have an accountable owner, a documented purpose and the narrowest scope that purpose needs. Revocation should be a rehearsed action, not a search.
• Your own logs of supplier activity. Authentication, API calls and data transfers by suppliers inside your environment should be logged and retained, so your investigation does not depend on the supplier’s account alone.
• An agreed evidence package in the contract. Define in advance what the supplier must provide after an incident: timelines, affected systems, data categories, access records, remediation evidence and, where justified, independent validation.

An eight-step third-party incident-response playbook

The workflow below is proposed operational guidance, informed by established incident-response practice such as NIST SP 800-61 Rev. 3. It is not a reconstruction of what the organisations above actually did.

Step 1 — Establish ownership and classify the event

Owner: Incident Commander / Security Manager

Register the supplier notification as a security event and decide whether it activates your incident-response process. Record the supplier, the affected business services, the known facts and the open questions. Establish a verified channel with the supplier’s incident-response team and name who collects updates.

Evidence: incident record, accountable owner, notification timestamp, initial classification, decision log.

Escalate when: a critical supplier, sensitive dataset, privileged integration or essential service may be affected.

Step 2 — Map the dependency and potential exposure

Owner: Security Architecture / IT / Vendor Manager

Identify the systems, identities, data and business services tied to the supplier, using the CMDB, records of processing, integration documentation and access records. Include production and non-production environments; service accounts and privileged access; API keys, tokens and app permissions; data exports, migration datasets and test copies; backups and support data held externally; and the supplier’s own critical subcontractors, where known.

Assessing only live production integrations would have missed the PKZH exposure.

Evidence: a dependency map linking supplier access, systems, data and business services.

Escalate when: the scope of shared data cannot be established, sensitive data may be exposed, or a critical function depends on the supplier.

Step 3 — Make a containment decision

Owner: Incident Commander / IT Operations / Business Owner

Decide whether continued connectivity is an acceptable risk. Options include restricting access, disabling integrations, revoking credentials or suspending data transfers, as Ace & Tate did on the day it was informed. Preserve logs and forensic evidence before making changes wherever feasible.

The goal is not to disconnect every supplier by reflex. It is a documented, proportionate decision taken with the business owner.

Evidence: containment decision, actions taken, affected assets, residual-risk assessment.

Escalate when: credential compromise is suspected, malicious activity is found, or the supplier cannot give reasonable assurance that continued access is safe.

Step 4 — Investigate the environment you control

Owner: SOC / DFIR

The SOC usually has no access to the supplier’s telemetry. It can investigate the supplier’s interactions with your environment: authentication records, privileged sessions, API activity, network connections, application logs and data transfers. Look for unusual requests, unexpected volumes, abnormal service-account behaviour and changes from established baselines, and correlate them with any indicators the supplier shares.

An absence of alerts is not evidence of no compromise, especially where the relevant activity falls outside monitoring coverage.

Evidence: investigation timeline, queries and results, forensic artefacts, findings, documented visibility gaps.

Escalate when: unauthorised access, suspicious data retrieval, privilege misuse or lateral movement is identified.

Step 5 — Establish data exposure and business impact

Owner: Incident Commander / Data Owner / DPO / Business Owner

Determine what data the supplier held, how it was stored, and whether there is evidence of access or exfiltration. Request validated findings from the supplier: timestamps, affected systems, access records and data categories. Sort findings into confirmed exposure, suspected exposure, and exposure not yet determinable.

In the Ace & Tate case, initial notices said personal data could not be ruled out; confirmation of access came weeks later. Plan for that gap. A lack of confirmed exfiltration is not proof that data was not accessed.

Evidence: data-impact assessment, affected services, supporting findings, outstanding evidence requests.

Escalate when: sensitive data, material disruption or potentially reportable consequences are identified.

Step 6 — Assess regulatory reporting obligations

Owner: Legal / Compliance / DPO / Security Management

Determine which legal and contractual notifications apply. For entities in scope of NIS2 or its national transposition, assess whether the incident meets the criteria for a significant incident. Evaluate GDPR personal-data-breach obligations separately. Record when you became aware of the relevant facts, which thresholds apply, and why you decided as you did.

The supplier’s ongoing investigation does not pause your own reporting clock.

Evidence: documented regulatory assessment, applicable deadlines, notification records.

Escalate when: a threshold may be met, a deadline is approaching, or uncertainty prevents a defensible assessment.

Step 7 — Validate remediation before reconnection

Owner: Security / IT Operations / Business Owner

A supplier announcing that its services are running again does not by itself show that the security risk has been resolved. Request evidence of containment, remediation, credential rotation and validation proportionate to the incident; where the risk warrants it, require independent assurance. Reconnect in stages, with increased monitoring.

Evidence: remediation documentation, validation results, residual-risk assessment, authorised reconnection decision.

Escalate when: the attack path has not been addressed, critical evidence is missing, or residual risk exceeds approved tolerance.

Step 8 — Review the incident and improve the controls

Owner: Security Management / Vendor Risk / Business Owner

Review both the supplier relationship and your own response. Could you identify the dependencies, retrieve the evidence, execute containment and keep essential operations running? Update contractual requirements, access scopes, logging coverage, notification arrangements and recovery procedures, and assign each corrective action an owner and a verification criterion.

Evidence: post-incident report, remediation plan, updated supplier risk assessment, evidence of closure.

Escalate when: material risks remain open or the supplier cannot meet your security and assurance requirements.

Where NIS2 changes the expectations

Supply-chain security is an explicit part of cybersecurity risk management under Article 21 of the NIS2 Directive (EU 2022/2555). Each member state’s transposition turns that into concrete duties. Romania’s is a useful example of how specific those duties become.

In Romania, NIS2 is transposed by Emergency Ordinance (OUG) 155/2024, approved with amendments by Law 124/2025. For essential and important entities in scope:

• Article 13 covers risk-management measures, including supply-chain security and the security of relationships with direct suppliers and service providers.
• Article 14 makes management bodies responsible for approving and overseeing those measures.
• Article 15 sets out reporting for significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report generally within one month. It also sets a separate six-hour deadline for information that allows the national CSIRT to establish cross-border impact.

These obligations are not triggered automatically when a supplier reports an incident. The organisation must assess its own status, the incident’s impact and the reporting criteria. GDPR breach obligations are evaluated separately.

The three cases above occurred in other jurisdictions; Romanian law did not govern them. It is used here only to show what the same scenario would demand of an in-scope organisation under one national transposition.

What a SOC can and cannot do

A SOC cannot access a supplier’s infrastructure, reproduce its forensic investigation or verify every claim in its incident report. It can see supplier activity inside the monitored environment, investigate access paths, correlate evidence, support containment decisions and document what remains unknown.

How much of that it can do is decided before the incident: whether dependencies are mapped, whether supplier integrations are logged, whether permissions have owners, whether escalation involves the right business functions. Vendor management, legal, privacy, IT operations and leadership all carry part of the response. The SOC is central to it, but it does not own it alone.

The operational lesson

Supplier relationships extend your dependencies beyond the infrastructure you own: application credentials, logistics systems, personal data, and production data handed over for projects that have not yet gone live. When one supplier serves many customers, a single compromise becomes many incidents at once.

No security programme can guarantee visibility into a third party’s systems. It can establish which dependencies exist, what is observable, what access can be controlled, and what evidence suppliers must provide.

The measure of readiness is not whether you prevent every supplier compromise. It is whether you know what to investigate, who can authorise containment, what must be reported, and what evidence you need before trust is restored.

Sources

Public information reviewed as of 22 October 2026. The playbook represents proposed practice, not a reconstruction of the affected organisations’ procedures.

Incident disclosures

• Swiss Federal Council — Cyberattack on Publica software supplier: data outflow confirmed (8 Oct 2026)
• PK Softech — Cyberattack statement
• inside-it.ch — Data outflow at the federal pension fund
• SRF — Publica: data categories potentially affected
• PKZH — Cyberattack on PK Softech
• Nau.ch — PKZH statement of 15 Oct 2026
• Migros-Pensionskasse — Cyberattack on software supplier
• BleepingComputer — BigCommerce alerts merchants of breach linked to Ribon apps
• teiss — Ribon attack and Master of Malt
• TechCrunch — CEVA Logistics breach ripples across banks, retailers and Steam (10 Aug 2026)
• Dutch IT Channel — Ace & Tate reports possible data breach after CEVA intrusion
• RetailDetail — De Bijenkorf: customer data was indeed accessed (10 Sep 2026)