Knowledge Center / TISAX
ENX Association · Global / Europe

TISAX (Automotive)

The information-security assessment standard for the automotive industry.

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.

Copyright and licensing note
TISAX, the VDA ISA catalogue, and the associated assessment criteria are the intellectual property of the ENX Association and the VDA (Verband der Automobilindustrie). This guide is an original, independent explanation written for educational purposes. It does not reproduce the copyrighted text of the VDA ISA control catalogue, the TISAX Participant Handbook or ENX assessment requirements. Organisations must obtain the current official VDA ISA workbook and register on the ENX TISAX portal to conduct a formal assessment. Requirement identifiers and terminology are referenced descriptively for orientation only.

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.

Label, not certificate
TISAX deliberately avoids the word certificate. A successful assessment yields a TISAX label with a defined validity (typically three years) that is visible only to organisations the participant chooses to share it with on the ENX portal. There is no public register of pass or fail. This confidentiality model is a defining feature of the exchange.

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 typeWhy TISAX typically applies
Vehicle OEMsSet the requirement for their supply base and often hold labels themselves for internal and joint-venture assurance
Tier 1 / Tier 2 component suppliersHandle 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 developersAccess source code, calibration data and connected-vehicle information
Prototype and tooling manufacturersPhysically hold protected prototypes and pre-series parts (Prototype Protection objective)
Testing, validation and homologation labsOperate proving grounds, camouflaged vehicle testing and secure test benches
Design, styling and clay-model studiosHandle unreleased styling and design information of very high sensitivity
Logistics and transport providersMove prototypes and confidential materials; may need prototype and confidentiality objectives
Marketing, media and event agenciesReceive pre-launch imagery, film footage and product information under embargo
IT / cloud / managed service providersProcess or store automotive customer data; may need the data-connection objective
Providers processing personal dataHandle 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 / domainScope of contentApplies when
1. IS Policies and OrganisationGovernance, ISMS scope, roles, risk management, asset and project security, supplier and external-party managementAlways (Information Security module)
2. Human ResourcesPersonnel screening, awareness, training, confidentiality obligations, teleworkingAlways
3. Physical Security and Business ContinuitySecurity zones, access control to premises, equipment protection, BCM and redundancyAlways
4. Identity and Access ManagementIdentity lifecycle, authentication, privileged access, access rights reviewAlways
5. IT Security / Cyber SecurityCryptography, operations security, malware, logging, vulnerability and change management, network segmentation, secure developmentAlways
6. Supplier RelationshipsSecurity requirements in the supply chain, service delivery, cloud servicesAlways
7. ComplianceLegal and regulatory compliance, protection of records, information security reviews and auditAlways
Prototype ProtectionPhysical and organisational protection of prototypes, test vehicles and pre-series parts, plus event and film-shoot securityPrototype objective selected
Data ProtectionControls derived from GDPR Article 28 for order-processing (processor) obligationsData 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 verifyTypical evidence
An information security policy is defined, approved by top management, published and communicatedSigned 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 locationsISMS scope statement, site list, scope diagram
A risk assessment methodology exists and information security risks are identified, evaluated and treatedRisk methodology, risk register, risk treatment plan, management sign-off
Assets are inventoried, owned and classified according to protection needsAsset inventory, classification scheme, information classification policy
Information security is addressed within projects from initiationProject security checklist, sample project security assessment
Segregation of duties and conflicting responsibilities are managedSoD matrix, access provisioning approvals
Contact with authorities and special interest groups is maintainedCERT membership, authority contact list, incident escalation contacts
Management reviews the ISMS at planned intervals and drives continual improvementManagement review minutes, improvement actions, KPI reports

Domain 2 — Human Resources Security

What to verifyTypical evidence
Background verification is performed for personnel commensurate with role sensitivity and lawScreening policy, sample screening records, HR procedure
Confidentiality / non-disclosure obligations are agreed with employees and contractorsSigned NDAs, employment contract clauses, contractor agreements
Employees receive information security awareness training and role-specific educationTraining plan, attendance records, e-learning completion reports
Terms and conditions of employment reference security responsibilitiesEmployment contract templates, acceptable use policy acknowledgements
A disciplinary process exists for security breachesDisciplinary policy, HR sanction procedure
Joiner-mover-leaver process ensures timely change and return of assets and revocation of accessJML procedure, asset return checklist, offboarding tickets
Teleworking and mobile working are governed by policy and technical controlsRemote working policy, VPN/endpoint config standards

Domain 3 — Physical Security and Business Continuity

