THE CALL CAME IN 37 MINUTES AFTER THE LEAK WAS NOTICED

By then, the ADAS algorithm video had already been forwarded from a tier‑2 software partner to a marketing freelancer and quietly synced into a public cloud folder outside your TISAX scope.

While legal scrambled to draft a hold‑notice, the OEM’s security contact was asking a simple question:

“Walk me through your incident playbook for prototype IP leaks in the ADAS chain.”

If your team can’t answer that confidently in a tabletop exercise, you will not like answering it in a live incident. This article shows how to build TISAX‑aligned tabletop scenarios that stress‑test those answers before auditors – or attackers – do.

---

What you’ll learn

• How to design TISAX‑aligned tabletop exercises specifically for ADAS suppliers.
• How to model a realistic prototype IP leak across a hybrid (cloud + on‑prem + partner) supply chain.
• How to layer a coordinated ransomware attack onto the same scenario without overwhelming participants.
• How to orchestrate roles, artefacts and timelines so exercises generate strong TISAX AL2/AL3 evidence.
• How to use GRC and automation tools (Sprinto, Drata, VComply, 6clicks, etc.) to capture results and drive remediation.
• How to avoid common mistakes that make tabletops theatrical but useless for TISAX maturity scoring.

---

Designing TISAX‑Aligned Tabletop Exercises for ADAS Programs

Answer first:

TISAX‑grade tabletops start from the VDA ISA catalog, not from random “cool scenarios.” For ADAS suppliers, they must explicitly cover information security, prototype protection and, if telemetry or driver data is involved, data protection objectives.

TISAX sits on top of ISO 27001 with automotive extensions. For AL2 and AL3, auditors expect maturity level ≥3: defined, implemented, and effective processes.

A good tabletop is a controlled rehearsal of those processes. It should:

• Trace back to ISA questions in the information security and prototype catalogs.
• Exercise incident management, supplier relationships, operations, and business continuity in one coherent storyline.
• Produce artefacts you can attach to controls in your GRC or automation platform.

Key Takeaway
If you can’t map a tabletop step to at least one ISA question, you’re rehearsing theatre, not TISAX.

Practical design steps

1. Anchor on assessment objectives and level

Typical ADAS scopes include:

• Information Security – Confidential or Strictly confidential.
• Prototype Protection – Proto parts / Proto vehicles / Test vehicles.
• Data / Special data – when you process driver or test‑driver telemetry.

These usually imply AL2 (remote) for pure information scopes, and AL3 (on‑site) once prototype vehicles or “Strictly confidential” data are in play.

2. Select which ISA domains to stress

For a first ADAS tabletop, focus on:

• ISMS governance & incident management.
• Supplier relationships & third‑party risk.
• Operations security (logging, monitoring, backups).
• Prototype protection (where applicable).
• Data protection (if telemetry / PII is involved).

3. Decide where automation supports the exercise

• Use Sprinto or Drata to pull live evidence on: MFA, logging status, backup jobs, and access reviews.
• Use VComply or 6clicks to tie tabletop actions back into ISA controls and risk records.
• Use OneTrust or similar privacy tooling if DSARs or breach notification workflows may trigger.

Mini‑Checklist – Before You Script Anything

• Assessment objectives and AL2/AL3 confirmed with OEM(s).
• Relevant ISA sections identified and tagged in your GRC tool.
• Current incident response and supplier escalation procedures documented.
• Tooling in place to capture evidence (tickets, logs, dashboards) during the tabletop.
• Sponsor named: who will approve follow‑up remediation?

---

Building the Hero Scenario: Prototype IP Leak in a Hybrid Supply Chain

Answer first:

Your hero scenario should be a single, vivid narrative about prototype IP leaving controlled TISAX scope, traversing suppliers and cloud services you think are covered, and landing somewhere that absolutely is not.

For ADAS suppliers, the obvious asset is prototype perception or planning code or annotated sensor datasets for an upcoming function.

The leak should travel across at least three entities: you, a cloud‑based toolchain, and a downstream partner.

Narrative spine of the hero scenario

Day 0 – Quiet misconfiguration

• A DevOps engineer at a tier‑2 partner attaches a non‑TISAX tenant to your shared ADAS repository.
• The repository contains prototype perception models and sensor clips flagged “Strictly confidential.”

Day 3 – Human error

• A senior ADAS engineer exports a subset of these clips to share with a labeling vendor.
• Instead of the agreed secure transfer, they drop them into a generic cloud drive folder reused for multiple customers.

Day 5 – Detection

• Your Netwrix Auditor or SIEM detects anomalous access patterns against the shared repository.
• Simultaneously, the OEM’s product security office emails you about a snippet of unreleased HMI visuals seen in an external UX agency deck.

