Eight finding patterns in TISAX® ISA 2027

Unit of analysis and approach

Unit of analysis: the chapter summaries count 26 controls with an overall classification of “partially degraded” and 1 control with “friction-only” (27 of 45) — this figure refers to the overall classification per control at normal protection requirement and does not reflect several concurrent finding causes per control (for example 4.1.2: both the missing phishing resistance and pure time compression, depending on the protection requirement level). 4 further controls (1.2.2, 4.1.1, 5.2.9, 6.1.3) are unremarkable at normal protection requirement but degrade at high or very high, and accordingly do not appear in the figure of 27, although they do contain individual affected requirements. Pattern formation therefore works at the level of the 74 individual affected requirements (73 partially degraded plus 1 friction-only) across 31 distinct controls, parsed from the document text by the same extraction procedure as the priority table in the appendix. This figure was corrected during revision from an original 71 to 72, and with version 1.1 to 74: the earlier compact index had failed to capture one of the two affected requirements in control 1.4.1 (the should level, assessment criteria), even though Chapter 1 itself already correctly showed it as partially degraded; version 1.1 adds two further individual findings from control 1.6.3, resulting from the primary-source-based reassessment of the editorial catalogue duplicates there (see Methodology, data quality note).

Methodological approach: the eight clusters were formed inductively from the 74 individual findings, not derived from a category grid fixed in advance. Each individual finding was first considered on its own on the basis of its rationale in Chapters 1 to 7; only then were recurring causal patterns (for example “periodic rather than event-driven”) consolidated into a named cluster. The number eight is accordingly an empirical result of this particular analysis, not a methodological given — a different TISAX® module or a different requirements catalogue could produce a different number of clusters.

Cluster overview

Total: 74. Cluster 1 (periodic review) is by far the largest and covers four of the seven chapters — the time compression gap is not an isolated phenomenon of individual functional areas but a structural pattern spanning the CISO function, IT operations, IAM and procurement.

Gap analysis against six comparison frameworks

Methodology: for each cluster it is examined whether NIST CSF 2.0, BSI C5:2026, DORA, the CRA, the NIS2 Directive and Implementing Regulation, and ISA/IEC 62443-2-1:2024 already close the same structural gap. This is a comparison at the level of regulatory and normative baseline stance (the maturity of the best practice), not a statement about whether a given company is formally subject to these six frameworks — DORA addresses financial entities and their critical ICT third-party providers, the CRA addresses manufacturers of products with digital elements, NIS2 addresses essential and important entities in certain sectors. The assessment rests on web research from July 2026 into the publicly available texts and secondary sources; it does not replace a clause-precise certification review.

Legend: ✓ = expressly addresses the gap with a binding deadline or method · ~ = mitigates the gap but does not close it fully · ✗ = shares the same structural gap · n/a = outside the substantive scope of the framework

¹ For these cells, the research could not verify a sufficiently concrete, citable individual requirement; the classification is cautious and indicative rather than clause-precise.

² Applies only to the vulnerability-deadline half of the cluster: C5:2026 OPS-25.01AC requires a defined, monitored, CVSS-bound deadline framework for remediating vulnerabilities, binding for review periods from 1 June 2027 — this structural requirement is confirmed across several secondary sources. The concrete CVSS-tiered example deadline values in the criteria catalogue itself could not, however, be verified directly against the BSI primary document (the full PDF text was not technically extractable); one checked secondary source names divergent values for this. They are therefore deliberately not stated in figures here. The ransomware and backup immutability half (control 5.2.8) remains open even under this more cautious classification: criteria OPS-06 to OPS-09 require encryption, RTO/RPO alignment, monitoring and regular restore tests, but nowhere immutability or WORM — the term “immutable” occurs in the entire criteria catalogue only in the context of container images (OPS-26), not for backups.

Die wichtigsten Einzelbefunde:

Cluster 2 (patch gap and ransomware) is the most clearly closed case on the vulnerability-deadline aspect, but not on backup immutability: BSI C5:2026 (binding for review periods from 1 June 2027) requires, in criterion OPS-25.01AC, a defined and monitored, CVSS-bound deadline framework for remediating vulnerabilities (see footnote 2 on the state of sourcing for the exact deadline values). That is precisely the precision the vague TISAX® wordings lack — “adequate patch management” with no speed SLA (5.2.5, should) and “appropriate timeframe” (5.2.6, must) — and independently confirms that the patch gap collapse diagnosed here is not a special case of this analysis but was already treated as a regulatory gap by a German supervisory authority in 2026. The same does not hold for backup immutability: C5:2026 criteria OPS-06 to OPS-09 (Data Backup and Recovery) require encryption, RTO/RPO alignment, monitoring and restore tests at least annually, daily where sharpened — the term “immutable” occurs in the entire criteria catalogue only in the context of container images (OPS-26), not for backups. The gap diagnosed in control 5.2.8 accordingly also remains open against C5:2026. The CRA additionally obliges manufacturers to report actively exploited vulnerabilities to ENISA within 24 hours, with a follow-up report after 72 hours and a final report 14 days after a remedy becomes available — binding from 11 September 2026. That concerns the disclosure obligation for the manufacturer's own product, not internal patch management of the IT environment, but it is a precedent for clock-bound rather than vaguely worded deadlines.

Cluster 3 (phishing resistance) shows a finer nuance: NIS2 Art. 21(2)(j) is the first EU law of any kind to name multi-factor or continuous authentication expressly — thereby closing the “no second factor at all” gap. The adversary-in-the-middle relay gap (real-time phishing defeats OTP and push), however, persists, because neither NIS2 nor the remaining five frameworks expressly prescribe phishing-resistant methods (FIDO2/WebAuthn) in the core text. That level of precision exists to date only in secondary technical guidance (for example NIST SP 800-63B, AAL3) — TISAX® ISA 2027 accordingly shares this gap with the majority of the comparison frameworks, not merely with itself.

Cluster 4 (document forgery) shows a robust ranking among the comparison frameworks themselves: DORA Art. 30(3) — a sector-specific reference framework for financial entities and their critical ICT third-party providers, see the Methodology above — requires an unrestricted right of audit and access and expressly clarifies that submitted certifications “support but do not replace” the entity's own review. NIS2 Art. 21(2)(d)/(3) in conjunction with NIS2 IR No. 5.1.4 likewise requires a documented supplier assessment with contractually anchored audit rights or access to audit reports — with proportionality latitude (“where appropriate”) rather than DORA's unrestricted claim, but without standard certificates (ISO 27001, SOC 2 Type II, a TISAX® assessment, CSA STAR) being expressly permitted to replace those audit rights. TISAX® ISA 2027, with mere self-declaration or attestation, remains the weakest of the three requirements. For the personnel process (2.1.1: deepfake identity in the hiring process), none of the six frameworks offers an equivalent — that part of the cluster remains entirely TISAX®-original.

Cluster 7 (autonomous AI agents) is the only cluster in which all six comparison frameworks share the same gap as TISAX® ISA 2027 — and that is evidenced by current research, not merely assumed: neither the NIST AI RMF nor ISO/IEC 42001 nor the EU AI Act to date contains any reference to “agent”, “agentic” or autonomous AI systems. NIST has itself recognized this and, in February 2026, launched the “AI Agent Standards Initiative” (937 responses received to a Request for Information); an “AI Agent Interoperability Profile” is announced for Q4 2026 at the earliest — not yet available, therefore, as at the state of this analysis. The finding diagnosed here (1.3.3, 1.3.4: AI assistants call external services or packages on their own, without a human ever having submitted that particular tool for approval) is accordingly not a TISAX® peculiarity but a gap at the frontier of regulation as a whole. A second, narrower NIST approach is likewise still at draft stage: the NIST Cyber AI Profile (NIST IR 8596) published an initial draft in December 2025 with a comment period until the end of January 2026; according to NIST's own project page, its processing status at the time of this analysis is “Reviewing Comments” — no final text exists, and an express agent reference claimed by secondary sources could not be verified against the NIST primary text (see Part II, MHC-13, Section 2). The MHC catalogue in Part II deliberately goes beyond the pure TISAX® diagnosis at this point (see the section “Original additions beyond TISAX®” below).

