TISAX ISA v6 gap analysis: what the assessment misses and why it matters
Amara OkaforApril 29, 2026
Key takeaways
TISAX-certified organizations show measurable configuration drift in 71% of environments reviewed within 12 months of successful audit, based on Vulnox assessment data -- the certificate was accurate when issued, the environment had changed.
Article 4.2.2 patch management is the most consistently failed TISAX control in automotive supplier environments; Vulnox data shows an average 140-day remediation lag for critical CVEs on MES and ICS components.
Organizations with ISO 27001 certification still averaged 14 open findings against TISAX-specific controls in initial Vulnox assessments -- the automotive-specific control domains do not map cleanly to generic ISMS frameworks.
Assessment Level 3 requires on-site inspection of physical security and OT environments; misclassifying scope as AL2 when OEM contracts require AL3 is among the most common and costly pre-assessment errors.
TISAX audit evidence formats (PDF screenshots, policy documents) and post-breach forensic evidence formats (raw JSONL logs, PCAP, memory images) are almost entirely non-overlapping -- optimizing for one degrades readiness for the other.
Supplier risk management under Article 4.1.3 fails in a specific pattern: third-party assessments completed at onboarding and never repeated, leaving the supplier risk posture static while actual supplier environments change.
TL;DR
TISAX certification confirms your controls existed and were documented on the day the auditor looked. It does not confirm they still exist six months later. The gap between audit-time compliance and operational security is widest in three places: OT patch management that nobody wants to touch because it requires production downtime, configuration drift that accumulates silently between audit cycles, and supplier risk programs that stopped after the initial questionnaire. This article is about what hands-on assessment finds that the ISA v6 checklist process does not.
The ISO 27001 certificate that almost cost them the OEM contract
A Tier 2 automotive supplier in Poland came to us six weeks before their TISAX AL2 deadline. They had ISO 27001 certification, a documented ISMS, and a security team that had done the internal readiness review. Their confidence level going into the call was high. We ran a technical pre-assessment over two weeks. Fourteen findings against TISAX-specific controls that ISO 27001 had not surfaced. Three were in prototype data handling -- a control domain that ISO 27001 treats under general asset management but TISAX specifies with obligations their current classification scheme did not cover. One was the MES network segment, which shared a subnet with the corporate domain controller. The ISO 27001 auditor had noted the network architecture. The TISAX AL2 auditor would do the same. The AL3 auditor their OEM was about to require would walk into the facility and look at the physical cabling.
The ISO 27001 certificate was accurate for what it measured. TISAX measures different things, and the overlap is real but incomplete in exactly the places automotive suppliers are most exposed: OEM IP handling, prototype environments, and OT network architecture. The supplier knew this in the abstract. They had not mapped it to their specific environment before beginning remediation.
What ISA v6 actually requires that other frameworks leave underspecified
The ISA v6 catalogue organizes controls across three main domains: information security (IS), prototype protection (PP), and data protection (DP). The IS domain maps reasonably well to ISO 27001 -- organizations with mature ISMSs typically cover it with moderate gaps. The PP domain is where the automotive specificity concentrates. It requires physical and logical controls specifically for prototype data: CAD files, production specifications, tooling designs, test results. The question is not whether you have an asset register. It is whether your asset register explicitly classifies prototype data as a separate category with associated handling restrictions, access controls, and destruction procedures that match the OEM contractual requirements for that data.
Example
A common failure pattern: an organization classifies data as Confidential, Restricted, or Public. Prototype CAD files land in Confidential. The TISAX PP control requires that prototype data handling includes specific controls around printing (tracked output, no unattended printing), physical transport (sealed containers, documented chain of custody), and digital transmission (not via standard email, requires encrypted channels with recipient verification). None of those specific requirements are legible from the Confidential classification alone. The classification exists. The control specificity required by TISAX does not exist under it.
The ISA v6 maturity model scores controls from 0 to 5. Most TISAX certifications require a score of 3 on applicable controls, which means the control is documented, implemented, and periodically reviewed. Score 3 does not require that the control is automatically enforced or that deviations are automatically detected. The gap between score 3 and actually-effective is where configuration drift and manual process failures accumulate.
What the assessment data shows across automotive supplier environments
Assessment base: Pre-assessment and gap analysis engagements across 28 automotive supplier environments, 2022-2024, mix of Tier 1 and Tier 2 suppliers across DE, PL, CZ, and UK
Configuration drift in 71% of TISAX-certified environments within 12 months of audit
When we ran automated configuration baseline scans against TISAX-certified environments, 20 of 28 showed deviations from the configuration state documented in their audit evidence. The most common drifts: password policy complexity requirements weakened after an application compatibility issue; audit logging disabled on a subset of domain controllers after a storage capacity event; TLS 1.1 re-enabled on a legacy integration endpoint that the application team did not realize was in scope. None of these changes were malicious. All of them would produce findings in a re-audit.
The certification process creates a snapshot. Operations create drift. The organizations that fared worst had no automated process for comparing current configuration state against the certified baseline -- they relied on change management documentation, which captures intentional changes but not the ones that happen as operational workarounds. The control that addresses this, Article 5.3.4, is typically satisfied with a documented configuration management policy. The automated enforcement of that policy is a separate thing that the audit does not require.
Average 140-day critical CVE remediation lag on MES and ICS components
Across environments where OT-adjacent systems were in scope, the average time from CVE publication to patch deployment on manufacturing execution systems and industrial control components was 140 days. For comparison, TISAX Article 4.2.2 requires critical vulnerabilities to be remediated within a risk-appropriate timeframe, with documentation of exceptions. Most organizations had exception documentation. The exceptions covered nearly every critical CVE on the OT systems because production downtime windows were not available.
The documentation was technically TISAX-compliant. The risk was real and growing. The root issue is not that organizations are ignoring patch management -- they know the gap exists. The issue is that OT patch deployment requires coordination with production scheduling, OEM approval for maintenance windows in some cases, and vendor testing for ICS firmware updates. None of that process is fast. TISAX compliance in this area often amounts to well-documented acceptance of a risk that nobody has the operational authority to close unilaterally.
Supplier risk management treated as a one-time onboarding activity in 19 of 28 environments
Article 4.1.3 requires ongoing supplier risk management. In 19 of 28 environments, the process consisted of an initial questionnaire at supplier onboarding, a policy requiring annual reassessment, and no evidence that the annual reassessment had ever been completed for suppliers onboarded more than 12 months prior. The policy said annually. The practice said once. Auditors reviewing the policy and a sample of recent onboarding questionnaires would see a compliant program. Auditors requesting evidence of reassessment for a five-year supplier relationship would find none.
This is the most structurally predictable gap in TISAX programs. The onboarding process is visible and has a deliverable -- the questionnaire. The reassessment process is invisible because it has no external trigger. Nobody sends a reminder. The supplier does not request it. It requires the internal team to initiate it on a schedule, and that schedule competes with everything else the team is doing. The organizations with functioning reassessment programs had automated calendar reminders tied to supplier onboarding dates in their GRC tool. The organizations without had good intentions in their policy documents.
ISO 27001 certification masked an average of 14 TISAX-specific open findings on first assessment
Every organization in the dataset that presented ISO 27001 certification as evidence of TISAX readiness had open findings against TISAX-specific controls on their initial assessment. The average count was 14. The range was 8 to 23. The controls with the highest miss rate were prototype protection (PP domain, not addressed in ISO 27001), OT network segmentation documentation (ISO 27001 addresses network security generically; TISAX requires specific documentation of OT segment isolation), and the data classification requirements for OEM IP categories.
ISO 27001 is a useful foundation and a genuine head start. It is not a substitute for ISA v6 gap analysis, and organizations that present it as one are consistently surprised by the finding count. The surprise is expensive -- it compresses remediation timelines and has caused two organizations in the dataset to delay their OEM contract start date while completing automotive-specific control remediation.
The organizations with the most documentation had the worst audit outcomes
Common belief
A mature document management system and comprehensive policy library signals TISAX readiness. If the controls are documented, the organization is close to compliant.
What we found
In two cases, the most thoroughly documented organizations in the dataset had the highest configuration drift scores on technical assessment. Their policies described exactly how configuration management should work. Their systems were not enforcing it. The auditors who reviewed the documentation would see a mature program. The automated scan that compared current state to documented baseline saw 23 deviations. Both things were simultaneously true.
Documentation maturity and control effectiveness are weakly correlated in TISAX environments. The organizations that invested heavily in policy documentation -- detailed patch management policies, comprehensive asset registers, extensive supplier questionnaire libraries -- consistently had higher finding counts on technical control validation than organizations with leaner documentation that was tied to automated enforcement. The reason is attention allocation. Writing and maintaining detailed policies requires ongoing effort from the same team members who would otherwise be implementing configuration enforcement, automated drift detection, and supplier reassessment triggers. Documentation is visible, auditable, and produces a deliverable. Technical control enforcement is invisible until something goes wrong. Both are required for TISAX compliance. In resource-constrained teams, documentation expands to fill the available time.
What automotive suppliers say before gap analysis, and what is actually underneath
'Our ISO 27001 cert covers most of TISAX. We just need to fill in a few gaps.'
Root cause:The overlap between ISO 27001 and TISAX IS controls is real -- roughly 60-70% of IS domain controls have ISO 27001 counterparts. The PP and DP domains have minimal overlap. Organizations with ISO 27001 certification consistently underestimate the prototype protection domain because it has no equivalent in the ISO framework. The 'few gaps' assumption typically encounters 8-14 specific findings that require dedicated remediation work, including physical security controls for prototype areas that the ISO 27001 audit did not assess.
'We completed supplier risk assessments for all our vendors last year.'
Root cause:Completed means onboarded. For the majority of organizations, last year's supplier risk assessment was the initial onboarding questionnaire from whenever that supplier relationship started. The annual reassessment required by Article 4.1.3 was documented as a policy obligation but had not been operationalized as a scheduled process. The distinction between 'we have assessed our suppliers' and 'we reassess them on a defined cycle' is where the gap lives, and it is invisible until someone asks for evidence of the most recent reassessment for a five-year supplier relationship.
'We have a patch management process. Our team reviews vulnerabilities monthly.'
Root cause:Monthly review on corporate IT systems is generally credible. The same process applied to OT-adjacent systems fails on execution because patching MES and ICS components requires production downtime coordination, vendor testing, and sometimes OEM approval that the security team does not control. The review happens. The remediation does not, because the team that can approve the maintenance window is not the team doing the vulnerability review. Article 4.2.2 compliance requires both -- and the documentation of exceptions and risk acceptance decisions needs to be auditor-accessible, which it rarely is when the decisions are made verbally in production scheduling meetings.
The ISA v6 gaps that standard gap analysis tooling does not surface
Audit log retention on cold storage versus SIEM index
Article 5.1.1 requires logging and monitoring with sufficient retention for incident investigation. TISAX auditors typically verify this by reviewing SIEM configuration screenshots showing retention policy settings. What they do not verify is whether the cold storage archival policy -- where logs move after the SIEM index window closes -- matches the documented retention requirement. In several Vulnox assessments, the SIEM was configured for 90-day indexing with automated archival to object storage. The archival policy had an independent retention setting that had been reduced during a cost optimization exercise. The SIEM configuration screenshot showed 90 days. The archived logs older than 30 days had been deleted. An incident at day 45 would have incomplete evidence.
Data flow documentation for OEM-specific information categories
TISAX requires that information flows involving OEM-classified data are documented and controlled. The gap in most environments is not that data flows are undocumented -- most organizations have data flow diagrams. The gap is that OEM-specific data categories (prototype specifications, pre-production test data, tooling designs) are not traced through the data flow diagram separately from generic confidential data. When an auditor asks 'show me the data flow for prototype CAD files from receipt through processing to archival,' the answer is usually a combination of a general data flow diagram and verbal explanation. For AL3 assessments particularly, that combination is not sufficient.
Connected system scope creep between audit cycles
TISAX scope is defined at assessment time. Between assessments, integrations get added: a new MES integration with a logistics partner, an IoT sensor network on the production floor, a cloud-based QMS that ingests production data. Each integration potentially expands the scope of systems that should be in TISAX scope. None of them trigger a scope review automatically. By the next audit cycle, the scope definition is stale, and controls that should apply to new systems have not been implemented for them. This is not a dramatic failure -- it is a slow accumulation of scope drift that mirrors the configuration drift problem but at the architectural level.
Where TISAX compliance failures are heading
Within 24 months, at least one publicly reported automotive supplier breach will be attributed to a TISAX-certified environment where the exploited control had been compliant at audit time but had drifted post-certification.
The configuration drift finding in 71% of certified environments is a structural condition, not an outlier. The number of TISAX-certified suppliers is growing as OEM requirements expand down the supply chain. The combination of increasing certified scope and known drift rates means the probability of a breach in a certified-but-drifted environment is increasing. The breach itself is not the prediction -- breaches happen in certified environments regularly. The prediction is that the post-incident analysis will explicitly identify the audit-time versus breach-time configuration discrepancy, which will force a public conversation about what TISAX certification actually guarantees.
Confidence: mediumA published incident report or regulatory finding referencing a TISAX-certified supplier breach where the root cause control had passed the most recent audit but was not in compliant state at time of breach. Watch ENX community communications and German BSI advisories.ENX will introduce a continuous monitoring requirement or inter-audit attestation mechanism into TISAX by 2027, specifically targeting configuration drift between audit cycles.
The point-in-time audit model is the known weakness of the current framework. ENX has introduced ISA v6 changes that moved toward more prescriptive control specificity -- the direction of travel is toward more rigorous verification, not less. Continuous monitoring requirements have appeared in adjacent frameworks (NIS2, DORA for financial services). The automotive sector is watching those frameworks for borrowable mechanisms. The falsifiable signal is already partially visible: the ISA v6 control language around secure configuration management is more specific than v5, which suggests ENX is aware of the drift problem even if the audit mechanism does not yet address it.
Confidence: mediumAn ENX announcement or ISA v7 draft that includes inter-audit attestation, continuous configuration monitoring requirements, or automated evidence submission for configuration baseline controls.
Why TISAX gap analysis needs technical hands on the environment, not just the documentation
Most TISAX gap analysis engagements are documentation reviews. A consultant collects policy documents, configuration screenshots, and process descriptions, maps them against the ISA v6 control catalogue, and produces a gap report. That process finds the documentation gaps. It does not find the configuration drift, the OT patch window that has been open for 140 days, or the SIEM archival policy that was quietly changed six months ago. The organizations that arrive at their TISAX audit with the fewest surprises are the ones that ran a technical pre-assessment -- automated configuration scanning against their actual systems, not their documented baselines. The gap analysis that only reads documents is essentially asking the patient to describe their own symptoms. The physical exam is separate.
Counterargument
The counterargument is that technical pre-assessment is expensive and time-consuming, and for organizations with limited budgets and compressed timelines, documentation review is a reasonable starting point that identifies the majority of remediation work. That is partially true. Documentation review does identify the majority of work by volume of findings. What it misses is disproportionately impactful -- configuration drift and logging gaps are the findings most likely to appear in a post-breach forensic investigation. The cost calculation changes significantly when you factor in what a missed technical finding costs after the audit rather than before it.
One concrete action before your TISAX timeline begins
Pull your current SIEM log retention configuration and your cold storage archival policy and compare them side by side this week. They should show the same retention period. In a significant portion of TISAX-assessed environments, they do not -- the SIEM index setting was set correctly at implementation, and the archival policy was changed independently during a storage cost review without anyone considering the compliance implication. It takes 20 minutes to check. If they match, you have confirmed one control that auditors often miss but forensic investigators always need. If they do not match, you have found a gap before the auditor does.
Further Reading
Gap Analysis
framework gap analysisISO
ISO 27001 framework questionnaireISO 27001 Official Standard
ISO 27001 official standardUnderstanding Compliance Gap Analysis
understanding compliance gap analysisNIST Cybersecurity Framework 2.0
NIST Cybersecurity Framework
Frequently Asked Questions
What does a TISAX ISA v6 gap analysis actually cover that a standard ISO 27001 audit does not?
TISAX ISA v6 adds automotive-specific control domains that ISO 27001 treats generically or not at all: prototype protection (IS controls 6.x), connected vehicle data handling, and supply chain information flow requirements tied to OEM contractual obligations. A gap analysis against ISA v6 must specifically evaluate whether information asset classification includes CAD data, bill-of-materials, and production tooling specifications -- all of which carry OEM IP obligations that a generic ISO 27001 asset register typically ignores. In Vulnox assessments, organizations with existing ISO 27001 certification still averaged 14 open findings against TISAX-specific controls when first assessed.
What is the difference between TISAX assessment level 2 and level 3?
Assessment Level 2 is conducted remotely by an ENX-accredited auditor reviewing documentation, configuration screenshots, and process evidence. Level 3 requires an on-site audit with direct inspection of physical security controls, server rooms, and operational technology environments. The practical gap is significant: Level 2 auditors cannot observe whether badge access logs are actually reviewed, whether server room entry records match shift schedules, or whether OT network segments are physically isolated from corporate networks. Level 3 is required for prototype handling and for suppliers with AL3 designations in their OEM contracts. Misclassifying scope as AL2 when the OEM requires AL3 is one of the most common -- and most costly -- errors Vulnox encounters during pre-assessment reviews.
How long does TISAX ISA v6 certification take from initial gap analysis to audit completion?
Based on Vulnox assessment data, organizations completing a gap analysis before beginning remediation averaged 7 months from gap analysis to successful audit completion. Organizations that skipped gap analysis and went directly to remediation based on internal estimates averaged 11 months, because they consistently underestimated the scope of supplier risk management and logging control gaps. The variance is largest for organizations handling prototype data -- AL3 scope adds physical security remediation work that typically takes 3 to 4 months independently of technical controls.
What TISAX ISA v6 controls fail most often in Vulnox automotive supplier assessments?
Three control areas fail consistently: Article 4.2.2 patch management on OT-adjacent systems (average remediation lag of 140 days for critical CVEs on MES and ICS components); Article 5.3.4 secure configuration management, specifically the absence of automated drift detection that would catch post-audit configuration weakening; and supplier risk management under Article 4.1.3, where third-party assessments are completed at onboarding and then not repeated. The patch management failure is the most operationally embedded -- organizations know it is a gap but cannot remediate without production downtime windows that require OEM coordination.
Does passing TISAX certification mean the environment is actually secure?
Not reliably, for a specific structural reason. TISAX audits validate controls at a point in time against documented evidence. Configuration drift -- the gradual weakening of hardened settings between audit cycles -- is not detected by the certification process. In Vulnox assessments of TISAX-certified organizations, automated configuration scans identified deviations from audit-time baselines in 71% of environments reviewed within 12 months of their last successful audit. The certification was accurate when issued. The environment had changed. The certificate had not.
What evidence format do TISAX auditors actually request versus what forensic investigators need post-breach?
TISAX auditors typically accept PDF screenshots of SIEM dashboards, policy documents with approval signatures, and configuration exports in vendor-native formats. Forensic investigators after a breach need raw log exports in structured formats (JSONL or CSV with UTC timestamps), memory images from affected systems, and network flow records in PCAP or NetFlow format. The evidence formats are almost entirely non-overlapping. Organizations that optimize for audit evidence collection -- polished PDFs, redacted screenshots -- are systematically less prepared for post-incident investigation than organizations that collect raw machine-readable logs regardless of audit requirements.
How should a TISAX remediation sequence be ordered to avoid rework?
Network segmentation before application controls. Logging infrastructure before detection rules. Supplier risk management processes before technical supplier assessments. The most expensive rework pattern Vulnox encounters is organizations that implement MFA and WAF controls before segmenting OT networks from corporate infrastructure -- when the segmentation work happens later, it frequently breaks authentication flows and requires application control reconfiguration. Patch management on OT systems should be scoped last because it requires production downtime coordination; attempting it before network architecture is stable adds scheduling risk without reducing exposure.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.