Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Supply-chain incident response checklist
Updated
Confirm whether a vendor or supply chain dependency breach reached you. Map the blast radius. Walk contractual and possible DORA or CRA flow-down duties with counsel. This page does not start a clock and is not legal advice.
Operational guidance, last verified 7 September 2026 against Regulation (EU) 2022/2554 (Digital Operational Resilience Act — ICT third-party risk in Chapter V and major-ICT-related-incident reporting in Article 19; a legal requirement only if DORA applies to YOU as a financial entity, not a universal vendor-breach statute), Regulation (EU) 2024/2847 (Cyber Resilience Act — manufacturer due diligence on third-party components in Article 13(5)–(6) and manufacturer reporting in Article 14; a legal requirement only if CRA applies to YOU as a manufacturer or in-scope steward of a product with digital elements, and Article 14 reporting applies from 11 September 2026), NIST SP 800-161 Revision 1 Update 1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, 1 November 2024 — C-SCRM guidance, not a statute), and ENISA, Good Practices for Supply Chain Cybersecurity (13 June 2023 — an agency report of observed practice, not a statute). Roles are described generically (ICT third-party service provider, component manufacturer, processor, customer). This page does not rank vendors, does not start a notification clock, and is not a substitute for counsel, your insurer, or a retained DFIR firm. Not legal advice.
Intake the vendor incident first — this is not a statute
Audience: the incident commander facing a breach or outage at a vendor, a compromised dependency, or a poisoned component, and counsel, the insurer, and DFIR on the out-of-band bridge. The we've-been-breached page on this site is the first-moves hub. The first-72-hours page on this site is the clock-mapping checklist. The compromise-vs-breach page on this site is the taxonomy (compromise, access, exfiltration, confirmed data breach). The repository-compromise-checklist page on this site is the planted-commit and poisoned-release hunt when the supply-chain path ran through YOUR source. The cicd-compromise-checklist page on this site is the freeze-and-audit, secret-rotation, and artifact-provenance runbook. This page is the third-party / supply-chain runbook: confirm exposure, map blast radius across YOUR systems and published artifacts, then walk contractual versus possible regulatory flow-down duties with counsel. It does not rank vendors, does not name a preferred ICT third-party service provider, does not interpret YOUR contract, and does not start a notification clock.
A vendor telling you they had an incident is not a finding that YOUR data was stolen, that a statute applies, or that a clock has started. Confirm what reached you before you notify anyone. NIST SP 800-161r1-upd1 treats cybersecurity supply-chain risk as a risk-management practice — identify, assess, respond — not as a filing form. ENISA's Good Practices for Supply Chain Cybersecurity is observed practice among essential and important entities, not a law. Regulation (EU) 2022/2554 and Regulation (EU) 2024/2847 are legal requirements only when they apply. Last verified 7 September 2026. Not legal advice.
- Intake first, then blast radius, then duties. A customer email sent before you know whether the vendor held YOUR data is how you invent a notification you cannot later unsay. The compromise-vs-breach page on this site is that taxonomy.
- Do not tip the actor. No in-band 'we see you' to the vendor's possibly compromised channel, no public status page, no mass secret rotation from an identity the vendor still holds. Preserve the vendor notice, the contract, and YOUR logs of what you consumed. The preserve-evidence page on this site is that hold.
- Contractual notice and regulatory filing are different instruments. A DPA clause that you will tell a customer within 48 hours is not a DORA Article 19 report and not a CRA Article 14 early warning. Counsel maps each. This page does not.
- This page does not rank vendors, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
What to do now
Walk top to bottom. Unknowns belong on the list. Last verified 7 September 2026. Not legal advice.
- Declare the incident. Name one commander. Open an out-of-band bridge the actor cannot see (phone, a clean conference — not the vendor's possibly compromised Slack). The who-to-call page on this site is the contact order.
- Intake the vendor incident: who notified, when (UTC), what they claim happened, which of YOUR services, data, identities, or published artifacts they say were in scope, and what they have not yet said. Save the notice. This product does not intake a vendor notice for you.
- Place the evidence hold on YOUR side: vendor emails and tickets, contracts and DPAs, SBOMs and lockfiles, access logs to the vendor, pipeline runs that consumed the component, and package or container pulls in the dwell window. Do not delete the vendor account, rotate those logs away, or 'clean up' the dependency tree. The preserve-evidence page on this site is the capture list.
- Confirm exposure before you notify: did the vendor actually hold YOUR data or identities; did YOUR systems pull the affected version; did a pipeline publish an artifact that embeds it. A press article about a vendor is not exposure. This product does not confirm that a named vendor held YOUR data.
- Map the blast radius: which repositories, services, environments, customers, and published artifacts consume the affected vendor or dependency, including transitives. Unknown consumers are a gap, not a clean bill. This product's blast-radius search is over captured dependencies — transitive npm when a lockfile was fetched — which is package exposure in YOUR tree, not a filing.
- Walk flow-down duties with counsel: contractual notices (MSA, DPA, customer SLAs) versus possible regulatory duties (DORA ICT third-party / Article 19 if you are a financial entity; CRA Article 13(6) and Article 14 if you are a manufacturer; GDPR Article 33(2) if the vendor is your processor). Mapping is not filing. This page does not start a clock.
- Contain third-party risk: revoke the vendor's access you can revoke, pin or yank the affected component, rotate secrets the vendor could have seen, and record what you cannot yet contain. Page the insurer if YOUR policy requires prompt notice. This product does not revoke a vendor's access.
Vendor-incident intake
Containment for a third-party incident is not 'forward the vendor's blog post to customers and hope.' Intake is a record: what was claimed, what you can corroborate, and what is still unknown. NIST SP 800-161r1-upd1 frames C-SCRM as identifying and assessing supply-chain risk before you respond — guidance, not a statute. Walk the rows. Last verified 7 September 2026. Not legal advice.
| Surface | What 'done' looks like | If you skip it |
|---|---|---|
| Who notified, and through which channel | The notice is saved (email, ticket, status page capture) with UTC received-time. The channel is marked trusted or untrusted. A notice that arrived on the vendor's possibly compromised chat is recorded as such. | You cannot later prove when you became aware. 'Becoming aware' is a legal and factual test under more than one regime. This page does not start that clock. |
| What the vendor claims happened | Incident type (outage, ransomware, credential theft, poisoned component, sub-processor), dwell they admit, and what they say was in scope. Their words are quoted, not paraphrased into a statute. | A later regulator file that restates the vendor's marketing language as YOUR finding is how two facts become one story you cannot defend. |
| What of YOURS was in play | Data categories, identities, keys, environments, and published artifacts the vendor could have reached. 'Unknown — vendor has not said' is a line, not a silence. | You notify a customer whose data was never there, or you skip one whose data was. The compromise-vs-breach page on this site is the taxonomy. |
| Contract and DPA in force | The MSA, DPA, subprocessors schedule, and any incident-notification clause are pulled. The clause is quoted. Whether it is a contractual duty is a contract question for counsel. | You miss a 24-hour customer clause because you were reading DORA, or you invent a DORA duty because the DPA said 'promptly.' |
| Identities and access the vendor still holds | SSO grants, API keys, deploy credentials, support jump-hosts, and inbound webhooks from that vendor are listed. Unexplained access is revoked after the evidence hold. | The actor keeps a vendor-issued path into YOU after the vendor's blog post says they are 'contained.' This product does not revoke a vendor's access. |
Blast-radius assessment for affected dependencies
A vendor incident is not automatically a dependency incident, and a dependency CVE is not automatically YOUR exposure. Map consumers before you notify. This product's blast-radius search is over captured dependencies — transitive npm when a lockfile was fetched. That is package exposure in YOUR tree, not a finding that a named vendor was breached, not a hunt for planted commits, and not a flow-down filing. Last verified 7 September 2026. Not legal advice.
| Question | What 'done' looks like | Limit |
|---|---|---|
| Did we consume the affected component or version? | Lockfiles, SBOMs, container images, and vendor-library inventories are searched for the affected name and version range, including transitives. Hits and misses are recorded. Unknown ecosystems (a language you do not lock) are listed as unknown. | This product's blast-radius search covers captured dependencies — transitive npm when a lockfile was fetched. It does not scan every ecosystem and does not prove a vendor SaaS held YOUR data. |
| Which services and environments run it? | Each hit is mapped to repositories, deployable services, and environments (prod, staging, CI). Owners are named. A library that never left a developer laptop is still a fact, not a skip. | A blast-radius list without owners is a spreadsheet, not containment. |
| Did we publish an artifact that embeds it? | Packages, containers, mobile builds, and firmware that include the affected component and were published in the window are listed. Downstream consumers of YOUR artifact are a second blast radius. The repository-compromise-checklist page on this site is the poisoned-release hunt when the path was YOUR source. | Yanking a package without a copy and a consumer-notification plan destroys evidence. The cicd-compromise-checklist page on this site is the freeze-and-audit runbook. |
| Did the vendor hold OUR data or identities, even if no package is in the tree? | SaaS processors, identity providers, observability vendors, and support contractors are a different blast radius from npm. Intake (above) answers this; blast-radius search does not. | Searching lockfiles for a payroll vendor's name will miss the payroll vendor. Do not treat a clean package search as a clean SaaS finding. |
Flow-down notification duties — contractual versus regulatory
This is a decision tree of questions for counsel, not a determination and not a clock this page starts. Contractual duties come from YOUR agreements. Regulatory duties come from named instruments that apply to YOU. They can run at the same time. Filing one never discharges the other. Last verified 7 September 2026. Not legal advice.
| Instrument | What it may require | Verify before you treat it as yours |
|---|---|---|
| YOUR contract (MSA, DPA, customer SLA) — contractual, not a statute | Many processing and services agreements require the processor or vendor to notify the customer without undue delay, or inside a stated number of hours, when they become aware of a security incident affecting the customer's data. YOUR customer contracts may require YOU to notify them on the same facts. Quote the clause. Perform it if counsel says it applies. | A contractual hour-count is not a GDPR 72-hour filing, not a DORA Article 19 report, and not a CRA Article 14 early warning. Counsel reads YOUR paper. This page does not interpret YOUR contract and does not start a clock. |
| Regulation (EU) 2022/2554 (DORA) Article 19 and Chapter V — legal requirement only if DORA applies | Financial entities report major ICT-related incidents to the relevant competent authority (Article 19). ICT third-party risk is managed as part of ICT risk (Chapter V, including Article 28 general principles and Article 30 key contractual provisions such as assistance in the event of an ICT incident). A major incident at an ICT third-party service provider can still be YOUR Article 19 report if YOU are the financial entity and the incident is major for YOU. | DORA applies to defined financial entities, not to every company that uses a vendor. 'Major ICT-related incident', 'ICT third-party service provider', and 'critical or important function' are legal and factual tests. Implementing rules further specify report contents and time limits; counsel maps those. This page does not apply DORA to you and does not start an Article 19 clock. DORA engineering metrics on this product (deployment frequency, lead time, change-failure rate, time to restore) are delivery metrics; they are not a Regulation (EU) 2022/2554 filing. |
| Regulation (EU) 2024/2847 (CRA) Articles 13 and 14 — legal requirement only if CRA applies | Manufacturers exercise due diligence when integrating components sourced from third parties (Article 13(5)). Upon identifying a vulnerability in an integrated component, including an open-source component, they report it to the person or entity manufacturing or maintaining that component (Article 13(6)) — a flow-down to the maintainer, not a CSIRT filing. Article 14's manufacturer reporting ladder (early warning, notification, final report) is a legal requirement when it applies, to the CSIRT designated as coordinator and to ENISA via the Single Reporting Platform, from 11 September 2026. | CRA applies to manufacturers (and some other economic operators and in-scope open-source stewards) of products with digital elements on the Union market — not to every consumer of a library. Scope, 'product with digital elements', 'becoming aware', 'actively exploited', and 'severe' are legal and factual tests. A vulnerability in a component that cannot be exploited in YOUR product is not an Article 14 actively-exploited-vulnerability duty on that ground; Article 13(6) may still ask you to tell the maintainer. Counsel maps both. This page does not apply CRA and does not start an Article 14 clock. |
| Regulation (EU) 2016/679 (GDPR) Article 33(2) — legal requirement only if GDPR applies | A processor notifies the controller without undue delay after becoming aware of a personal data breach. If the vendor is YOUR processor and YOUR personal data was in play, that is a processor→controller flow-down TO you, which may then start YOUR controller assessment under Article 33(1). If YOU are the processor for a customer, YOUR flow-down is to that controller. | Processor versus controller, 'personal data breach', and 'becoming aware' are legal and factual tests. Article 33(2) is not a 72-hour DPA filing by the processor. The first-72-hours page on this site is the controller-side 72-hour map. This page does not start either clock. |
Where this shows up in ShipReady Metrics
The signed-in app does not file a flow-down notice, does not determine that DORA or CRA applies, does not intake a vendor's incident notice, does not revoke a vendor's access, and does not start a notification clock. If you already have a session: signed-in app → Security → Blast radius searches captured dependencies — transitive npm when a lockfile was fetched — which is package exposure in YOUR tree, not a finding that a named vendor was breached and not a flow-down filing. Dependency ingest (Dependabot and other SCA findings) lands in Security findings. signed-in app → Compliance → Questionnaires drafts answers from recorded posture; it does not send a customer or regulator notice. signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a determination that CRA applies, it does not start a clock for you, and a named human still submits. The obligation map (frameworks you have marked in-scope, including DORA and CRA among the crosswalked set) is under Compliance; marking a framework in-scope is not a legal determination. A vendor-incident register grades how quickly a vendor notified you against a severity SLA that is a convention, not a legal deadline, and classifies downstream considerations only from explicit signals (our personal data in scope; the org's own DORA-reportable classification). Silence is never a breach. DORA engineering metrics on this product are delivery metrics; they are not a Regulation (EU) 2022/2554 filing. None of those surfaces files a flow-down notice or decides that DORA or CRA applies.
Primary sources (last verified 7 September 2026)
Every operational and regulatory claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2022/2554 Articles 19, 28 and 30 are legal requirements only when DORA applies. Article 19 is major-ICT-related-incident reporting by financial entities to competent authorities. Chapter V (including Article 28 general principles and Article 30 key contractual provisions) is ICT third-party risk management, not a universal vendor-breach statute. Regulation (EU) 2024/2847 Articles 13(5)–(6) and 14 are legal requirements only when CRA applies; Article 14 reporting applies from 11 September 2026. Regulation (EU) 2016/679 Article 33(2) is a processor→controller notification duty only when GDPR applies. NIST SP 800-161 Revision 1 Update 1 (1 November 2024) remains the current C-SCRM practices guide this page cites — guidance, not a statute. ENISA, Good Practices for Supply Chain Cybersecurity (13 June 2023) is an agency report of observed practice, not a law. NIST SP 800-61r2 remains the current final Computer Security Incident Handling Guide this cluster cites for containment then eradication then recovery.
Frequently asked questions
What should we do first after a vendor or dependency is breached?
Intake the vendor notice (who, when UTC, what they claim, what of YOURS they say was in play). Preserve YOUR logs, contracts, and lockfiles. Confirm exposure before you notify anyone. Then map blast radius — which services, environments, and published artifacts consumed the affected vendor or component — and walk contractual versus possible regulatory flow-down duties with counsel. A press article is not exposure. This page does not start a clock. Not legal advice.
Does a vendor breach start a DORA or CRA clock for us?
Not by itself. DORA Article 19 is a financial-entity duty to report major ICT-related incidents; it applies only if DORA applies to YOU and the incident is major for YOU. CRA Article 14 is a manufacturer reporting ladder from 11 September 2026; it applies only if CRA applies to YOU as a manufacturer or in-scope steward of a product with digital elements. Counsel maps applicability. A vendor's incident can still be YOUR report when those tests are met. This page does not apply either instrument and does not start a clock. Not legal advice.
Is a contractual notification the same as a regulatory filing?
No. A DPA or MSA clause that you will tell a customer within a stated number of hours is a contract performance question. A DORA Article 19 report, a CRA Article 14 early warning, and a GDPR Article 33 supervisory-authority notification are regulatory filings to named authorities when those instruments apply. They can all be due on the same facts. Filing one never discharges the others. Counsel reads YOUR paper and YOUR statutes. Not legal advice.
Does ShipReady Metrics file flow-down notices or determine that DORA or CRA applies?
No. The signed-in app does not file a flow-down notice, does not determine that DORA or CRA applies, and does not start a notification clock. Blast-radius search is package exposure over captured dependencies (transitive npm when a lockfile was fetched). Questionnaires draft answers from recorded posture. Compliance → CRA reporting is a ladder from recorded awareness for org-classified CRA-in-scope findings; a named human still submits. The vendor-incident register grades vendor notification latency against a convention SLA and classifies downstream considerations from explicit signals. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from Regulation (EU) 2022/2554, Regulation (EU) 2024/2847, NIST SP 800-161r1-upd1, and ENISA's Good Practices for Supply Chain Cybersecurity. Whether a notification duty has started, whether DORA or CRA applies, and what you may say to customers or authorities are questions for counsel on YOUR facts. This page does not rank vendors and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.