TISAX ISA2027 for Suppliers Who Host Their Own Systems

If a German OEM is in your customer list, TISAX arrives eventually — usually as a contract line naming a label you must hold before the next programme starts. Not a certification you buy once, but an assessment by an ENX-accredited audit provider against the VDA Information Security Assessment catalogue, bound to named locations and asking where information sits.

That assumption is the whole story for infrastructure teams. On someone else's platform, "where is the data" is answered by a contract and a region name. On infrastructure you run, it is a rack, a room and a door — and the catalogue turns that into which controls apply at all.

TISAX, VDA ISA, and the 2027 deadline you are actually on

Two things get conflated. TISAX is the exchange mechanism — the ENX process, the audit providers, the labels, the portal. VDA ISA is the questionnaire it runs against: controls phrased as questions, scored on a five-step maturity model. The Definitions tab sets the target maturity level for every control consistently at 3 (Established), which the Maturity levels tab defines as a standard process integrated into the overall system, with evidence of sustained and active use over an extended period.

Read that as a schedule, not a paragraph. A policy written the week before an assessment cannot evidence sustained use. Every artefact below is dated and repeated for that reason.

The catalogue is mid-transition and the dates are firm. ENX's release note states that ISA 6 was released in October 2023, effective for assessments ordered from 1 April 2024, and that ISA2027 applies to all TISAX assessments ordered from 1 January 2027 onwards. Assessments ordered before 2027-01-01 can still run on ISA6, whose final initial-assessment opening date ENX gives as March 2027. ISA2028 is announced for summer 2027, and labels keep their three-year validity.

The definition that decides everything: outside the audit scope

The VDA ISA glossary entry for *Cloud/external IT service* reads: "An external IT service is the processing of company information outside the audit scope." Its examples name cloud services such as AI tools (AI chatbots, AI agents), hosting, web services such as anti-virus dashboards, and SIEM services provided by external companies.

Note what is absent. Not "a service you do not own." Not "anything in a public cloud." The test is where processing happens relative to the audit scope — and the TISAX standard scope description (version 2.0) binds that to the listed assessment objectives at the listed locations. Ownership appears in neither sentence, and this is no ISA2027 innovation: ISA 6.0.3 is almost identical.

Four ISA2027 controls are written about external IT services specifically. 1.3.3: not used without explicit assessment and implementation of the information security requirements, harmonized with the protection need of the processed information assets. 5.3.3: a defined and implemented return-and-secure-removal procedure for each one. 5.3.4: effective segregation preventing access to your own information by unauthorized users of other organizations. 6.1.3: responsibilities between provider and your own organization defined, with mechanisms for shared responsibilities.

A Kubernetes cluster in a listed room is not an external IT service, so those four do not attach. The rest of the catalogue does, undiminished — the logic of ISO 27001 Annex A when nothing is inherited: you stop importing someone else's control and start owning it.

Click to zoom

AL 2 vs AL 3: more verification, not necessarily more total effort

You rarely pick an assessment level directly; you pick assessment objectives and they imply one. Handbook v2.8 section 4.3.3.5 maps them: *Confidential*, *High availability*, *Test vehicles*, *Proto events* and *Data* imply AL 2; *Strictly confidential*, *Very high availability*, *Proto parts*, *Proto vehicles* and *Special data* imply AL 3. *Info high* and *Info very high* still appear in the Handbook's tables, but were selectable only until 31 March 2024 and replaced from 1 April 2024 by the two *confidential* objectives.

The Handbook's method table is unambiguous. Evidence moves from a plausibility check at AL 2 to thorough verification at AL 3; interviews from web conference to in person, on site; on-site inspection from *at your request* to *yes*. At AL 3 the audit provider examines documents and evidence, holds planned interviews with process owners, observes local conditions and process execution, and conducts unplanned interviews with process participants.