Cluster 5 (signature-based detection) and cluster 6 (aggregation resistance) could not be verified with comparable precision: the research found no sufficiently concrete, citable individual requirement on behaviour-based or AI-supported malware detection, or on an explicit obligation to detect deliberately fragmented attack chains, in any of the six frameworks. ISA/IEC 62443-2-1:2024 mentions, in secondary sources, “behavioral analytics” and “continuous monitoring for anomaly detection” as an extension relative to the previous edition, without a sharp, citable obligation being derivable from that. These two clusters are therefore classified more cautiously (~ rather than ✓) than the others.

Individual findings outside the clusters

8 requirements across 6 controls could not be assigned to any recurring pattern: 1.2.2 (segregation of duties undermined by an AI-enabled dual role), 1.4.1 (outdated likelihood-of-occurrence assumptions in the risk methodology — at both the level of the assessment itself and of the underlying assessment criteria, 2 requirements), 1.6.3 high (AI-orchestrated scenarios not provided for in crisis planning, including the editorially duplicated second catalogue version, 2 requirements), 3.1.4 (PIN or password as a fallback option where no encryption obligation exists), 5.1.2 must (unspecific measures for remote access with no minimum standard), 5.3.1 (re-identification of pseudonymized data through AI-supported correlation). For individual findings with no recurring pattern, a six-framework gap analysis is not informative; they remain anchored with their full rationale in Chapters 1 to 7 and feed directly into the MHC catalogue (phase 4) as standalone measures.

Positioning for phase 4

Cluster 8 and the patch-deadline half of cluster 2 are the “lightest” cases for phase 4 — the solution already exists outside TISAX® and need only be adopted; the backup immutability half of cluster 2, by contrast, requires a wording of its own despite the review undertaken. Cluster 7 is the most valuable individual finding of this analysis: a gap that no relevant framework currently closes, so that an MHC contribution here genuinely breaks new ground rather than merely mirroring existing practice.

Original additions beyond TISAX®

The MHC catalogue in Part II is, with one exception, derived throughout from a concrete TISAX® requirement finding in this document (see Methodology, “What this analysis is — and what it is not”). On one subject this boundary is deliberately and expressly crossed: the security of AI agents.

Occasion: cluster 7 shows that TISAX® ISA 2027 touches AI agents at only two points (1.3.3, 1.3.4 — unreviewed tool or service integration) and that none of the six comparison frameworks from phase 3 closes this gap. A comparison against the OWASP Top 10 for Agentic Applications (ASI01–ASI10, as at June 2026) — a community-based threat taxonomy developed specifically for AI agents — shows that the MHC-13 originally derived from cluster 7 fully covered only one of these ten threat categories and partially covered two more. Seven categories remained unaddressed — not because they are irrelevant to organizations, but because TISAX® ISA 2027 nowhere addresses them concretely enough to derive a finding of its own.

Approach: Part II extends MHC-13 by four additional minimum standards — (a) agent identity and NHI governance, (b) baseline hardening against prompt injection, (c) a kill switch, (d) continuous reassessment of approved components — and adds a new, standalone MHC-16 (multi-agent integrity) for threats that presuppose an architecture with several communicating agents. This brings the catalogue's coverage to eight of the ten OWASP ASI categories (ASI01, ASI02, ASI03, ASI04, ASI05 via MHC-13; ASI06, ASI07, ASI08 via MHC-16). Two categories remain unaddressed even after this extension: ASI09 (human-agent trust exploitation) and ASI10 (rogue agents) — named here deliberately and openly rather than treated tacitly as solved.

Why this marking matters: the methodological value of MRIS lies in the fact that every classification can be traced back to a concrete, citable TISAX® requirement text (see Methodology, “Reproducibility”). The additions described here do not meet that criterion — they are the author's professional judgement on the basis of external threat research (primarily OWASP), not a diagnosis distilled from a TISAX® requirement text. This section, together with MHC-13 and MHC-16 (each in Section 2) in Part II, therefore consistently marks which part is TISAX®-derived and which is original, so that the two categories are not conflated. The “74 individual findings across 31 controls” of the core analysis (see Management Summary) remain unaffected by this extension.

Regulatory outlook: the NIST Cyber AI Profile (NIST IR 8596) is, at the time of this analysis, still at draft stage (status “Reviewing Comments”, see cluster 7 above) and was at no point citable enough to derive a TISAX®-comparable requirement from it. Should NIST IR 8596, or a future TISAX® ISA release, expressly address agent security, the content added here as original should be reviewed and, where appropriate, converted into a TISAX®-derived classification.