TISAX AI Compliance Checklist: 12 Owner-Based Completion Tests

The current VDA Information Security Assessment workbook, version six point zero point three, asks for objective evidence that information security processes work inside the assessment scope. Its target maturity level is 3, Established, for every information security control question. An AI policy signed in May shows intent. A model request recorded at 02:14 shows operation.

This TISAX AI compliance checklist puts twelve tests in dependency order. Each item names an owner, an observable completion condition and the artifact to retain. I use TISAX here as the ENX assessment and exchange mechanism, rather than describing it as a law or a standalone AI standard.

1. Freeze the AI assessment scope

Owner: ISMS manager with AI platform engineering.

Done when: the registered scope identifies every location, process, cloud tenant, model endpoint, gateway, identity service, retrieval store and log repository involved in the AI use case. A reviewer can trace one production request through the diagram and mark every component as inside or outside scope.

Keep: scope registration, architecture diagram, asset boundary and named owners.

2. Inventory information and supporting assets

The current ISA workbook treats information assets and the systems or services processing them as linked records. AI prompts often combine customer files, source code and prototype details inside one context window.

Owner: information owners with asset management.

Done when: each AI use case links its information classes to the application, retrieval source, model route, provider and record store. The inventory includes confidentiality, integrity and availability needs plus an owner for every asset.

Keep: information-asset register, supporting-asset map and classification decision.

3. Approve each external AI service

The external IT service control addresses evaluated and approved services, including documented approval and periodic verification of actual use.

Owner: procurement, security and the business service owner.

Done when: each model provider and endpoint has a risk assessment, permitted use, approved information classes, processing location, contractual review and expiry date. Thirty days of observed HTTP model traffic reconcile against the approved list, with every unknown host assigned for blocking or review.

Keep: service approval, provider assessment, endpoint inventory and reconciliation output.

4. Assign and treat AI security risks

The risk-management control calls for documented risks, risk owners, treatment measures and reassessment after relevant changes.

Owner: the named risk owner.

Done when: the register covers prompt disclosure, unauthorized destinations, excessive agent authority, provider outage, missing logs, identity loss and supplier change. Each risk has criteria, treatment, due date and residual decision. A model or routing change triggers reassessment through the change process.

Keep: risk record, treatment plan, acceptance decision and change-trigger evidence.

5. Bind every request to an originating identity

The secure user-access control addresses risk-based authentication. A service credential alone identifies the workload making a model call.

Owner: IAM and AI platform engineering.

Done when: a sampled request resolves to the employee or agent that initiated it, the workload that relayed it, the role in force and the role approval. A disabled identity and an expired delegation both receive the configured restrictive outcome.

Keep: identity mapping, role approval, permit record and denial record.

6. Restrict model destinations by role and information class

The service approval in item 3 becomes operational at the outbound request. The policy should connect an authenticated principal, information class and approved model route.

Owner: AI platform engineering with information-owner approval.

Done when: a purchasing agent can send an approved supplier summary to its assigned model, while a request containing synthetic prototype data to a general-purpose endpoint is refused. Both outcomes name the policy version and destination.

Keep: route policy, classification test, permit event, denial event and exception register.

7. Write and protect an independent event record

The ISA event-logging control covers requirements, analysis, escalation and protection against alteration.

Owner: security operations and AI platform engineering.

Done when: every sampled HTTP model request has one record containing event ID, originating identity, role, data class, endpoint, model, policy version, outcome and synchronized timestamp. The application making the call has no custody of the record write path, and an integrity test detects an altered field.

Keep: schema, sample export, signature test, access list and retention setting.

8. Test the service under failure and change

The secure-development control addresses requirements in new or changed IT systems and approval testing before productive use.

Owner: service owner with security testing.

Done when: release tests cover an unknown endpoint, missing identity, evaluator timeout, unclassified payload and policy rollback. The model request receives the approved restrictive result during each failure. A production change links to its test record and approval.

Keep: release criteria, test payloads, decision records, approval and rollback evidence.

9. Allocate supplier responsibilities