Both Handbook statements matter. Section 4.3.3.5 says a higher assessment level increases the effort that goes into the assessment. It also says AL 3 efforts are not generally higher than AL 2 — because AL 2 usually requires a more comprehensive self-assessment and better internal documentation, while at AL 3 demonstrating how you work, plus basic documentation, often suffices.

One asymmetry to plan around: the Handbook states an audit provider cannot use AL 2 results as the basis for an AL 3 upgrade, which costs essentially the same as an initial assessment. The hedge is the AL 2.5 method — a full remote assessment, still formally AL 2 but methodically compatible with AL 3, so a later upgrade needs only the on-site activities.

Asset inventory: what a cluster can and cannot prove

Control 1.3.1 asks to what extent information assets are identified and recorded, and this is where infrastructure teams overclaim. Its must column carries two requirements:

• "Information assets and other assets where security is relevant to the organization are identified and recorded."
• "The supporting assets processing the information assets are identified and recorded."

The glossary separates the terms deliberately. An *information asset* is information of relevant value to the organization — business secrets, critical business processes, know-how, patents. *Supporting assets* store, process and transport them: IT systems, IT services and providers, mobile storage, paper documents.

A cluster export answers the second requirement, excellently. It cannot answer the first: no command knows the CAD volume holds a customer's pre-series body-in-white. Nor is it the catalogue of relevant information assets — that, with supporting assets assigned, an owner named and regular review, sits in 1.3.1's *should* column.

#!/usr/bin/env bash
# supporting-assets-export.sh
#
# Covers ISA2027 control 1.3.1, SECOND must-requirement ONLY: "The supporting
# assets processing the information assets are identified and recorded."
# Does NOT answer the FIRST must (the information assets), nor produce the
# information-asset catalogue (a SHOULD-requirement of 1.3.1).
set -euo pipefail

CTX="${1:?usage: supporting-assets-export.sh <kube-context> <out-dir>}"
DIR="${2:?missing <out-dir>}/$(date -u +%Y-%m-%dT%H-%M-%SZ)"
mkdir -p "$DIR"

kc() { kubectl --context "$CTX" "$@"; }

kc get nodes -o json > "$DIR/nodes.json"
kc get namespaces,persistentvolumes,storageclasses -o json > "$DIR/cluster.json"
kc get deployments,statefulsets,daemonsets,cronjobs \
  --all-namespaces -o json > "$DIR/workloads.json"

# Digests, not tags. A tag is a label someone can move; a digest is identity.
kc get pods --all-namespaces -o json | jq '[
  .items[].status.containerStatuses[]? | {image: .image, imageID: .imageID}
] | unique' > "$DIR/image-digests.json"

