Automotive

For workloads run by or for manufacturers, suppliers and engineering partners in the automotive industry, and the teams building for them. The mountain is the same as for everyone; this page maps what this route demands of it, and adds nothing.

The regulatory map

What binds here, and what each regime asks of an architecture.

TISAX. The automotive industry’s mutual assessment for information security, operated by the ENX Association on the industry’s own catalogue, the VDA ISA . It exists because OEMs share prototypes, designs and launch plans with their suppliers, and it is contractually required before that sharing happens: without the label at the demanded level, the collaboration does not start. Its subject is protection of partner data, which lands on SEC 3 (classification with defined levels), SEC 2 (isolation of one partner’s data from another’s) and the evidence to prove both, SOV 7.

The software supply chain is a type-approval matter. The UNECE vehicle regulations on cyber security and software update management, R155 and R156, tie a manufacturer’s type approval to a managed cyber security and update system across the vehicle’s lifecycle. The UNECE vehicle-regulations pages carry the texts, without stable deep links, and every OEM’s homologation function works from them. For a cloud workload feeding development or updates, the consequence is architectural: provenance, scanning and a tamper-evident path from source to artefact, which is SEC 10 end to end.

Trade secrets rather than statutes. Unlike the public sector or healthcare, almost nothing here fixes where data must live. What binds is contract: confidentiality levels per project, per-partner isolation requirements, and audit rights. It is Tier 2’s description almost word for word.

The tier default

Tier 2, sovereignty-preferred. No statute forces residency. What the criteria describe is elevated protection need with severe competitive damage on compromise: a leaked prototype is a market event, not a fine.

Per data set, SOV 1.3, the tier moves in both directions: a project under a contract that names jurisdictions or forbids specific providers is a Tier 1 conversation, and public marketing assets sit at Tier 3. The reasoning is recorded either way, SOV 1.2.

The pillar weighting

Two pillars shift strongly; each shift traces to the map.

Security leads, classification-first and partner-shaped. TISAX’s levels are a classification scheme the customer arrives with: SEC 3 maps it onto data sets and their copies, SEC 2 carries the per-partner isolation that the assessment audits, and identity, secrets and entitlement hygiene (SEC 4, SEC 9, SEC 5.4) are the mechanics those boundaries stand on. The supply chain questions (SEC 10) carry the type-approval half.

Sovereignty & Compliance is elevated on evidence and custody. Not residency but proof: who can technically decrypt a partner’s data (SOV 4.1 beside SEC 7.3), which parties process it (SOV 6.1), and the records an assessment or a partner audit consumes (SOV 7).

Reliability, Operational Excellence, Performance Efficiency, Cost Optimization and Sustainability do not shift. A development platform wants the ordinary treatment; what is extraordinary here is whose data it holds.

The statement core

What an assessment of an automotive workload accounts for regardless of where the conversation went: each of these ends evidenced or in the risk register.

Security

Swipe sideways to see the whole table

Statement	What makes it mandatory here
SEC 2.1	Isolation strength per partner and project is chosen from the contract, not defaulted
SEC 2.3	Environment separation is what keeps a prototype out of a test system’s reach
SEC 3.1	The TISAX levels are a classification waiting to be mapped onto data sets
SEC 3.2	Controls that follow classification mechanically are what the assessment audits
SEC 3.3	Copies of partner data, caches and exports included, inherit its level
SEC 4.2	Workload identities per system keep one partner’s pipeline out of another’s data
SEC 4.3	Credentials that expire are the difference between offboarding and hoping
SEC 5.4	Entitlement review against intent is a standing partner-audit expectation
SEC 9.1	Secrets in a purpose-built store, because a leaked token is a leaked project
SEC 9.3	Rotation on schedule and on suspicion, for the same reason
SEC 10.1	Knowing what artefacts are built from is where the update regime starts
SEC 10.2	Continuous scanning, because the vehicle lifecycle outlives the build
SEC 10.3	Controlled sources for images and dependencies, or provenance is theatre
SEC 10.4	A tamper-evident path from source to production is the type-approval expectation
SEC 11.1	Detecting exfiltration of partner data needs records the actor cannot alter

Sovereignty & Compliance

Swipe sideways to see the whole table

Statement	What makes it mandatory here
SOV 4.1	Who can technically decrypt a partner’s data is the custody question contracts ask
SOV 6.1	The processing chain for partner data is what a partner audit walks first
SOV 7.1	TISAX and partner audits consume recorded actions, not assurances
SOV 7.2	Records alterable by the recorded party prove nothing to an assessor
SOV 10.2	Portable formats keep a project movable when a partnership ends

Outside this page

The vehicle itself. Type approval, the vehicle’s on-board systems and the update system as homologated belong to the manufacturer’s engineering and homologation functions. This page maps the cloud workloads that feed them, not the vehicle.

TISAX scoping and labels. Which sites, which assessment level and which label a company needs is between it, its partners and its assessor. The page maps what the architecture must evidence once the level is set.

Related

• Security: the pillar the label stands on
• Sovereignty & Compliance: custody and evidence