The ISA supplier controls address assurance and the division of responsibilities with external IT service providers.

Owner: procurement and the service owner.

Done when: the responsibility matrix assigns provider security, tenant configuration, identity propagation, information classification, model routing, incident notification, deletion and continuity. The team tests one provider incident against that matrix and records each handoff.

Keep: contract requirements, supplier evidence, responsibility matrix, service report and incident contacts.

10. Exercise AI incident handling

The ISA incident controls expect reporting channels, prioritization, assigned responders, escalation and lessons learned. An AI incident needs a bounded request set before those processes can work.

Owner: incident response with the ISMS manager.

Done when: a tabletop involving classified prompts sent to an unapproved endpoint produces affected identities, destinations, information classes, policy outcomes and timestamps within one working day. The team categorizes the event, escalates it and records containment plus follow-up actions.

Keep: tabletop plan, request query, incident record, timeline and remediation owner.

11. Test continuity for the AI service

Availability requirements extend past the model provider. Identity, policy evaluation, routing and evidence storage all sit in the service dependency chain.

Owner: business continuity and the service owner.

Done when: the continuity plan identifies the service impact, recovery sequence, provider dependency and communication owner. A test removes the primary model route and verifies the approved failover or stop condition without bypassing identity, classification, policy or event recording.

Keep: business impact record, continuity plan, test results and recovery actions.

12. Run an internal review across time

The ISA internal-review control asks organizations to review policy observance and technical requirements, retain results and pursue corrective measures. The TISAX Participant Handbook explains how the maturity model shapes assessment preparation and results.

Owner: internal audit or an independent ISMS reviewer.

Done when: the review samples permitted, denied, redacted, failed and post-change requests across at least two policy versions. Every event reconstructs through identity, service approval, risk treatment and supplier responsibility. Findings have an owner, due date and verified closure.

Keep: review plan, sampling query, evidence bundle, findings and closure proof.

Completion register

Use one row per test result. Link to the actual artifact rather than a project board.

• ISMS and Platform, item 1: record Pass or Gap, link the scope and request-path diagram, and set a due date.
• Procurement and Security, item 3: record Pass or Gap, link the service approval and route check, and set a due date.
• IAM and Platform, item 5: record Pass or Gap, link the identity chain and two decisions, and set a due date.
• SOC and Platform, item 7: record Pass or Gap, link the record sample and integrity test, and set a due date.
• Incident Response and ISMS, item 10: record Pass or Gap, link the tabletop and bounded event set, and set a due date.
• Internal Audit, item 12: record Pass or Gap, link the sample and finding closure, and set a due date.

My preference is to start with item 7. A whiteboard photograph full of green arrows describes the intended route. The independent event record shows the route that a production agent used, under the policy that existed at that second.

Work outside the HTTP boundary

Items 5 through 8 cover the slice visible on authenticated HTTP traffic to LLM endpoints. A gateway can classify that traffic, enforce role and destination policy, refuse a request and preserve a decision record.

The broader TISAX assessment scope also includes management approval, personnel qualification, physical protection, endpoint security, software inventory and patching, cloud IAM administration, supplier contracts, business continuity and internal audit. Model evaluation and human review of generated decisions require their own controls. Assign those tasks to the owners above and keep their evidence beside the runtime records.

The TISAX AI audit evidence guide packages the artifacts for sampling. The TISAX AI controls mapping gives each family a coverage verdict.

DeepInspect

DeepInspect supplies the control point for items 5 through 8 and runtime evidence for items 3, 10 and 12. It sits inline between authenticated users or agents and HTTP-based LLM endpoints. Each request is evaluated against identity, role, information classification, destination and policy with a fail-closed default, then written as a signed, tamper-evident decision record outside the calling application's custody.

That component provides the identity chain, route reconciliation, classification result, permit or denial, failure behavior and bounded incident set. Scope registration, risk acceptance, supplier contracting, IAM administration, continuity planning and internal audit remain with their named owners. Book a technical deep dive at deepinspect.ai.