Day 5+ – Escalation

• Incident response kicks in: triage, containment, supplier notifications, OEM notification, and legal assessment.

Pro Tip – Make It Visceral
Don’t say “a model file leaks.” Say: “The L4 highway‑merge planner for MY27 flagship EV is now on a contractor’s shared drive used for three OEMs.”

“Hero Scenario Visual” – How to Draw It on One Slide

Create a simple swimlane diagram your executives and auditors can grasp in seconds:

• Lanes (from top to bottom): OEM, Your ADAS Org, Tier‑2 Algorithm Partner, Labeling Vendor, Cloud Services.
• Columns: T‑3 days, T‑0 (leak), T+1h, T+24h, T+7d.
• Icons:
  • Locked folder icon for TISAX‑scoped repositories.
  • Open cloud folder icon for non‑scoped storage.
  • Red exclamation triangle for “control failure moments” (misconfiguration, policy violation).
  • Blue shield icons for specific controls that should have caught or prevented the issue (DLP, access reviews, supplier onboarding checks).

Label each transition with its corresponding ISA control ID inside your tooling (e.g., link to the custom ISA object in CyberArrow, VComply, or 6clicks).

Mini‑Checklist – Building the IP Leak Scenario

• Critical prototype or ADAS artefact clearly defined.
• At least three organizations in the chain, including one cloud provider.
• At least one intentional policy violation and one pure misconfiguration.
• Clear “detection moment” mapped to logging / monitoring controls.
• OEM notification decision point identified.

---

Layering a Ransomware Outbreak onto the Same Exercise

Answer first:

Don’t run a separate ransomware tabletop; extend the IP‑leak scenario so a crypto‑locker outbreak hits at the worst possible time. This reflects how multi‑vector incidents actually look to OEMs and TISAX assessors.

Why combine IP leak + ransomware?

• TISAX AL3 looks at business continuity and incident management under stress, not just in isolation.
• ADAS suppliers increasingly span safety‑critical dev, connected test fleets, and cloud‑native training pipelines. Ransomware against build systems or data lakes is realistic.
• Combining both scenarios forces participants to prioritise: do we restore services, contain exfiltration, or communicate first?

Example injects to overlay

Add these to the timeline above:

T+2h – First ransomware alerts

• Your SOC (or outsourced MDR) raises a high‑urgency ticket: unusual encryption activity on the file server that hosts legacy ADAS tools.
• Sprinto / Drata dashboards show several backups for that server have been failing silently for two weeks.

T+4h – Supplier impact

• Tier‑2 partner reports their CI/CD runners for ADAS components are locked. Builds for tomorrow’s vehicle software integration cannot complete.

T+24h – OEM escalation

• OEM asks for: current status, RTO/RPO for affected systems, and whether compromised environments also held prototype artefacts already in scope.

Key Takeaway
A combined scenario makes it painfully obvious whether your incident command structure is robust, or whether every function is improvising.

Avoiding overload

To keep the exercise focused and auditable:

• Cap to two technical impact domains: e.g., file server + CI/CD.
• Explicitly freeze all other noise; facilitators should block “what if the ERP is also down?” digressions.
• Keep all impacts traceable to clearly identified systems in your asset inventory and ISA mapping.

---

Orchestrating the Exercise: Roles, Timelines, and Tooling

Answer first:

A TISAX‑useful tabletop looks less like an unstructured workshop and more like a short, high‑tempo drill with clear roles, artefacts, and timestamps.

Core roles to script

• Incident Commander (IC): usually CISO or delegate. Owns prioritisation and communication.
• Technical Lead(s): ADAS platform owner, infra lead, and security engineering lead.
• Supplier Manager: responsible for TISAX expectations in contracts and escalation to partners.
• Data Protection Officer / Privacy Lead: if telemetry / PII is involved.
• Business Owner: ADAS program or product lead.
• Observer / Scribe: captures decisions, ambiguities, and time stamps.

Pro Tip – Involve Audit and GRC Early
Invite your internal audit lead or TISAX program owner as an observer. They know exactly which ISA questions your exercise should generate evidence for.

Structure the session

1. Pre‑brief (15–20 minutes)

• Scope: which systems, which suppliers, which OEM.
• Constraints: timeboxed to 90–120 minutes; only the scenario as drawn in the hero visual.
• Rules: no laptops except facilitators; no “we would check our runbook” without describing what’s in it.

2. Walk‑through (60–75 minutes)

• Move left‑to‑right across the timeline, pausing at each inject.
• Ask three consistent questions at each step:
  1. What do you see? (signals, alerts, calls)
  2. What do you do? (actions, owners, tools)
  3. What do you log? (tickets, communications, decisions)

3. Hot wash / After‑Action Review (20–30 minutes)

