Introduction: Why TISAX Matters for the Automotive Supply Chain
TISAX (Trusted Information Security Assessment Exchange) is the mechanism by which the automotive industry assures itself that information shared across its supply chain is protected to a common, mutually recognised standard. Governed by the ENX Association on behalf of the German Association of the Automotive Industry (VDA), TISAX allows a supplier to be assessed once and to share that assessment result with multiple original equipment manufacturers (OEMs) and tier-N partners, rather than undergoing a separate audit for each customer. For any organisation that designs, develops, manufactures, tests, transports or otherwise handles automotive information assets, prototypes, or personal data on behalf of a vehicle manufacturer, TISAX has become a de facto entry ticket to doing business.
This guide is written from the perspective of practising information security auditors and assessors who prepare organisations for TISAX. It walks through what TISAX is, who must comply, the structure of the underlying assessment catalogue (the VDA Information Security Assessment, or VDA ISA), a master control-by-control readiness checklist, scoping considerations, a phased implementation programme, the maturity scoring model, the assessment lifecycle, evidence expectations, roles, KPIs, common gaps and mappings to adjacent frameworks such as ISO/IEC 27001. The objective is to give a security, risk or compliance leader a defensible, auditor-grade roadmap to a successful TISAX label.
What is TISAX?
TISAX is not a certifiable standard in the way ISO/IEC 27001 is; rather, it is an assessment and exchange framework. It comprises three tightly coupled elements: the assessment catalogue (VDA ISA), the assessment procedure (defined by ENX in the TISAX assessment requirements and Participant Handbook), and the exchange platform (the ENX TISAX portal on which results, called labels, are shared under participant control). An organisation registers as a TISAX participant, defines its assessment scope and objectives, engages an ENX-approved audit provider, undergoes the assessment, and — on success — receives one or more TISAX labels that it can selectively share with its customers.
The substantive content is carried by the VDA ISA (Information Security Assessment), a spreadsheet-based catalogue of controls organised into criteria groups. The current generation, VDA ISA 6.x, structures its controls across three modules: Information Security, Prototype Protection, and Data Protection. Each control is expressed as a requirement with a maturity target, and the assessment measures the organisation's implemented maturity against that target on a defined scale.
A crucial concept is the assessment objective. Unlike a single certificate, TISAX lets a participant select assessment objectives that match the sensitivity of the information it handles — for example, high or very high protection needs for confidentiality and availability, protection of prototypes, connection to third parties, or handling of personal data. Each objective maps to a defined subset of the VDA ISA controls and to a required assessment level (AL 2 or AL 3), which in turn dictates the depth and rigour of the audit.
Who Must Comply with TISAX?
TISAX applies to any organisation in the automotive value chain that a customer OEM or tier supplier requires to demonstrate a defined level of information security. Compliance is contractual rather than statutory: the obligation flows down from purchasing terms and supplier onboarding requirements. In practice the population is broad.
| Organisation type | Why TISAX typically applies |
|---|---|
| Vehicle OEMs | Set the requirement for their supply base and often hold labels themselves for internal and joint-venture assurance |
| Tier 1 / Tier 2 component suppliers | Handle design data, specifications and often prototype parts; label demanded as a purchasing precondition |
| Engineering service providers (ESPs) | Develop or test vehicle components, software or systems using confidential OEM data |
| Software and embedded / ECU developers | Access source code, calibration data and connected-vehicle information |
| Prototype and tooling manufacturers | Physically hold protected prototypes and pre-series parts (Prototype Protection objective) |
| Testing, validation and homologation labs | Operate proving grounds, camouflaged vehicle testing and secure test benches |
| Design, styling and clay-model studios | Handle unreleased styling and design information of very high sensitivity |
| Logistics and transport providers | Move prototypes and confidential materials; may need prototype and confidentiality objectives |
| Marketing, media and event agencies | Receive pre-launch imagery, film footage and product information under embargo |
| IT / cloud / managed service providers | Process or store automotive customer data; may need the data-connection objective |
| Providers processing personal data | Handle employee, customer or connected-vehicle personal data (Data Protection module) |
- The trigger is almost always a customer contract clause or supplier portal requirement specifying a TISAX label at a stated assessment level and objective.
- An organisation may need multiple labels covering different sites or different objectives (for example, high protection plus prototype protection).
- Sub-suppliers frequently inherit the requirement: an OEM's tier 1 will flow TISAX down to its own critical tier 2 suppliers.
- There is no legal exemption; the only way to avoid TISAX is to not handle protected automotive information for a customer that requires it.
Structure of TISAX: Modules, Criteria and the VDA ISA Catalogue
The assessment content is defined by the VDA ISA. In the 6.x generation the catalogue is divided into three modules, each a worksheet of numbered controls. The Information Security module is mandatory for every assessment; the Prototype Protection and Data Protection modules apply only when the corresponding assessment objective is in scope. Within the Information Security module, controls are grouped into seven control domains (chapters). Each control has a unique identifier, a control question, an objective, and — for many — must, should and high/very-high requirement tiers.
| Module / domain | Scope of content | Applies when |
|---|---|---|
| 1. IS Policies and Organisation | Governance, ISMS scope, roles, risk management, asset and project security, supplier and external-party management | Always (Information Security module) |
| 2. Human Resources | Personnel screening, awareness, training, confidentiality obligations, teleworking | Always |
| 3. Physical Security and Business Continuity | Security zones, access control to premises, equipment protection, BCM and redundancy | Always |
| 4. Identity and Access Management | Identity lifecycle, authentication, privileged access, access rights review | Always |
| 5. IT Security / Cyber Security | Cryptography, operations security, malware, logging, vulnerability and change management, network segmentation, secure development | Always |
| 6. Supplier Relationships | Security requirements in the supply chain, service delivery, cloud services | Always |
| 7. Compliance | Legal and regulatory compliance, protection of records, information security reviews and audit | Always |
| Prototype Protection | Physical and organisational protection of prototypes, test vehicles and pre-series parts, plus event and film-shoot security | Prototype objective selected |
| Data Protection | Controls derived from GDPR Article 28 for order-processing (processor) obligations | Data protection objective selected |
The maturity of each control is rated on a six-point capability scale (levels 0 to 5) drawn from the ISA methodology. Assessment objectives translate into required maturity targets — typically an average target of 3 (established/managed) across applicable controls, with must-requirements fully met. The higher the protection need, the more controls are activated and the deeper the evidence expected.
Master Assessment Checklist: Control-by-Control Readiness
This is the operational heart of TISAX preparation. Below, each VDA ISA control domain is expanded with the specific requirement areas an assessor will examine, what to verify for each, and the typical evidence expected. Organisations should treat every row as a discrete readiness item and confirm both design (documented) and operating effectiveness (demonstrated over time). No control area is omitted; the Prototype Protection and Data Protection modules are included for organisations that select those objectives.
Domain 1 — Information Security Policies and Organisation
| What to verify | Typical evidence |
|---|---|
| An information security policy is defined, approved by top management, published and communicated | Signed IS policy, approval record, intranet/communication log |
| Information security roles and responsibilities are defined and allocated, including a responsible security officer (ISO/CISO) | Org chart, role descriptions, ISO appointment letter, RACI |
| An ISMS scope is defined with clear boundaries covering the assessment scope locations | ISMS scope statement, site list, scope diagram |
| A risk assessment methodology exists and information security risks are identified, evaluated and treated | Risk methodology, risk register, risk treatment plan, management sign-off |
| Assets are inventoried, owned and classified according to protection needs | Asset inventory, classification scheme, information classification policy |
| Information security is addressed within projects from initiation | Project security checklist, sample project security assessment |
| Segregation of duties and conflicting responsibilities are managed | SoD matrix, access provisioning approvals |
| Contact with authorities and special interest groups is maintained | CERT membership, authority contact list, incident escalation contacts |
| Management reviews the ISMS at planned intervals and drives continual improvement | Management review minutes, improvement actions, KPI reports |
Domain 2 — Human Resources Security
| What to verify | Typical evidence |
|---|---|
| Background verification is performed for personnel commensurate with role sensitivity and law | Screening policy, sample screening records, HR procedure |
| Confidentiality / non-disclosure obligations are agreed with employees and contractors | Signed NDAs, employment contract clauses, contractor agreements |
| Employees receive information security awareness training and role-specific education | Training plan, attendance records, e-learning completion reports |
| Terms and conditions of employment reference security responsibilities | Employment contract templates, acceptable use policy acknowledgements |
| A disciplinary process exists for security breaches | Disciplinary policy, HR sanction procedure |
| Joiner-mover-leaver process ensures timely change and return of assets and revocation of access | JML procedure, asset return checklist, offboarding tickets |
| Teleworking and mobile working are governed by policy and technical controls | Remote working policy, VPN/endpoint config standards |
Domain 3 — Physical Security and Business Continuity
| What to verify | Typical evidence |
|---|---|
| Physical security perimeters and zones are defined based on protection need | Site zoning plan, security concept, floor plans |
| Physical entry controls restrict access to authorised persons | Access control system logs, badge management records, visitor log |
| Offices, rooms and secure areas (e.g. server rooms, prototype areas) are protected | Room access lists, CCTV coverage map, lock/alarm records |
| Delivery, loading and public-access areas are controlled | Goods-in procedure, segregation of delivery zones |
| Equipment is sited, protected and maintained; power and cabling secured | Maintenance records, UPS/generator tests, cabling standards |
| Secure disposal and reuse of equipment and media is enforced | Media sanitisation records, certificates of destruction |
| Clear desk and clear screen policy is implemented | Clear desk policy, walkthrough observation, screen-lock GPO |
| Business continuity and redundancy for information processing are planned and tested | BCM policy, BIA, continuity plans, DR test reports |
Domain 4 — Identity and Access Management
| What to verify | Typical evidence |
|---|---|
| A formal identity lifecycle governs creation, change and removal of user identities | IAM policy, provisioning workflow, identity source of truth |
| Access to information and systems is granted on least-privilege and need-to-know | Access request/approval records, role-based access model |
| Authentication mechanisms are appropriate to risk; MFA for remote and privileged access | Authentication policy, MFA configuration, VPN/SSO settings |
| Password and secret management enforce strength and confidentiality | Password policy, password manager/vault, key handling procedure |
| Privileged and administrative access is restricted, logged and reviewed | Privileged account inventory, PAM logs, admin approval records |
| Access rights are reviewed at planned intervals and on role change | Access recertification reports, review sign-offs |
| User authentication information (credentials) is protected in storage and transit | Hashing/encryption config, secrets store evidence |
| Access to source code and development environments is controlled | Repository access matrix, branch protection settings |
Domain 5 — IT / Cyber Security (Operations, Cryptography, Development)
| What to verify | Typical evidence |
|---|---|
| A cryptography policy defines algorithms, key strength and key management | Crypto policy, approved cipher list, key management procedure |
| Keys are generated, stored, rotated and revoked under controlled processes | Key inventory, KMS/HSM records, rotation logs |
| Documented operating procedures exist for information processing facilities | Runbooks, SOPs, configuration baselines |
| Change management controls changes to systems and applications | Change policy, change tickets, CAB approvals |
| Capacity is monitored and managed | Capacity reports, monitoring dashboards |
| Development, test and production environments are separated | Environment topology, deployment pipeline segregation |
| Protection against malware is deployed and kept current | EDR/AV coverage report, signature/update status |
| Backups are performed, protected and restore-tested | Backup policy, backup job logs, restore test evidence |
| Event logging captures user, admin and security events; logs are protected | Logging standard, SIEM ingestion list, log retention config |
| Clock synchronisation is enforced | NTP configuration evidence |
| Technical vulnerabilities are identified, assessed and remediated (patch management) | Vulnerability scan reports, patch SLAs, remediation tickets |
| Networks are segmented and controlled; external connections secured | Network diagram, firewall rulebase, segmentation evidence |
| Secure development and system acquisition practices are applied | Secure SDLC policy, code review records, SAST/DAST reports |
| Test data is protected and production data is not used insecurely in test | Test data management procedure, masking/anonymisation evidence |
| Information transfer (email, file exchange, portals) is protected | Encryption in transit config, secure file-transfer procedure |
Domain 6 — Supplier Relationships (Supply Chain Security)
| What to verify | Typical evidence |
|---|---|
| Information security requirements are agreed with suppliers who access, process or store data | Supplier security clauses, onboarding questionnaire, contracts |
| Supplier risk is assessed before and during the relationship | Supplier risk assessments, tiering criteria |
| Security requirements are flowed down to sub-suppliers in the ICT supply chain | Flow-down clauses, sub-processor register |
| Supplier service delivery is monitored and reviewed | Service reviews, SLA reports, audit rights exercised |
| Changes to supplier services are managed with security in mind | Supplier change records |
| Cloud service use is governed, including data location and shared-responsibility | Cloud policy, provider due-diligence, configuration evidence |
Domain 7 — Compliance
| What to verify | Typical evidence |
|---|---|
| Applicable legal, regulatory and contractual requirements are identified and documented | Legal register, compliance obligations list |
| Intellectual property rights and licensing are respected | IP policy, software licence inventory |
| Records are protected against loss, destruction and falsification per retention needs | Records retention schedule, protected storage evidence |
| Privacy and protection of personal data comply with applicable law | Data protection policy, records of processing |
| Information security is independently reviewed at planned intervals | Internal audit plan, audit reports, corrective actions |
| Technical compliance with policies and standards is checked | Configuration audit reports, hardening compliance scans |
Prototype Protection Module (when Prototype objective is in scope)
| What to verify | Typical evidence |
|---|---|
| Organisational requirements for prototype protection are defined (security concept, responsibilities) | Prototype security concept, roles, classification of prototypes |
| Physical and environmental security of prototype areas, buildings and premises is enforced | Zoning, fencing, access control, CCTV, alarm evidence for prototype zones |
| Access to prototypes and secure areas is need-to-know and logged | Prototype area access lists, visitor escorting records |
| Camouflage, covering and concealment measures protect vehicles in transit and testing | Camouflage procedure, covered-transport evidence |
| Requirements for handling test and trial vehicles on public and private roads are met | Test-drive authorisation, driver briefing, route control |
| Events and film/photo shoots involving prototypes are secured | Event security plan, confidentiality briefings, device controls |
| Third parties handling prototypes meet equivalent protection requirements | Sub-supplier prototype agreements, audits |
Data Protection Module (when Data Protection objective is in scope)
| What to verify | Typical evidence |
|---|---|
| Order-processing (processor) obligations under GDPR Article 28 are implemented | Data processing agreements, processing instructions |
| A record of processing activities is maintained | RoPA / processing register |
| Technical and organisational measures (TOMs) protect personal data | TOM documentation, encryption/pseudonymisation evidence |
| Data subject rights and controller instructions are supported | DSR procedure, instruction handling records |
| Sub-processor engagement is authorised and controlled | Sub-processor list, authorisation records |
| Personal data breaches are detected and reported to the controller | Breach procedure, notification templates, timelines |
| Cross-border transfers use valid safeguards | Transfer mechanism evidence (SCCs), transfer impact notes |
Scoping the TISAX Assessment
Scoping in TISAX has a specific, portal-driven meaning. The participant defines a scope that determines which locations, processes and organisational units are covered by the label. ENX provides a standard scope definition (the default wording that most OEMs accept) and allows extended or custom scopes where needed. Getting scope right is the single most consequential early decision, because a label only covers what the scope describes.
- Standard scope: the ENX-defined boilerplate that covers all processes handling the participant's own and its customers' information security requirements at the listed locations — the most widely accepted option.
- Extended / custom scope: used where an organisation wants to narrow or specifically describe coverage; may reduce acceptance by some customers and requires careful justification.
- Locations: every physical site that handles in-scope information must be listed; multi-site organisations may use a group assessment with sampling.
- Assessment objectives: select all that apply — for example high or very high need for confidentiality/availability, prototype protection, data connection to third parties, and data protection — as these drive the applicable controls and assessment level.
- Assessment level (AL 2 or AL 3): determined by protection need; AL 3 requires on-site assessment and evidence inspection, AL 2 permits a plausibility-based (often remote) approach.
- Exclusions: any excluded process, system or location must be explicitly stated and justified; unstated exclusions invalidate the assurance.
Implementation Approach: A Phased Programme
A structured, phased approach de-risks TISAX and typically spans three to nine months depending on maturity and scope. The following five phases move an organisation from registration to label award and ongoing maintenance.
Phase 1 — Initiation and Registration
- Activities: confirm customer requirements (objective + level), register on the ENX TISAX portal, obtain the participant ID, define the scope and locations, appoint a programme sponsor and project lead, and acquire the current VDA ISA workbook.
- Deliverables: TISAX participant registration, agreed scope statement, selected assessment objectives and level, project charter and plan.
Phase 2 — Gap Assessment (Self-Assessment)
- Activities: complete the VDA ISA self-assessment, rating current maturity of every applicable control; identify gaps against target maturity; produce a prioritised remediation backlog and risk-based roadmap.
- Deliverables: completed VDA ISA self-assessment workbook, gap analysis report, remediation plan with owners and dates, indicative budget.
Phase 3 — Remediation and ISMS Build
- Activities: implement or uplift policies, procedures and technical controls; establish or align the ISMS; deploy IAM, logging, backup, vulnerability and change processes; run awareness training; execute prototype/data-protection specific controls where applicable.
- Deliverables: approved policy set, operating procedures, configured technical controls, training completion records, updated risk register and Statement of Applicability-equivalent.
Phase 4 — Internal Validation and Evidence Preparation
- Activities: run an internal audit/mock assessment, verify operating effectiveness over a sufficient window, collate the evidence library indexed to each control, remediate residual findings, and re-score the self-assessment.
- Deliverables: internal audit report, evidence index/library, closed corrective actions, assessment-ready self-assessment reaching target maturity.
Phase 5 — Formal Assessment and Label Award
- Activities: engage an ENX-approved audit provider, undergo the initial assessment (remote and/or on-site per AL), address any minor/major non-conformities within the corrective-action window, and receive the TISAX label; then share it selectively with customers.
- Deliverables: assessment report, corrective action plan (if required), TISAX label(s) published on the portal, customer sharing configured, surveillance/maintenance plan.
Maturity and Scoring Model
The VDA ISA rates each control on a six-level capability maturity scale adapted from established process-maturity models. The assessment compares the achieved maturity of each control against the target maturity for the selected objective (commonly a target level of 3). A weighted result must meet or exceed the target, with all must-requirements satisfied, for the label to be granted.
| Level | Name | Meaning for the assessor |
|---|---|---|
| 0 | Incomplete | The control is not implemented or does not achieve its purpose; a partial or non-existent process. |
| 1 | Performed | The control is performed but ad hoc and undocumented; results depend on individuals. |
| 2 | Managed | The control is performed and managed (planned, monitored) but not fully standardised across the organisation. |
| 3 | Established | The control follows a defined, documented standard process and is consistently applied — the usual target. |
| 4 | Predictable | The control operates within defined quantitative limits and its performance is measured and predictable. |
| 5 | Optimising | The control is continually improved using metrics and change management; best-in-class. |
For most TISAX objectives the aggregate target is level 3, meaning controls must be defined, documented and consistently applied. Higher protection needs (very high) and certain critical controls may attract stricter expectations. Deviations below target on individual controls are recorded as findings; must-requirement failures generally block the label until corrected.
Assessment and Audit Approach
The TISAX assessment lifecycle is defined by ENX and executed by an approved audit provider. The steps below describe a typical initial assessment through to label maintenance.
- Register on the ENX TISAX portal, define scope, objectives and assessment level, and obtain the participant/scope IDs.
- Complete and submit the VDA ISA self-assessment to the required target maturity.
- Select and contract an ENX-approved TISAX audit provider (the participant chooses and pays the provider directly).
- Undergo the initial assessment: for AL 2, largely evidence-based and often remote; for AL 3, on-site inspection, interviews and control walkthroughs.
- Receive the assessment result: if requirements are met, a temporary label may be issued pending final report; if minor or major non-conformities exist, they enter a corrective-action plan.
- Implement corrective actions within the defined window (typically up to nine months for the plan) and undergo a follow-up review where required.
- On successful closure, the audit provider confirms results and the participant is issued the TISAX label(s) with a three-year validity.
- Share the label selectively with customers via the ENX portal; only recipients you authorise can view your result.
- Maintain the ISMS through the validity period; significant scope changes, new locations or higher objectives trigger re-assessment before expiry.
- Plan re-assessment ahead of the three-year expiry to maintain continuous label coverage.
Evidence Request List
Assessors expect a curated evidence library indexed to each VDA ISA control. The categorised list below reflects what is typically requested. Provide both documented design and records demonstrating operating effectiveness over a representative period.
- Governance: IS policy, ISMS scope, roles/RACI, ISO appointment, management review minutes, risk methodology, risk register and treatment plan.
- Asset and classification: asset inventory, information classification scheme and handling rules, data flow/scope diagrams.
- HR security: screening records, NDAs, training plans and completion reports, JML procedure and sample tickets, disciplinary policy.
- Physical and BCM: site zoning plans, access-control and visitor logs, CCTV coverage, maintenance/UPS test records, BIA, continuity and DR test reports.
- Identity and access: IAM policy, provisioning/approval records, MFA configuration, privileged-access inventory and logs, access recertification reports.
- IT/cyber operations: cryptography and key-management records, change tickets and CAB minutes, backup and restore-test logs, SIEM/log configuration and retention, malware/EDR coverage, vulnerability scans and patch SLAs, network diagrams and firewall rulebase.
- Secure development: secure SDLC policy, code review records, SAST/DAST reports, environment segregation and repository access matrix, test-data management.
- Supplier and cloud: supplier security clauses, risk assessments, sub-processor register, service reviews, cloud due-diligence and configuration.
- Compliance: legal/regulatory register, records retention schedule, internal audit plan and reports, corrective-action tracker.
- Prototype (if in scope): prototype security concept, area access logs, camouflage/covered-transport records, event and test-drive security plans.
- Data protection (if in scope): DPAs, RoPA, TOM documentation, DSR and breach procedures, sub-processor authorisations, transfer safeguards.
Roles and Responsibilities
| Role | Key TISAX responsibilities |
|---|---|
| Executive sponsor / top management | Approve scope and budget, endorse the IS policy, chair management reviews, own residual risk |
| Information Security Officer / CISO | Own the ISMS, drive remediation, coordinate the assessment, maintain the evidence library |
| TISAX project lead | Run the programme plan, manage the portal registration, liaise with the audit provider |
| IT / infrastructure teams | Implement and evidence technical controls (IAM, logging, backup, network, endpoints) |
| Application / development teams | Deliver secure SDLC, code review, environment segregation and test-data protection |
| HR | Screening, NDAs, awareness training, JML process, disciplinary handling |
| Facilities / physical security | Zoning, access control, CCTV, prototype-area protection, visitor management |
| Data protection officer / privacy | Data Protection module controls, DPAs, RoPA, breach and DSR handling |
| Procurement / vendor management | Supplier security clauses, flow-down, risk assessment and reviews |
| Internal audit | Independent internal review, mock assessment, corrective-action verification |
| Control owners | Maintain assigned controls at target maturity and supply evidence |
KPIs to Track
- Percentage of applicable VDA ISA controls meeting target maturity (level 3 or above).
- Number and severity of open non-conformities and days to closure against the corrective-action window.
- Security awareness training completion rate and phishing-simulation failure rate.
- Mean time to detect and mean time to remediate security incidents.
- Patch and vulnerability remediation within SLA (critical/high percentage closed on time).
- Access recertification completion rate and count of orphaned or excessive-privilege accounts.
- Backup success rate and restore-test pass rate.
- Supplier assessments completed versus in-scope suppliers, and flow-down coverage.
- Percentage of assets inventoried and classified.
- Days remaining to label expiry and re-assessment readiness status.
- For prototype scope: prototype-area access violations and camouflage/transport compliance.
- For data protection scope: breach notification timeliness and DSR response within statutory deadlines.
Readiness Checklist
- Customer-required assessment objective(s) and level (AL 2 / AL 3) confirmed against contract
- Registered on the ENX TISAX portal with participant ID and defined scope
- Current VDA ISA workbook obtained and self-assessment completed
- IS policy approved by top management and communicated
- ISMS scope, roles and responsibilities defined and allocated
- Risk assessment performed with a treatment plan endorsed by management
- Asset inventory and information classification in place
- HR controls (screening, NDAs, training, JML) operating and evidenced
- Physical and prototype-area protections implemented where in scope
- IAM with least-privilege, MFA and periodic access reviews operating
- Logging, backup/restore-testing, malware, vulnerability and change management operating
- Network segmentation and secure development practices in place
- Supplier security requirements agreed and flowed down
- Data protection module controls implemented where in scope
- Internal audit / mock assessment completed and findings closed
- Evidence library indexed to every applicable control and demonstrating operating effectiveness
- ENX-approved audit provider engaged and assessment scheduled
- Corrective-action and label-maintenance/re-assessment plan established
Common Gaps Auditors Find
- Scope and objective mismatch: the registered objective/level does not match what the customer actually requires, so the label is rejected.
- Documentation without operating evidence: policies exist but records showing consistent operation over time are missing, capping maturity below level 3.
- Weak access reviews: no periodic recertification, orphaned accounts and unmanaged privileged access.
- Immature supplier management: no flow-down of security requirements and no evidence of supplier risk assessment or review.
- Backup restores never tested: backups run but no restore evidence, so continuity claims are unproven.
- Incomplete asset and classification coverage: shadow IT and unclassified information undermine the whole control set.
- Logging without monitoring: events are collected but not reviewed, and retention is undefined.
- Prototype protection treated too lightly: physical, transport, camouflage and event controls under-specified relative to the objective.
- Data protection module underestimated: DPAs, RoPA and TOMs incomplete when the data-protection objective is selected.
- No independent internal audit before the formal assessment, so findings surface late and costly.
- Vulnerability and patch SLAs undefined or unmet, with no evidence of timely remediation.
TISAX Mapped to Other Frameworks
TISAX and the VDA ISA are heavily aligned with ISO/IEC 27001 and its control set, which makes an existing ISO 27001 ISMS a strong foundation. The mapping below orients teams that hold other certifications; note that alignment is conceptual and does not replace the VDA ISA's automotive-specific and prototype/data-protection requirements.
| TISAX / VDA ISA area | ISO/IEC 27001:2022 | NIST CSF 2.0 | SOC 2 (TSC) |
|---|---|---|---|
| IS policies and organisation | Clauses 5-6; A.5 Organisational controls | Govern (GV); Identify (ID) | CC1, CC2, CC3 |
| Human resources security | A.6 People controls | Protect (PR.AA / awareness) | CC1.4, CC2 |
| Physical security and BCM | A.7 Physical controls; Clause 8 / A.5.30 | Protect (PR); Recover (RC) | CC6.4, A1 |
| Identity and access management | A.5.15-18; A.8.2-8.5 | Protect (PR.AA) | CC6.1-CC6.3 |
| IT / cyber security operations | A.8 Technological controls | Protect (PR); Detect (DE) | CC6, CC7 |
| Supplier relationships | A.5.19-23 | Govern (GV.SC); Identify | CC9.2 |
| Compliance | A.5.31-36 | Govern (GV) | CC2, CC4 |
| Prototype protection | No direct ISO equivalent (automotive-specific) | ID / PR (physical) | No direct equivalent |
| Data protection module | ISO/IEC 27701; GDPR Art. 28 | Govern (GV) / Protect | Privacy / Confidentiality TSC |
Frequently asked questions
Need help with TISAX?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.
