TISAX AI Controls Mapping: Objective, Owner, Test and Evidence

TISAX assesses information security through the VDA Information Security Assessment catalogue and exchanges standardized result summaries among registered participants. AI has no separate TISAX module in the current VDA ISA workbook, version six point zero point three. A hosted model enters the assessment as an IT service, external service, supporting asset and network destination inside a defined scope.

A useful TISAX AI controls mapping adds six implementation fields to each verified ISA family: objective, owner, control point, test, evidence and coverage. I use Full for a control enforced on authenticated HTTP model traffic, Partial for a contribution or evidence source, and Outside for work owned elsewhere.

Scope and ISMS management

ISA basis: the ISMS management control covers scope, management approval, applicable controls and effectiveness review.

Objective: place every AI service, dependency and owner inside a declared assessment boundary.

Owner: ISMS manager with executive approval.

Implementation and test: register the application, model endpoints, cloud tenant, identity provider, retrieval sources, policy service and record store. Select one production request and trace every component against the scope diagram.

Evidence: registered scope, service architecture, applicable-control determination and management review.

Coverage verdict: Partial coverage reflects the fact that runtime traffic can reveal model endpoints and policy use, while scope approval and ISMS governance stay outside the request path.

Information assets and approved external services

ISA basis: the external IT service control addresses evaluated and approved services. The information-asset controls connect protection needs to the systems and services that process them.

Objective: allow AI services only after approval for the relevant information class and use.

Owner: information owners, procurement and security.

Implementation and test: map each information class to approved providers, models, regions and purposes. Reconcile the approved list against thirty days of observed HTTP model traffic. The team should investigate every unknown destination.

Evidence: information-asset register, provider assessment, service approval, endpoint inventory and reconciliation output.

Coverage verdict: Full for destination enforcement on routed HTTP model traffic. Asset valuation, procurement and approval receive Partial evidence and remain owned by their respective functions.

Information security risk management

ISA basis: the risk-management control calls for regular and event-triggered assessment, documented risks, named owners, treatment measures and reassessment after environmental change.

Objective: record and treat the security risks created by each AI use case.

Owner: the business risk owner with security.

Implementation and test: cover information disclosure, excessive agent authority, unapproved model use, provider outage, lost identity context, missing records and supplier change. Change the model route in a test environment and confirm that the risk reassessment and approval workflow starts.

Evidence: risk record, criteria, treatment plan, acceptance, review history and change ticket.

Coverage verdict: Partial coverage reflects how request records provide frequency, destination and control-outcome facts, while risk methodology and acceptance sit outside an HTTP gateway.

User access and delegated authority

ISA basis: the secure user-access control addresses risk-based authentication and stronger procedures for privileged access.

Objective: tie each model request to an authenticated originating principal and an approved role.

Owner: IAM and AI platform engineering.

Implementation and test: propagate the employee or agent identity through the workload making the model call. Attempt an approved request, a disabled identity and an expired delegation. Preserve the policy result for each event.

Evidence: identity mapping, role grant, delegation record, permit event and denial events.

Coverage verdict: Full for per-request authorization when identity reaches the HTTP boundary. Identity proofing, joiner-mover-leaver processes, MFA and privileged-access administration remain Outside.

Event logging and escalation

ISA basis: the event-logging control covers requirements, external-service monitoring options, regular analysis, escalation and protection against alteration.

Objective: reconstruct which principal sent which information class to which model under which policy.

Owner: security operations and AI platform engineering.

Implementation and test: write an independent record containing event ID, principal, role, workload, classification, endpoint, model, policy version, decision and timestamp. Alter one exported field and verify the integrity check fails. Query denied requests and exercise the escalation path.

Evidence: schema, signed record sample, integrity result, monitoring query, alert and incident ticket.

Coverage verdict: Full for routed HTTP AI traffic. Endpoint, operating-system, SaaS administration and cloud control-plane logs remain Outside and should feed the wider monitoring design.

Network management and data-loss controls

ISA basis: the network-management control addresses segmentation, internet-accessible services, external-service separation, attack detection and prevention of data loss or leakage.

Objective: restrict outbound model traffic to approved routes and limit the information each route may carry.

Owner: network security and AI platform engineering.

Implementation and test: route model API traffic through the inspection point, classify the payload and apply endpoint policy. Send a synthetic protected value to an unapproved host and induce an evaluator timeout. Both events should receive the configured restrictive result.

Evidence: route configuration, classification policy, denial records, timeout test and alert.

Coverage verdict: Full on authenticated HTTP model traffic that is actually routed through the gateway. General network segmentation, DNS control, cloud firewall configuration and non-HTTP egress stay Outside.

Security in new and changed AI services

ISA basis: the secure-development control addresses information security requirements during development or acquisition, approval testing, secure configuration and tests after significant changes.

Objective: make security acceptance part of each AI service release.

Owner: service owner, platform engineering and security testing.

Implementation and test: define identity, data-class, destination, failure, logging and retention criteria before release. Run those tests on a new model or tool route and require approval before production traffic begins.