• Identify three strengths, three weaknesses, three quick wins.
• Link each to ISA domains and TISAX objectives on a whiteboard or virtual board.

Using tools to capture and replay

• Use your GRC suite (Archer, ServiceNow GRC, CyberArrow, VComply, 6clicks) to create a dedicated “exercise control record” per ISA domain, attaching:

  • Agenda and scenario description.
  • Participant list and roles.
  • Notes, screenshots, chat transcripts from digital whiteboards.

• Use automation platforms (Sprinto, Drata, Thoropass) during the exercise to pull live snapshots:

  • Current MFA coverage.
  • Last successful backup for key servers.
  • Vendor inventory and last due‑diligence dates for affected suppliers.

Mini‑Checklist – Orchestration Hygiene

• Clear IC and scribe appointed.
• Timeline printed / shared and visible to all.
• GRC records created before the exercise to attach artefacts.
• Automation tools connected and ready to pull live data if needed.
• AAR scheduled within 48 hours with key stakeholders.

---

Turning Findings into TISAX Evidence and Control Improvements

Answer first:

Tabletops are only as valuable as the deltas they drive into your ISMS. For TISAX, that means moving maturity scores, closing non‑conformities, and enriching evidence for AL2/AL3.

Map findings to ISA and TISAX labels

For each gap uncovered, document:

• Which ISA question(s) it corresponds to (e.g., incident process, supplier risk, prototype protection procedure).
• Which assessment objective(s) it affects (e.g., Strictly confidential, Proto vehicles, Data).
• Which site / scope in ENX terms is impacted.

Use your GRC tool to:

• Create or update risks linked to these controls.
• Attach the tabletop artefacts as mitigation testing evidence even if the control failed; auditors value demonstrated learning cycles.

Key Takeaway
A well‑documented exercise can sometimes compensate for a partial control gap by evidencing PDCA (Plan-Do-Check-Act) and continuous improvement.

Drive structured remediation

Turn AAR items into:

• Work items in your GRC / ticketing system with owners, due dates, and acceptance criteria.
• Policy updates (e.g., clarifying how suppliers must use TISAX‑scoped tenants, or how ADAS engineers share datasets externally).
• Playbook updates for incident response, business continuity, and supplier escalation.

Automation tools help here:

• Sprinto’s risk mapping can show which controls will improve multiple frameworks (TISAX, ISO 27001, maybe SOC 2).
• Drata’s cross‑framework mapping reduces duplicate work when a single fix affects several standards.
• OneTrust or Transcend can embed privacy‑specific fixes (e.g., DSAR handling in breach scenarios).

Mini‑Checklist – Turning Lessons into TISAX Maturity

• Every gap linked to an ISA question and a risk record.
• At least one measurable KPI per major gap (e.g., backup success rate, time‑to‑escalation).
• Follow‑up control tests scheduled (could be another mini‑tabletop).
• Evidence (minutes, screenshots, emails) attached to GRC records.
• Updated maturity scores reflected in your next internal ISA self‑assessment.

---

The Counter-Intuitive Lesson Most People Miss

Most teams design tabletops to “prove” their incident process works. Under TISAX, the more powerful outcome is often the opposite: to prove where it does not work – and to show a credible path to fix it.

Auditors at AL2 and AL3 are less impressed by flawless role‑play than by:

• Honest identification of breakdowns (e.g., suppliers not on call‑trees, unclear OEM notification thresholds).
• Evidence that findings are fed back into the ISMS via risk registers, policy updates, and re‑tests.
• Demonstrated use of tools (GRC plus automation) to institutionalise those lessons.

Organizations that script only “heroic” responses tend to:

• Over‑estimate maturity in ISA self‑assessments.
• Get surprised by non‑conformities when auditors interview engineers and partners.
• Miss systemic supplier or prototype‑handling weaknesses.

Those that allow tabletops to fail in a controlled way – and then encode those failures into the system of record – often score better on TISAX maturity, even with similar technical stacks.

---

Evolving Your Scenario Library for 2025–2027

Answer first:

Your 2025 hero scenario should not be your 2027 hero scenario. ADAS, connectivity, and regulatory expectations are shifting; your tabletop library must follow.

Scenario themes to add over time

• NIS2‑aligned outages: combine ransomware with OT impact on test tracks or hardware‑in‑the‑loop rigs.
• Cloud region failures: stress multi‑region resilience for ADAS training clusters, especially where cloud providers have their own TISAX attestations.
• Data protection incidents: erroneous sharing of labeled camera streams containing faces or plates, triggering privacy‑by‑design and breach notification workflows.
• Supplier insolvency or acquisition: sudden change in a key ADAS partner’s risk profile and TISAX status.