What to verifyTypical evidence
Physical security perimeters and zones are defined based on protection needSite zoning plan, security concept, floor plans
Physical entry controls restrict access to authorised personsAccess control system logs, badge management records, visitor log
Offices, rooms and secure areas (e.g. server rooms, prototype areas) are protectedRoom access lists, CCTV coverage map, lock/alarm records
Delivery, loading and public-access areas are controlledGoods-in procedure, segregation of delivery zones
Equipment is sited, protected and maintained; power and cabling securedMaintenance records, UPS/generator tests, cabling standards
Secure disposal and reuse of equipment and media is enforcedMedia sanitisation records, certificates of destruction
Clear desk and clear screen policy is implementedClear desk policy, walkthrough observation, screen-lock GPO
Business continuity and redundancy for information processing are planned and testedBCM policy, BIA, continuity plans, DR test reports

Domain 4 — Identity and Access Management

What to verifyTypical evidence
A formal identity lifecycle governs creation, change and removal of user identitiesIAM policy, provisioning workflow, identity source of truth
Access to information and systems is granted on least-privilege and need-to-knowAccess request/approval records, role-based access model
Authentication mechanisms are appropriate to risk; MFA for remote and privileged accessAuthentication policy, MFA configuration, VPN/SSO settings
Password and secret management enforce strength and confidentialityPassword policy, password manager/vault, key handling procedure
Privileged and administrative access is restricted, logged and reviewedPrivileged account inventory, PAM logs, admin approval records
Access rights are reviewed at planned intervals and on role changeAccess recertification reports, review sign-offs
User authentication information (credentials) is protected in storage and transitHashing/encryption config, secrets store evidence
Access to source code and development environments is controlledRepository access matrix, branch protection settings

Domain 5 — IT / Cyber Security (Operations, Cryptography, Development)

What to verifyTypical evidence
A cryptography policy defines algorithms, key strength and key managementCrypto policy, approved cipher list, key management procedure
Keys are generated, stored, rotated and revoked under controlled processesKey inventory, KMS/HSM records, rotation logs
Documented operating procedures exist for information processing facilitiesRunbooks, SOPs, configuration baselines
Change management controls changes to systems and applicationsChange policy, change tickets, CAB approvals
Capacity is monitored and managedCapacity reports, monitoring dashboards
Development, test and production environments are separatedEnvironment topology, deployment pipeline segregation
Protection against malware is deployed and kept currentEDR/AV coverage report, signature/update status
Backups are performed, protected and restore-testedBackup policy, backup job logs, restore test evidence
Event logging captures user, admin and security events; logs are protectedLogging standard, SIEM ingestion list, log retention config
Clock synchronisation is enforcedNTP 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 securedNetwork diagram, firewall rulebase, segmentation evidence
Secure development and system acquisition practices are appliedSecure SDLC policy, code review records, SAST/DAST reports
Test data is protected and production data is not used insecurely in testTest data management procedure, masking/anonymisation evidence
Information transfer (email, file exchange, portals) is protectedEncryption in transit config, secure file-transfer procedure

Domain 6 — Supplier Relationships (Supply Chain Security)

What to verifyTypical evidence
Information security requirements are agreed with suppliers who access, process or store dataSupplier security clauses, onboarding questionnaire, contracts
Supplier risk is assessed before and during the relationshipSupplier risk assessments, tiering criteria
Security requirements are flowed down to sub-suppliers in the ICT supply chainFlow-down clauses, sub-processor register
Supplier service delivery is monitored and reviewedService reviews, SLA reports, audit rights exercised
Changes to supplier services are managed with security in mindSupplier change records
Cloud service use is governed, including data location and shared-responsibilityCloud policy, provider due-diligence, configuration evidence

Domain 7 — Compliance

What to verifyTypical evidence
Applicable legal, regulatory and contractual requirements are identified and documentedLegal register, compliance obligations list
Intellectual property rights and licensing are respectedIP policy, software licence inventory
Records are protected against loss, destruction and falsification per retention needsRecords retention schedule, protected storage evidence
Privacy and protection of personal data comply with applicable lawData protection policy, records of processing
Information security is independently reviewed at planned intervalsInternal audit plan, audit reports, corrective actions
Technical compliance with policies and standards is checkedConfiguration audit reports, hardening compliance scans

Prototype Protection Module (when Prototype objective is in scope)

What to verifyTypical 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 enforcedZoning, fencing, access control, CCTV, alarm evidence for prototype zones
Access to prototypes and secure areas is need-to-know and loggedPrototype area access lists, visitor escorting records
Camouflage, covering and concealment measures protect vehicles in transit and testingCamouflage procedure, covered-transport evidence
Requirements for handling test and trial vehicles on public and private roads are metTest-drive authorisation, driver briefing, route control
Events and film/photo shoots involving prototypes are securedEvent security plan, confidentiality briefings, device controls
Third parties handling prototypes meet equivalent protection requirementsSub-supplier prototype agreements, audits

Data Protection Module (when Data Protection objective is in scope)