Evidence: requirement specification, secure configuration, test results, finding log, approval and rollback record.

Coverage verdict: Partial coverage reflects how a gateway runs request-path acceptance tests, while secure development, code review, dependency testing and cloud configuration need separate evidence.

Supplier assurance and responsibility allocation

ISA basis: the supplier controls address risk, contractual security, service evidence, shared responsibilities, configuration and proof that providers fulfill their assigned duties.

Objective: assign every security task for the hosted AI service and verify the provider evidence appropriate to the protection need.

Owner: procurement, legal, security and the service owner.

Implementation and test: map provider security, tenant configuration, identity propagation, model routing, monitoring, deletion, incident notification and continuity. Run one incident scenario and verify each owner performs the assigned handoff.

Evidence: contract requirements, supplier assessment, service report, responsibility matrix, configuration record and exercise result.

Coverage verdict: Partial coverage reflects how runtime records show the destination and the organization's enforcement decisions, while contracts, provider assurance and supplier governance sit Outside.

Internal review and maturity evidence

ISA basis: the internal-review control addresses policy observance, technical requirements, retained results and corrective measures. The current workbook sets target maturity level 3 across the information security questions.

Objective: prove the mapped controls operate as an established process over time.

Owner: internal audit or an independent ISMS reviewer.

Implementation and test: sample permits, denials, redactions, failures and post-change events across two policy versions. Reconstruct each event through identity, service approval, risk treatment and supplier responsibility. Track every finding to verified closure.

Evidence: audit plan, sample query, evidence bundle, findings, corrective actions and closure test.

Coverage verdict: Partial coverage reflects how the request path supplies repeatable operating evidence, while audit independence, sampling judgment and management follow-up remain Outside.

Coverage table

• ISMS scope: ISMS and Executive own governance, and tracing one request to the registered scope yields Partial coverage.
• Assets and external services: Information Owners and Procurement own approval while Platform owns the route, so comparing approved and observed hosts yields Full coverage for route enforcement and Partial coverage for approval.
• Risk management: the Risk Owner and Security own the risk process, and a route-change reassessment yields Partial coverage.
• User access: IAM and Platform own identity and request policy, so tests of disabled and expired users yield Full coverage on the request and Outside coverage for IAM administration.
• Event logging: SOC and Platform own the independent record writer, and altering one field before querying denials yields Full coverage on routed traffic.
• Network management: Network and Platform own the HTTP egress boundary, so host, payload and timeout tests yield Full coverage on the routed request and Outside coverage for general network administration.
• New or changed service: the Service Owner and Security own the release gate, and new-model acceptance tests yield Partial coverage.
• Supplier assurance: Procurement and the Service Owner own contracts and configuration, and an incident-handoff test yields Partial coverage.
• Internal review: Internal Audit owns the ISMS review, and a sample across policy versions yields Partial coverage.

The table has three Full runtime rows and zero rows that turn wholly green through a gateway purchase. That is the honest mapping. My opinion is that any vendor diagram coloring supplier assurance, risk acceptance and IAM administration green has confused a useful evidence source with the whole control.

A yellow sticky note marked Partial is more valuable than a green architecture slide when it points to a named owner and a test date.

Transition to ISA2027

ENX has published ISA2027 for assessments ordered in 2027, while ISA 6 remains available for assessments ordered before 1 January 2027 under the transition information on the ENX download page. Keep the version used by the assessment in the mapping header. Treat the new catalogue as a controlled change: compare applicable requirements, assign owners, update tests and preserve the approved delta.

This article maps the verified control families in the current ISA 6 workbook that apply to AI services. It avoids inventing a TISAX AI control set. The TISAX AI compliance checklist turns these rows into completion tests, and the TISAX AI audit evidence guide packages their artifacts for assessor sampling.

HTTP boundary and adjacent controls

The Full verdicts apply only to authenticated HTTP traffic sent to LLM endpoints through the enforcement point. This boundary supports identity-aware request decisions, information classification, model-destination policy, response inspection and independent records.

Local model execution, non-HTTP tools, stolen credentials used outside the routed path, endpoint compromise, cloud IAM configuration, supplier contracts, workforce training, physical security and business continuity require adjacent controls. Output correctness, bias evaluation and human review also sit elsewhere. The mapping keeps those responsibilities visible instead of assigning them to request inspection.

DeepInspect

DeepInspect is the enforcement point behind the Full request-path verdicts. It sits inline between authenticated users or agents and HTTP-based LLM endpoints, evaluating identity, role, information classification, destination and policy before the model receives the request. An evaluator failure meets a fail-closed default, and every decision creates a signed, tamper-evident record outside the calling application's write path.

Against this mapping, DeepInspect enforces approved model routes, binds the originating principal, classifies outbound content, records permits and denials, and supplies samples for incident response and internal review. ISMS governance, risk acceptance, IAM administration, secure development, supplier contracts and continuity stay with the owners named above. Book a technical deep dive at deepinspect.ai.