( cd "$DIR" && sha256sum ./*.json > SHA256SUMS )
printf 'wrote %s\n' "$DIR"

Run it on a schedule, keep the dated directories, and *used sustainably and actively over an extended period* becomes a directory listing, not an argument. The link to the first requirement is a column in the asset register naming which namespace holds which information asset — a reviewed human decision the export evidences.

Approved software and approved services: 1.3.3 and 1.3.4 in practice

1.3.4 asks to what extent only evaluated and approved software is used. Its must-requirement is that software is approved before installation or use, considering four aspects: limited approval for specific use-cases or roles, conformance to the information security requirements, software use rights and licensing, and source/reputation of the software — and it applies to special purpose software such as maintenance tools too.

Three of those four are decisions and records. One — source — is enforceable in the cluster, turning an assertion in a binder into a control that produces logs. The Kyverno and OPA Gatekeeper comparison covers the engine choice; the policy below targets Kyverno v1.19.0.

# Enforces ONE aspect of ISA2027 control 1.3.4: "Source/reputation of the
# software". The other three aspects of the same must-requirement are decisions
# and records held elsewhere. Validated against Kyverno v1.19.0; failureAction
# lives under validate, as spec.validationFailureAction is deprecated.
# ClusterPolicy itself is deprecated as of Kyverno v1.19 and removed in v1.20 —
# plan the move to the CEL-based ValidatingPolicy.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: approved-image-sources
  annotations: { isa2027.control: "1.3.4" }
spec:
  background: true
  rules:
    - name: images-from-internal-registry-only
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: >-
          Images must come from registry.internal.example.com. Record the
          approval under ISA2027 1.3.4 before adding a source.
        pattern:
          spec:
            =(ephemeralContainers):
              - image: "registry.internal.example.com/*"
            =(initContainers):
              - image: "registry.internal.example.com/*"
            containers:
              - image: "registry.internal.example.com/*"

1.3.3 is the sibling for services, and the exemption is narrower than it feels. Your cluster is in scope; the hosted SIEM watching it is not, and neither is the AI assistant a developer pasted a stack trace into — ISA2027 added AI tools, chatbots and agents to its glossary examples. Its should column asks four things: procurement, commissioning and release requirements fulfilled; a release procedure keyed to the protection need; services and approvals documented; regular verification that only approved ones run.

The exit ramp is a control: 5.3.3 and 5.3.4

5.3.3 asks to what extent return and secure removal of information assets from external IT services is regulated. Its must-requirement has a sharp edge: a procedure for return and secure removal from each external IT service is defined and implemented. One per service.

That is an exit ramp written into a compliance catalogue — the instinct behind pricing your exit as a number rather than calling it a risk. Every external service you keep is another record to maintain and re-test; every one you bring inside the scope removes one.

# ISA2027 5.3.3 return-and-secure-removal record.
# Required for EXTERNAL IT SERVICES only — processing outside the audit scope.
service: hosted-siem
classification: confidential
audit_scope: outside            # this is what makes the record required
information_assets_processed: [Security event logs, location DE-01]

return:
  mechanism: Tenant export API, NDJSON, gzip, per-index
  format_is_reusable: true      # ingestible on-premises
  contractual_clause: MSA schedule 4, section 4.2
  tested_on: 2026-07-14

secure_removal:
  mechanism: Documented tenant deletion, provider deletion attestation
  backup_expiry_days: 35        # removal is not complete until this elapses
  verification: Re-query tenant API after deletion; expect HTTP 404

owner: Head of Information Security
next_review: 2027-07-14

5.3.4 is where precision pays. Its Objective column says a clear segregation between tenants must be maintained within external IT services. Its must-requirement is narrower: effective segregation, for example segregation of customers, prevents access to own information by unauthorized users of other organizations. Quote the objective at an assessor as if it were the requirement and you widen your obligation for free. For genuinely external services the honest answer is the provider's segregation concept plus a risk assessment — Schrems II in a different costume.

Shared responsibility written down: 1.2.4 is now 6.1.3

ISA2027's change history records that control ID 1.2.4 became 6.1.3, moving from *Organization of Information Security* into *Supplier Relationships*. Re-label existing evidence; the substance is intact. Its must-requirements: the IT services concerned are identified; relevant security requirements determined; the organization responsible for each defined and aware of its responsibility; mechanisms for shared responsibilities specified and implemented; and that organization fulfils them.

"Defined and aware of its responsibility" is the phrase to sit with. A provider's shared-responsibility diagram is not evidence that anyone on your side knows which half is yours. What satisfies it is a matrix per external service naming a person on your side and the requirement they own — the artefact that also carries weight in SOC 2 evidence work, where the auditor wants an owner, not a policy.

Prototype protection is physical, and ISA2027 rebuilt it

If your assessment objectives include *Proto parts* or *Proto vehicles*, the Prototype Protection module applies — and ISA2027 restructured it more than anything else in the catalogue. The change history states that all prototype protection controls have been rearranged and controls 8.3 to 8.5 deleted: in ISA 6.0.3, *Handling of vehicles, components, and parts*, *Requirements for trial vehicles*, and *Requirements for events and shootings*.

Click to zoom

The swap catches people mid-migration: ISA6's 8.1 Physical and Environmental Security becomes ISA2027's 8.2, and ISA6's 8.2 Organizational Requirements becomes ISA2027's 8.1, gaining new controls 8.1.1, 8.1.2, 8.1.4, 8.1.11, 8.1.12 and 8.1.13. An evidence index keyed on control ID silently mis-files everything unless it is remapped.

One control deserves a warning, because its wording invites an infrastructure reflex. 8.2.7 asks "To what extent is on-site client segregation existent?" — its must-requirement is spatial separation through personnel, organizational or technical measures, considering customers and/or projects, with explicit customer approval where it is not in effect. That is walls, sightlines and visitor routing, not multi-tenancy. A NetworkPolicy is a wrong answer to a physical question, even though default-deny segmentation answers several Information Security controls elsewhere.

Every sub-bullet is now an evidence obligation

The ISA2027 change most likely to alter how an assessment feels is a definition. The Definitions tab formalises a phrase that runs throughout the catalogue, turning every occurrence into questions with expected answers.

"We considered it" is no longer a sentence; it is a record. Hold it next to the thing it describes, in version control, so the reasoning outlives its author.

# aspects-considered/1.3.4-software-approval.yaml
control: "1.3.4"
requirement_text: Software is approved before installation or use.
decided_on: 2026-08-14
decided_by: Head of Platform Engineering
review_interval_months: 12

aspects:
  - aspect: Limited approval for specific use-cases or roles
    implemented: partial
    reasoning: >-
      Cluster-admin tooling approved for the platform group only, by RBAC;
      developer tooling organisation-wide.
    evidence: evidence/rbac/2026-08-14/clusterrolebindings.json

  - aspect: Conformance to the information security requirements
    implemented: true
    reasoning: Images are scanned and signed; admission rejects unsigned ones.
    evidence: evidence/registry/2026-08-14/signing-policy.yaml

  - aspect: Software use rights and licensing
    implemented: true
    reasoning: Licence gate in the intake checklist, extracted from the SBOM.
    evidence: evidence/sbom/2026-08-14/licence-report.csv

  - aspect: Source/reputation of the software
    implemented: true
    reasoning: Enforced — only registry.internal.example.com is permitted.
    evidence: evidence/kyverno/2026-08-14/approved-image-sources.yaml

special_purpose_software:
  reasoning: Maintenance and diagnostic tooling follows the same intake path.
  evidence: evidence/intake/2026-08-14/checklist.md

The long game: annual catalogues, three-year labels, portable evidence

ISA2027 begins an annual release cycle against labels valid for three years. Your label will outlive the catalogue it was issued under, and your next assessment will use one that does not exist yet. That argues for evidence whose meaning does not depend on a control number: a dated artefact that says what it is, plus a thin control-ID-to-artefact map. When IDs move — as 1.2.4 to 6.1.3 just did — you edit the map, not the pipeline.

The regimes converge on the same artefacts. Asset inventories, classification schemes, access records and deletion procedures are the shared substrate under TISAX, ISO 27001, SOC 2 and GDPR Article 32. The ISA's Data Protection tab is explicitly scoped: edited additionally in case of processing within the meaning of Article 28 GDPR, with controls requiring merely yes/no answers. That is the Definitions tab describing an answer format, not an easy tab: its 9.x controls carry must-requirement text of their own.

One scoping trap is worth naming before it costs a label. Handbook v2.8 describes the full custom scope for locations in different assessment scopes sharing services at one site — a data centre, or a central IT department — so a result can be reused. The catch is severe: they receive no TISAX labels, other participants generally do not accept their results, and the Handbook puts a 98% chance on your audit provider reverting one to standard scope.

None of this makes self-hosting a compliance shortcut, and nothing here is endorsed by ENX or the VDA — it is one reading of a published catalogue, and the catalogue is the authority. What self-hosting changes is the *shape* of the work: four controls stop applying inside your listed locations, and in exchange you own every artefact those systems produce — precisely what an AL 3 assessment was built to look at. A good trade for a supplier still shipping into this industry in 2036; and, as Gaia-X showed, a poor one for anyone hoping a label substitutes for the work behind it.