---
type: industry
vertical: automotive
title: Automotive
description: "The framework read for automotive: TISAX as the ticket into OEM collaboration, the software supply chain as a type-approval matter, and Tier 2 as the default."
status: draft
sidebar:
order: 50
label: Automotive
source_url: "https://framework.stackit.cloud/architecture/industries/automotive/"
source_file: "docs/architecture/industries/automotive.mdx"
---
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`](/architecture/pillars/security/sec-03-data-classification/)
(classification with defined levels), [`SEC 2`](/architecture/pillars/security/sec-02-segmentation/) (isolation of one partner's data from another's)
and the evidence to prove both, [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/).
**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`](/architecture/pillars/security/sec-10-supply-chain/) 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`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-13-classify-per-data-set-because-a-workload-rarely-sits-at-one-tier), 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`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-12-record-the-reasoning-rather-than-only-the-result).
## 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`](/architecture/pillars/security/sec-03-data-classification/) maps it onto data sets and their copies, [`SEC 2`](/architecture/pillars/security/sec-02-segmentation/)
carries the per-partner isolation that the assessment audits, and identity, secrets and
entitlement hygiene ([`SEC 4`](/architecture/pillars/security/sec-04-identity/), [`SEC 9`](/architecture/pillars/security/sec-09-secrets/), [`SEC 5.4`](/architecture/pillars/security/sec-05-least-privilege/#sec-54-review-actual-entitlements-against-intended-ones-on-a-cadence)) are the mechanics those boundaries stand on.
The supply chain questions ([`SEC 10`](/architecture/pillars/security/sec-10-supply-chain/)) 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`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-41-establish-per-data-set-who-is-technically-able-to-decrypt) beside [`SEC 7.3`](/architecture/pillars/security/sec-07-encryption/#sec-73-decide-who-is-technically-able-to-decrypt-per-data-set)), which parties process it
([`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data)), and the records an assessment or a partner audit consumes ([`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/)).
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
| Statement | What makes it mandatory here |
|---|---|
| [`SEC 2.1`](/architecture/pillars/security/sec-02-segmentation/#sec-21-choose-the-isolation-strength-from-the-protection-need-not-from-a-default) | Isolation strength per partner and project is chosen from the contract, not defaulted |
| [`SEC 2.3`](/architecture/pillars/security/sec-02-segmentation/#sec-23-separate-environments-and-be-explicit-about-what-the-separation-rests-on) | Environment separation is what keeps a prototype out of a test system's reach |
| [`SEC 3.1`](/architecture/pillars/security/sec-03-data-classification/#sec-31-classify-every-data-set-before-deciding-where-it-lives) | The TISAX levels are a classification waiting to be mapped onto data sets |
| [`SEC 3.2`](/architecture/pillars/security/sec-03-data-classification/#sec-32-let-the-classification-drive-the-controls-mechanically) | Controls that follow classification mechanically are what the assessment audits |
| [`SEC 3.3`](/architecture/pillars/security/sec-03-data-classification/#sec-33-find-the-copies-telemetry-backups-caches-test-data-and-exports) | Copies of partner data, caches and exports included, inherit its level |
| [`SEC 4.2`](/architecture/pillars/security/sec-04-identity/#sec-42-give-workloads-their-own-identities-rather-than-sharing-human-credentials) | Workload identities per system keep one partner's pipeline out of another's data |
| [`SEC 4.3`](/architecture/pillars/security/sec-04-identity/#sec-43-set-an-expiry-on-every-credential-because-the-default-is-permanent) | Credentials that expire are the difference between offboarding and hoping |
| [`SEC 5.4`](/architecture/pillars/security/sec-05-least-privilege/#sec-54-review-actual-entitlements-against-intended-ones-on-a-cadence) | Entitlement review against intent is a standing partner-audit expectation |
| [`SEC 9.1`](/architecture/pillars/security/sec-09-secrets/#sec-91-keep-secrets-in-a-purpose-built-store-never-in-code-or-images) | Secrets in a purpose-built store, because a leaked token is a leaked project |
| [`SEC 9.3`](/architecture/pillars/security/sec-09-secrets/#sec-93-rotate-on-a-schedule-and-after-any-suspected-exposure) | Rotation on schedule and on suspicion, for the same reason |
| [`SEC 10.1`](/architecture/pillars/security/sec-10-supply-chain/#sec-101-know-what-your-artefacts-are-built-from) | Knowing what artefacts are built from is where the update regime starts |
| [`SEC 10.2`](/architecture/pillars/security/sec-10-supply-chain/#sec-102-scan-continuously-rather-than-only-at-build-time) | Continuous scanning, because the vehicle lifecycle outlives the build |
| [`SEC 10.3`](/architecture/pillars/security/sec-10-supply-chain/#sec-103-control-where-base-images-and-dependencies-come-from) | Controlled sources for images and dependencies, or provenance is theatre |
| [`SEC 10.4`](/architecture/pillars/security/sec-10-supply-chain/#sec-104-make-the-path-from-source-to-production-tamper-evident) | A tamper-evident path from source to production is the type-approval expectation |
| [`SEC 11.1`](/architecture/pillars/security/sec-11-detection-and-response/#sec-111-collect-security-relevant-signals-where-the-subject-cannot-alter-them) | Detecting exfiltration of partner data needs records the actor cannot alter |
### Sovereignty & Compliance
| Statement | What makes it mandatory here |
|---|---|
| [`SOV 4.1`](/architecture/pillars/sovereignty/sov-04-key-ownership/#sov-41-establish-per-data-set-who-is-technically-able-to-decrypt) | Who can technically decrypt a partner's data is the custody question contracts ask |
| [`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data) | The processing chain for partner data is what a partner audit walks first |
| [`SOV 7.1`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-71-record-the-actions-an-auditor-or-investigator-will-ask-about) | TISAX and partner audits consume recorded actions, not assurances |
| [`SOV 7.2`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-72-protect-records-against-modification-by-the-parties-they-record) | Records alterable by the recorded party prove nothing to an assessor |
| [`SOV 10.2`](/architecture/pillars/sovereignty/sov-10-open-interfaces/#sov-102-keep-data-in-portable-formats-and-know-how-to-get-it-out) | 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](/architecture/pillars/security/): the pillar the label stands on
- [Sovereignty & Compliance](/architecture/pillars/sovereignty/): custody and evidence