Pro Tip – Version Your Scenarios Like Code
Keep scenario definitions in source control; note which TISAX assessment cycle they were used for and which ISA revision they target.

Integrating with upcoming frameworks

As ENX aligns TISAX more visibly with NIS2 and expands into vehicle cybersecurity (e.g., ENX VCS), look for:

• Updated ISA versions you can import into 6clicks, VComply, or Archer.
• New control mappings in Sprinto / Drata for OT, telematics, and AI governance domains.
• Opportunities to run joint tabletops that satisfy both TISAX and internal CSMS (cybersecurity management system) objectives.

---

Key Terms mini-glossary

• TISAX – The Trusted Information Security Assessment Exchange, an ENX‑governed scheme based on the VDA ISA used to assess and share information security posture in the automotive supply chain.
• VDA ISA – The VDA Information Security Assessment catalog used as the normative requirements set for TISAX, aligned with ISO 27001 and extended for automotive topics like prototype protection.
• Assessment Level (AL1–AL3) – TISAX assurance depth levels: AL1 self‑assessment, AL2 remote plausibility check, AL3 full on‑site audit.
• Assessment Objective – A TISAX label component describing what is protected (e.g., confidential information, prototype vehicles, data / special data).
• Prototype Protection – ISA catalog domain covering secure handling of prototype parts, vehicles, tests, and events, usually requiring AL3.
• GRC Platform – Governance, Risk and Compliance software (e.g., ServiceNow GRC, Archer, CyberArrow, VComply, 6clicks) used to manage frameworks, risks, and evidence.
• Compliance Automation Platform – SaaS tools (e.g., Sprinto, Drata, Thoropass) that continuously collect evidence and monitor controls across cloud and SaaS environments.
• Continuous Control Monitoring (CCM) – Automated validation that controls (backups, access, logging, etc.) are operating effectively, often fed by integrations to IAM, SIEM, and infrastructure.
• ENX Portal – The central ENX‑operated platform where organizations register, define scopes, connect with accredited auditors, and share TISAX results.
• Tabletop Exercise – A facilitated, discussion‑driven simulation of an incident or crisis used to rehearse roles, decisions, and processes without touching production systems.

---

FAQ

Q1: How often should ADAS suppliers run TISAX‑focused tabletop exercises?

At least annually for each critical scope, and additionally before major TISAX assessments or when there are significant changes in architecture, suppliers, or OEM requirements.

Q2: Do auditors expect to see tabletop evidence during AL2 assessments, or only at AL3?

Evidence of rehearsed incident and continuity processes strengthens maturity arguments at both AL2 and AL3. At AL3, auditors are more likely to probe details of recent exercises.

Q3: Which tools are most useful during the exercise itself, versus before and after?

During the exercise, automation platforms like Sprinto or Drata help by pulling live data (backups, MFA, vendor lists). Before and after, GRC suites like Archer, CyberArrow, VComply, 6clicks, or ServiceNow GRC are key for mapping scenarios to controls, capturing artefacts, and tracking remediation.

Q4: How can tabletops help with data‑protection‑focused TISAX objectives?

By explicitly rehearsing telemetry or PII breaches – including detection, legal assessment, OEM communication, and regulator notification – and by integrating privacy platforms such as OneTrust or Transcend into the workflow.

Q5: Our suppliers are at mixed levels of TISAX maturity. Should we still include them in exercises?

Yes. Joint tabletops are one of the best ways to reveal gaps in supplier contracts, contact paths, and technical integration – and to generate concrete improvement actions for your third‑party risk program.

Q6: Can we reuse ISO 27001 incident scenarios for TISAX?

You can reuse core mechanics, but you should adapt them to automotive realities: prototype vehicles, shared development environments with OEMs, and hybrid cloud/on‑prem chains.

Q7: How detailed should the “hero scenario visual” be for executives?

One slide. If you need more than a simple swimlane with a handful of icons and timestamps to tell the story, it is probably too complex for steering‑committee and OEM discussions.

---

Conclusion

The incident that opens this article is fictional – but every element is common in ADAS programs: prototype algorithms, hybrid supply chains, cloud repositories, and OEMs who now treat TISAX as table stakes.

Well‑designed tabletop exercises are where you find out, safely, whether your TISAX‑aligned processes, your GRC stack, and your automation tools can cope with a prototype IP leak and a ransomware blast at the same time.

They translate abstract ISA questions into concrete muscle memory across engineering, security, and supplier management.

Close the loop by treating each exercise as both a rehearsal and a data‑gathering mission:

1. Feed outcomes back into your ISO 27001‑based ISMS.
2. Update TISAX‑relevant controls.
3. Capture rich evidence in your platforms.

Do that consistently from 2025 onward, and the next time an OEM security lead calls mid‑incident, the story you tell will be one you have already practised – and improved – many times before.