TISAX Firewall Requirements: What Automotive Suppliers Must Document
Over 30,000 automotive suppliers globally need TISAX certification to do business with OEMs like Volkswagen, BMW, and Daimler. Yet 67% fail their first audit attempt — and incomplete firewall documentation is one of the most common reasons. If you are an automotive supplier preparing for a TISAX assessment, your firewall configuration and change management documentation will be scrutinized in detail.
This guide breaks down the specific TISAX firewall requirements you need to meet, explains why most suppliers fail, and provides a practical checklist for building documentation that passes on the first attempt.
What Is TISAX and Why Does It Matter for Firewalls?
TISAX (Trusted Information Security Assessment Exchange) is the automotive industry’s information security standard, administered by the ENX Association. It is based on the VDA Information Security Assessment (VDA ISA) catalog, which is itself derived from ISO 27001 but with automotive-specific requirements around prototype protection, data confidentiality, and supply chain security.
For firewalls, TISAX matters because the VDA ISA catalog contains specific control objectives around network segmentation, access control, change management, and incident response — all of which are directly implemented through firewall policies. Your firewall is the enforcement point for many of the controls TISAX auditors will assess.
Unlike ISO 27001, which is an international standard with broad applicability, TISAX is industry-specific and recognition is shared through the ENX portal. Once you achieve TISAX certification, OEMs and Tier 1 suppliers can verify your status without requiring their own audits — saving significant time and cost across the supply chain.
The 5 Core TISAX Firewall Requirements
While the VDA ISA catalog covers information security broadly, these five control areas have the most direct impact on your firewall infrastructure and documentation:
1. Complete Change History
Every firewall rule change must be documented with a complete audit trail: who requested the change, who approved it, when it was implemented, and the business justification. TISAX auditors will ask to see your change log and will verify that it covers all changes made during the assessment period. Informal changes — done directly on the CLI without going through a process — are audit findings.
What auditors check: Change request records, approval evidence, implementation timestamps, business justification documentation, before/after rule state.
2. Regular Rule Review
Firewall rules must be reviewed regularly to confirm they are still needed and appropriately configured. TISAX expects documented evidence of periodic reviews — not just a statement that reviews happen, but actual records showing which rules were reviewed, by whom, and what the outcome was (kept, modified, or removed).
What auditors check: Review schedules, review completion records, reviewer identities, findings and actions taken, evidence that unused rules are removed.
3. Network Segmentation
TISAX requires network segmentation to protect sensitive data — particularly prototype information, which is a major concern for automotive OEMs. Your firewall policies must enforce clear boundaries between network zones: production networks, development environments, guest access, and any zones handling confidential prototype data. Network diagrams must accurately reflect the segmentation.
What auditors check: Network architecture diagrams, firewall zone configurations, inter-zone traffic rules, prototype data isolation controls, guest network separation.
4. Access Control
Firewall rules must enforce the principle of least privilege — only the traffic that is explicitly required should be allowed, with everything else denied by default. TISAX auditors will look for overly permissive rules (especially any-any rules), rules that allow unnecessary services, and rules that do not restrict source or destination addresses appropriately.
What auditors check: Default deny policies, rule specificity (no any-any-allow), service restrictions, source/destination address granularity, admin access controls on the firewall itself.
5. Incident Response
Your firewall infrastructure must support incident detection and response. This means logging is enabled on critical rules, logs are forwarded to a central system (SIEM or log management), retention periods meet TISAX requirements, and there is a documented process for how firewall logs are used during incident investigation.
What auditors check: Logging configuration, log retention periods, SIEM integration, incident response procedures referencing firewall data, evidence of past incident investigations using firewall logs.
Why 67% of Suppliers Fail Their First Assessment
The high failure rate is not because TISAX requirements are unreasonable — it is because most suppliers underestimate the documentation burden. The technical controls (firewalls, segmentation, logging) are usually in place. What is missing is the evidence that those controls are managed properly.
Common Failure Patterns
- No change management process. Firewall changes are made informally — engineer logs in, makes the change, moves on. No request record, no approval, no audit trail. This is the single most common finding.
- Missing business justifications. Rules exist but nobody can explain why. When the auditor asks “why does this rule allow TCP/8080 from the guest network to the production server?” and there is no documented answer, that is a finding.
- No evidence of rule reviews. The team says they review rules quarterly, but there is no documentation proving it happened. No review dates, no reviewer names, no findings, no remediation actions.
- Incomplete network diagrams. The network diagram shows the intended architecture but does not match the actual firewall configuration. New segments, VPN tunnels, or cloud connections were added without updating documentation.
- Logging gaps. Logging is enabled on some rules but not all critical ones. Or logs are stored locally on the firewall with insufficient retention. Or there is no process for reviewing logs during incident response.
How to Prepare: 5 Steps
Here is a practical approach to building TISAX-compliant firewall documentation, whether you are starting from scratch or preparing for a reassessment:
Step 1: Implement a Change Management Process
If you do not already have a formal firewall change management process, implement one immediately. Every rule change — no matter how minor — must go through a defined workflow: request, review, approve, implement, document. This is the foundation that everything else builds on.
Step 2: Audit Your Current Rulebase
Run a comprehensive firewall rule audit to identify shadow rules, conflicts, redundancies, and rules without documentation. Clean up what you can and document what you cannot change immediately (with a remediation plan and timeline).
Step 3: Document Business Justifications
Go through every rule in your rulebase and attach a business justification. For existing rules where the original requester is unknown, work with application owners and IT teams to reconstruct the purpose. If nobody can explain why a rule exists, disable it (with monitoring) and document the decision.
Step 4: Update Network Diagrams
Verify that your network diagrams accurately reflect the actual firewall configuration and network topology. Every zone, every inter-zone rule set, every VPN tunnel, and every cloud connection should be documented. Label zones clearly, especially any areas that handle prototype or confidential OEM data.
Step 5: Establish Review Cadence
Set up a regular review schedule — quarterly is best practice — and document every review. Record which rules were reviewed, by whom, what the findings were, and what actions were taken. Start this well before your TISAX assessment so you have at least 2-3 completed review cycles as evidence.
Manual vs. Automated TISAX Preparation
You can prepare for a TISAX firewall assessment manually, but the effort scales badly. Here is a realistic comparison:
Manual Preparation
- ✗ Change tracking in spreadsheets or emails
- ✗ Rule analysis by visual inspection (days/weeks)
- ✗ Business justifications in separate documents
- ✗ Review evidence scattered across files
- ✗ Audit preparation takes 2-4 weeks
- ✗ Easy to miss rules or lose documentation
Automated Preparation
- ✓ Change tracking with complete audit trail
- ✓ Rule analysis in minutes (shadow, conflict, redundancy)
- ✓ Business justifications attached to each rule
- ✓ Review evidence generated automatically
- ✓ Audit-ready reports exported on demand
- ✓ Continuous compliance, not point-in-time
Assessment Levels and Firewall Expectations
TISAX assessments are performed at three levels, each with increasing rigor. The firewall expectations scale accordingly:
Level 1 (Normal protection): Self-assessment based on the VDA ISA catalog. Firewall documentation must exist, but the assessment is less rigorous. Suitable for suppliers handling non-sensitive data.
Level 2 (High protection): Plausibility check by an approved audit provider. The auditor reviews your documentation and may request additional evidence. Your firewall change management process and rule documentation will be examined. Most common level for suppliers handling confidential OEM data.
Level 3 (Very high protection): Full on-site audit by an approved provider. The auditor verifies your documentation against the actual firewall configuration. They may log into the firewall to compare your documented rules against what is actually running. Any discrepancy between documentation and reality is a finding. Required for suppliers handling prototype data or classified information.
Preparing for the Auditor’s Questions
During a Level 2 or Level 3 TISAX assessment, the auditor will ask specific questions about your firewall management. Be ready for these:
“Show me your firewall change management process. How does a rule change go from request to implementation?”
You need a documented workflow with clear steps, roles, and approval criteria.
“Pick any rule on this firewall. Why does it exist? Who approved it?”
Every rule must have a traceable business justification and approval record.
“When was the last time you reviewed your firewall rules? Show me the evidence.”
You need dated review records with reviewer names, findings, and remediation actions.
“How is the network segment containing prototype data isolated? Show me the firewall rules enforcing that segmentation.”
Network diagrams must match actual firewall zone configuration and rules.
“If a security incident occurred right now, how would you use your firewall logs to investigate?”
You need a documented incident response process that references firewall log data.
Your TISAX Firewall Checklist
Use this checklist to track your TISAX preparation. Each item should be completed and documented before your assessment:
Change Management
- ☐ Formal change management process documented and approved
- ☐ All firewall changes go through the defined process
- ☐ Change requests include business justification
- ☐ Approval records are complete and retrievable
- ☐ Emergency change process defined with retroactive review
Rule Documentation
- ☐ Every rule has a documented business justification
- ☐ Every rule has a named owner or requester
- ☐ Unused or unexplained rules have been removed or documented
- ☐ No overly permissive rules (any-any-allow) exist without documented exception
Network Segmentation
- ☐ Network diagrams are current and accurate
- ☐ Prototype/confidential data zones are clearly identified
- ☐ Firewall zone configuration matches documentation
- ☐ Inter-zone traffic rules enforce least privilege
- ☐ Guest and visitor networks are isolated
Review and Monitoring
- ☐ Regular rule review schedule established (quarterly recommended)
- ☐ At least 2-3 completed review cycles documented
- ☐ Logging enabled on all critical firewall rules
- ☐ Logs forwarded to central SIEM or log management
- ☐ Log retention meets TISAX requirements
Incident Response
- ☐ Incident response procedure references firewall log data
- ☐ Team knows how to query firewall logs during an investigation
- ☐ Escalation procedures are documented and tested
Frequently Asked Questions
How long does TISAX certification take?
From initial preparation to certification, most organizations need 3-6 months. The timeline depends on your starting point — if you already have ISO 27001, much of the groundwork is done. The firewall-specific preparation (change management, rule documentation, review evidence) typically takes 4-8 weeks of focused effort.
Is TISAX the same as ISO 27001?
No. TISAX is based on the VDA ISA catalog, which is derived from ISO 27001 but includes automotive-specific requirements around prototype protection, data classification for OEM data, and supply chain security controls. Having ISO 27001 gives you a strong foundation, but TISAX certification requires additional automotive-specific documentation and controls.
Do I need TISAX for every OEM relationship?
Increasingly, yes. Most major OEMs (Volkswagen, BMW, Daimler, Audi, Porsche) now require TISAX certification from their suppliers. The certification is shared through the ENX portal, so one TISAX assessment covers all OEM relationships at the certified level. Without TISAX, you may be excluded from RFPs and supplier panels.
What happens if I fail the TISAX assessment?
You receive a findings report detailing what needs to be fixed. You have a defined period (typically 3-9 months depending on severity) to address the findings and request a follow-up assessment. During this period, your certification status shows as “in progress” on the ENX portal — which OEMs can see.
Next Steps
If you are preparing for a TISAX assessment, start with your firewall documentation — it is one of the areas most likely to generate findings if not properly prepared. The free FwChange rulebase scanner gives you an instant assessment of your current rule health: shadow rules, conflicts, redundancies, and documentation gaps. It takes 30 seconds and shows you exactly where your rulebase needs attention before the auditor arrives.
For automated change management, continuous rule analysis, and audit-ready documentation that satisfies TISAX requirements, explore the full FwChange platform or view pricing.
See How Your Firewall Rules Score
Upload your config and get a free compliance report with shadow rule detection, conflict analysis, and optimization recommendations.
Stay Updated
Get firewall management tips, compliance guides, and product updates.
No spam. Unsubscribe anytime.