Automotive is one of the few sectors that built its own assurance scheme rather than accepting a general one. If you supply original equipment manufacturers - parts, software, engineering services, tooling, even marketing agencies handling unreleased vehicle imagery - you will eventually be asked for TISAX rather than ISO 27001.
What TISAX is
TISAX is an assessment and exchange mechanism built on the VDA ISA catalogue, a control set derived from ISO 27001 with automotive-specific additions. Two features distinguish it:
- It is an exchange, not a certificate. You are assessed once and receive labels, which you then share with customers through a central platform. That solves the sector's real problem - every OEM auditing every supplier separately.
- Assessments are performed by approved audit providers, and results are recognised across participating companies rather than being one buyer's opinion.
The scope of the ISA catalogue extends beyond information security into prototype protection and data protection, which is why it does not map one-to-one onto a general standard.
Assessment levels and labels
Effort scales sharply with the protection needs of the information you handle:
- AL 1 - self-assessment, rarely sufficient on its own for a customer requirement.
- AL 2 - evidence reviewed by the audit provider, typically with a remote interview. The common level for confidential information.
- AL 3 - on-site assessment with deeper verification. Required for strictly confidential information, high-availability requirements, and most prototype-related work.
Labels then describe what was assessed - information security at a given protection level, prototype protection, or data protection. Customers ask for specific labels, so confirm which ones the customer actually needs before scoping. Buying AL 3 with prototype labels when the customer wanted AL 2 information security is an expensive misunderstanding, and it happens often.
Reuse your control work across schemes
GRC Copilot maps one control set to ISO 27001, TISAX-style requirements and your customers' questionnaires - so a second scheme is a delta, not a restart.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Prototype protection: the genuinely unusual part
This is where organisations with a mature ISMS still fail, because nothing in ISO 27001 prepares you for it. The concern is unreleased vehicles, components and designs leaking before launch - and the requirements are heavily physical:
- Defined secure areas for prototype parts and vehicles, with controlled and logged access.
- Camera and mobile phone restrictions in those areas - enforced, not just stated in a policy.
- Covering and concealment requirements for vehicles and components, including during transport.
- Controls on test drives on public roads, and on events where prototypes are present.
- Rules on photography, and on who may be present - including cleaning staff and contractors.
- Handling of prototype disposal, so parts do not reach scrap dealers intact.
A supplier can hold ISO 27001 and still fail prototype protection outright, because the requirements concern buildings, fences, cameras and people rather than systems. Budget for physical works, not just documentation.
How it relates to what you may already hold
ISO 27001 is a strong foundation - the management system, risk assessment, and most information security controls carry across, and organisations with a mature ISMS typically report the information security portion as manageable. What does not carry across is the prototype protection catalogue, the automotive-specific interpretation of some controls, and the assessment mechanics themselves.
Neither substitutes for the other. If you sell to automotive and to other sectors, you will likely maintain both - which is an argument for a single mapped control set rather than two parallel programmes with separate evidence.
Wider automotive obligations
Security assurance for suppliers sits alongside regulation aimed at vehicles themselves. UNECE regulations require vehicle manufacturers to operate a cybersecurity management system and a software update management system across the vehicle lifecycle, with ISO/SAE 21434 the engineering standard commonly used to demonstrate it. If you supply software or electronic components, expect those obligations to flow down to you contractually - product security engineering requirements, distinct from your corporate ISMS.
The practical consequence: automotive suppliers of software frequently need corporate security assurance (TISAX), product security engineering (21434 flow-down), and often a general certificate for non-automotive customers. Sequence them and share evidence, or the effort compounds.
Frequently asked questions
Do we need TISAX if we have ISO 27001?
Usually yes, if your customer asks for it - most OEMs will not accept ISO 27001 as a substitute. Your ISMS makes the assessment considerably easier.
How long is a label valid?
Typically three years, with re-assessment required after that. Significant changes to scope or locations can require earlier action.
Is TISAX only for German manufacturers?
It originated with the German automotive association but is used widely across the European automotive supply chain and by suppliers worldwide selling into it.
What if we never handle prototypes?
Then prototype protection labels are not in scope - assess for information security at the protection level your customer requires. Confirm the required labels in writing before scoping.
Key takeaways
- TISAX is an exchange of assessment results, not a certificate - customers ask for specific labels.
- Confirm the required label and assessment level before scoping; over-scoping is expensive.
- Prototype protection is physical security work that ISO 27001 does not prepare you for.
- Product security obligations under UNECE and ISO/SAE 21434 flow down separately from your ISMS.