For systems suppliers · Monitoring & incidents
One advisory. Every programme that carries your subsystem.
The investigation happens once, on your platform. Each customer's programme receives it in their own process, against their own clock, with the evidence they asked for.
Your customers keep their own process. Each programme is worked in its own stages, against the criteria that customer declared. Only the platform it runs on is yours.
ISO/SAE 21434 · UNECE R155 / R156 · EU CRA Art. 14 · GB 44495 — your customers' obligations, evidenced by you · Private cloud or on-premise — air-gapped supported.
The multiplier
One advisory. Count the answers.
A subsystem that ships into several programmes turns one advisory into a set of obligations. We do not fill your number in — a figure you compute from your own portfolio is one you will defend in your own budget review.
advisory × programmes carrying the subsystem × vehicle classes × markets = answers owed
See it run
One advisory, across the programmes that carry a subsystem
The film follows one advisory across the programmes that carry a subsystem, recorded on a running build.
Recorded on a running build. No cutaways to a deck.
Pillar 1
Anchor once; see every programme that carries it
The advisory is tied to the subsystem one time. The graph proposes which components carry it; a named person confirms the tie, and the record keeps who confirmed it and when. That confirmation is not repeated per customer.
From the confirmed anchor, the fan-out lists every member project that carries the subsystem — say a passenger-car programme, a heavy-truck programme and a coach programme — as rows of one table, each advancing on its own.
The portfolio view then answers the question your customers ask first: where the exposure actually sits, per programme. One row per project. Not one investigation per row.
Proof on screen
Per project — where the programme's exposure sitsone row per member projectthe relation canvas and the confirmed anchor set
Pillar 2
Your customer's process, running on your platform
Consolidation fails the moment it asks a customer to change how they review. So the model does not ask. When the parent incident is dispatched to a customer programme, the child it creates carries two things: the directive that dispatched it, and the criteria declared at the moment of dispatch.
That is what federated means here: one investigation on your platform, with each customer programme worked in its own child against that customer's own declared stages and criteria. The evidence is produced where the work is done. The expectations it meets are the customer's.
The parent — your platform governance — remains the only gate out. A child advances on its own stages and is judged on its own criteria; the programme decides when the incident is closed.
Proof on screen
Dispatched: <parent>its own stage setthe criteria declared at dispatch
Pillar 3
One vocabulary, every customer
Closure is declared from a fixed set. Three proof-of-remediation modes, chosen before the work starts. Four named endings: fixed, mitigated, deferred, not applicable. The set does not vary by customer, and evidence that does not validate is not stored — it is refused at the door rather than filed and argued about later.
So “mitigated” means one thing across every programme you supply, and an assessor reading two of your customers' records reads the same word with the same meaning. “Deferred” is tagged holding — never an ending — everywhere, so it cannot be an open item in one customer's record and a closed one in another's.
Proof on screen
the proof-of-remediation modesfour named endingsdeferred · holding — never an ending
Pillar 4
One record. Each customer's report is a preset, not a re-cut by hand.
There is one record. It is append-only, and every row carries who wrote it. Reports are generated from that record by audience preset, including a regulator/authority pack for where a customer's filing draws on your evidence. Whoever asks — a programme cybersecurity manager at one customer, homologation support at another — reads a cut of the same rows.
The evidence is not re-cut by hand per customer. Two customers' reports are drawn from the same rows; the difference between them is the preset, not the facts.
Proof on screen
the report generatoraudience preset selectedpressed in the walkthrough
Pillar 5
A refusal that survives someone else's review
When it cannot rate severity, it says so — and that has to hold in a customer's review, not just yours.
Severity comes out of the anchor, not out of a meeting: the confirmed tie between the advisory and the components carrying it is rated on four impact axes, and that rating is the severity.
There is one condition under which no severity is produced: the reachable set rates none of the four axes. Then the product writes down that it did not compute, and writes down what it lacked. No default is substituted in its place.
For an OEM, that abstention has to hold in front of an authority. For you, a programme cybersecurity manager at a company you do not control will read your answer against their template. “Not computed, and here is what was missing” survives that reading. A number that came from a default does not.
Proof on screen
not computed — missing: the reachable set rates no impact axis
Pillar 6
Reuse lives at the organisation, not in a copy-paste
Controls are catalogued once, at organisation level, in the Security Catalog. Policy is scoped in the Policy Manager — globally, or per project where one customer's programme requires a difference from the rest.
The second programme therefore starts from the organisation's library, not from someone's previous export. What the first customer's answer established is what the third starts from — and no copy was made to get it there.
Proof in the walkthrough
the organisation's Security Catalog, opened from the second programmea policy scoped globally, then varied for one projectMulti-stage manufacture
Two manufacturers between your record and the authority
A truck or bus chassis is frequently completed by a body builder or second-stage manufacturer. The cybersecurity evidence for your subsystem is therefore handed through two manufacturers before an authority reads it — and who holds the obligation for the completed vehicle is a live question for the people who buy from you.
That places the Tier-1 in a particular position: your record has to be reusable by a party you have no contract with. It has to be readable without you in the room. A record with a named anchor, a declared ending and per-row authorship is built for that reading. A document assembled for one customer is not.
The body builder who completes the chassis has never opened your platform. They read the record cold: who confirmed the anchor, what severity was computed or why it was not, which ending was declared and by whom.
Bring a multi-stage programme to the walkthrough and we render the record for a reader who was never in the room.
Vehicle classes
…and the obligations differ by class
| Class | Typical framing | What changes for incident response |
|---|---|---|
| M1 passenger cars | Highest volume, shortest cycle | Largest fan-out. Variant and market spread dominates the count of answers owed. |
| M2 / M3 buses and coaches | Passenger-carrying, fleet-operated | Same regulatory framework as M1 — category applicability and timelines to be confirmed per market. The operator is a third party who asks questions; availability pressure is theirs and yours. |
| N1–N3 trucks, LCV to HGV | Long service life, fleet-operated | Longer support obligation — category specifics to be confirmed; telematics and remote-diagnostics exposure; downtime carries a direct revenue cost. |
| O trailers | Routinely forgotten | Addressed where fitted with at least one ECU — weight class and market to be confirmed. Easy to under-declare. |
| Vocational / off-highway | Special bodies, low volume | May sit outside R155 scope. Coverage is not implied; category and market are confirmed before reliance. |
Scope per category is confirmed per market before reliance.
Definition
The model, in plain words
One investigation on your platform; each customer's programme works its own child, in the stages and against the criteria that customer declared. The model describes where the work runs, not whose process it follows — nothing in it asks a customer to adopt yours.
Standards
Standards the record is mapped to
ThreatZ's record is organised against the clauses your customers are held to, and supports the evidence they draw from you. It is not a certification. It does not file anything with any authority — on your behalf or theirs.
- ISO/SAE 21434what the cybersecurity interface agreement asks a supplier to show: which party did what, when, under which declared criteria
- UNECE R155incl. Annex 5 — your customer's CSMS obligation; supports evidence for the monitoring-and-response record they draw from you
- UNECE R156your customer's software-update obligation; supports evidence for the proof of remediation behind an update
- EU CRA Art. 14reporting timelines; supports the evidence behind a clock armed for that instrument, where the instrument applies
- GB 44495the Chinese market requirement; supports evidence for your customer's obligations in that market
Background reading: cybersecurity evidence handover from Tier-2 through Tier-1 to the OEM. Related on this site: SBOM & CVE monitoring · TARA · Pricing.
Deployment & sovereignty
Where the evidence runs
Private cloud or on-premise — air-gapped supported. Your investigation, your customers' child incidents and the record they share run on infrastructure you choose. ThreatZ is listed on AWS Marketplace as a procurement channel; buying there does not change where it deploys.
Runs from your bills of materials — CycloneDX or SPDX — and nothing else. Your source stays with you.
FAQ
Questions asked before the walkthrough
Does consolidating mean telling our customers “use our process”?
No. Each customer programme is a dispatched child of your investigation, and that child carries the directive and the criteria declared at dispatch. It is worked against that customer's stated expectations, in that customer's declared stages. The customer's process is what the child runs; only the platform it runs on is yours.
Where do a customer's stages and criteria come from?
You declare them at dispatch, from what that customer's interface agreement and review template ask for. They are recorded on the child, so the answer is judged against what was declared — not against what someone remembers the customer wanting.
What does each customer receive?
The child incident dispatched for that customer's programme, and the reports rendered from it by audience preset. The parent — your platform governance — stays yours. How each customer reaches their child is shown in the walkthrough.
Is the second customer programme as much work as the first?
The investigation is not repeated; the dispatch is. The anchor is confirmed once. What is done per customer is the child — its stages, its criteria, its severity, and the evidence recorded against them.
Does it need our source code?
No. It consumes bills of materials — CycloneDX or SPDX. Proof of a fix is a bill of materials showing the component moved to a version that clears the finding. Your source never leaves you.
How does this help with a customer's R155 evidence?
It produces the record the customer's type-approval evidence draws on: the confirmed anchor, the computed severity or the recorded abstention, the declared proof of remediation, the named ending. The customer holds the obligation and does the filing. You supply the record they read from.
Do we need a separate licence per customer programme?
Licensing is on the pricing page. How workspaces map to your customer programmes is walked through against your portfolio — bring the count of programmes and classes you carry.
What about trailers and off-highway equipment?
Trailers are addressed where fitted with at least one ECU, with weight class and market to be confirmed. Vocational and off-highway vehicles may sit outside R155 scope, and no coverage is implied. Scope per category is confirmed per market before anyone relies on it.
Where does it deploy?
Private cloud or on-premise — air-gapped supported. AWS Marketplace is a procurement channel only.
Building the vehicle rather than supplying the subsystem? →