What to verifyTypical evidence
Order-processing (processor) obligations under GDPR Article 28 are implementedData processing agreements, processing instructions
A record of processing activities is maintainedRoPA / processing register
Technical and organisational measures (TOMs) protect personal dataTOM documentation, encryption/pseudonymisation evidence
Data subject rights and controller instructions are supportedDSR procedure, instruction handling records
Sub-processor engagement is authorised and controlledSub-processor list, authorisation records
Personal data breaches are detected and reported to the controllerBreach procedure, notification templates, timelines
Cross-border transfers use valid safeguardsTransfer 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.
Scope drives everything
The assessment objective and level you register determine which VDA ISA controls apply and how deeply they are tested. Under-scoping saves effort but risks customer rejection of the label; over-scoping inflates cost. Validate the required objective and level against your customer's actual contractual demand before registering.

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.

LevelNameMeaning for the assessor
0IncompleteThe control is not implemented or does not achieve its purpose; a partial or non-existent process.
1PerformedThe control is performed but ad hoc and undocumented; results depend on individuals.
2ManagedThe control is performed and managed (planned, monitored) but not fully standardised across the organisation.
3EstablishedThe control follows a defined, documented standard process and is consistently applied — the usual target.
4PredictableThe control operates within defined quantitative limits and its performance is measured and predictable.
5OptimisingThe 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.

  1. Register on the ENX TISAX portal, define scope, objectives and assessment level, and obtain the participant/scope IDs.
  2. Complete and submit the VDA ISA self-assessment to the required target maturity.
  3. Select and contract an ENX-approved TISAX audit provider (the participant chooses and pays the provider directly).
  4. Undergo the initial assessment: for AL 2, largely evidence-based and often remote; for AL 3, on-site inspection, interviews and control walkthroughs.
  5. 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.
  6. Implement corrective actions within the defined window (typically up to nine months for the plan) and undergo a follow-up review where required.
  7. On successful closure, the audit provider confirms results and the participant is issued the TISAX label(s) with a three-year validity.
  8. Share the label selectively with customers via the ENX portal; only recipients you authorise can view your result.
  9. Maintain the ISMS through the validity period; significant scope changes, new locations or higher objectives trigger re-assessment before expiry.
  10. 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

RoleKey TISAX responsibilities
Executive sponsor / top managementApprove scope and budget, endorse the IS policy, chair management reviews, own residual risk
Information Security Officer / CISOOwn the ISMS, drive remediation, coordinate the assessment, maintain the evidence library
TISAX project leadRun the programme plan, manage the portal registration, liaise with the audit provider
IT / infrastructure teamsImplement and evidence technical controls (IAM, logging, backup, network, endpoints)
Application / development teamsDeliver secure SDLC, code review, environment segregation and test-data protection
HRScreening, NDAs, awareness training, JML process, disciplinary handling
Facilities / physical securityZoning, access control, CCTV, prototype-area protection, visitor management
Data protection officer / privacyData Protection module controls, DPAs, RoPA, breach and DSR handling
Procurement / vendor managementSupplier security clauses, flow-down, risk assessment and reviews
Internal auditIndependent internal review, mock assessment, corrective-action verification
Control ownersMaintain 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 areaISO/IEC 27001:2022NIST CSF 2.0SOC 2 (TSC)
IS policies and organisationClauses 5-6; A.5 Organisational controlsGovern (GV); Identify (ID)CC1, CC2, CC3
Human resources securityA.6 People controlsProtect (PR.AA / awareness)CC1.4, CC2
Physical security and BCMA.7 Physical controls; Clause 8 / A.5.30Protect (PR); Recover (RC)CC6.4, A1
Identity and access managementA.5.15-18; A.8.2-8.5Protect (PR.AA)CC6.1-CC6.3
IT / cyber security operationsA.8 Technological controlsProtect (PR); Detect (DE)CC6, CC7
Supplier relationshipsA.5.19-23Govern (GV.SC); IdentifyCC9.2
ComplianceA.5.31-36Govern (GV)CC2, CC4
Prototype protectionNo direct ISO equivalent (automotive-specific)ID / PR (physical)No direct equivalent
Data protection moduleISO/IEC 27701; GDPR Art. 28Govern (GV) / ProtectPrivacy / Confidentiality TSC
How CyberSigma helps you achieve your TISAX label
CyberSigma provides end-to-end TISAX readiness: from confirming the right assessment objectives and level against your customer contracts, to portal registration, a full VDA ISA gap assessment, ISMS build and remediation, prototype and data-protection module implementation, evidence-library preparation, internal mock assessment, and hands-on support through your ENX-approved assessment to label award. Our CERT-In empanelled and QSA-qualified auditors translate automotive supply-chain requirements into a defensible, audit-ready programme — and keep you continuously compliant through the three-year label lifecycle. Talk to CyberSigma to build your TISAX roadmap.
Free 1-minute check
Free Security Assessment
Get a complimentary, no-obligation assessment from CERT-In empanelled senior auditors.
Try it free →

Frequently asked questions

Is TISAX the same as ISO 27001?
TISAX is based on the VDA ISA, which is aligned to ISO 27001 but tailored to the automotive industry, adding prototype and data-protection objectives. An ISO 27001 ISMS is a strong head start.
Official documents

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.