Mythos Hardening Control · MRIS 2.0 · Applies to ISO/IEC 27001, TISAX® and IT-Grundschutz

MHC-10 Continuous control monitoring and policy as code

Closes the window between two periodic review cycles in which new attack patterns, incidents or system changes would otherwise remain undetected until the next round.

At a glance

Operational benefit: shortens the time to detection of a security deviation from months (the audit cadence) to minutes, because requirements are checked automatically on an ongoing basis. Target state from the Defined level; presupposes automated target specifications (policy as code).
Policy affected: policy on monitoring the effectiveness and observance of security requirements.
Dependencies: no precondition; presupposes requirements that can be expressed in machine-readable form and access to system and configuration data.
Effort drivers: depends on the number and nature of the requirements to be checked and on the heterogeneity of the system landscape. The actual effort depends on the organization's resources.
Primary metric: continuous monitoring coverage — share of the SoA requirements classified as automatable with active automated checking (at least daily). The reference base is expressly automation eligibility, not the total number of SoA controls; both metrics are defined in Section 7 (MRIS Annex G.6a/G.6b).
Standards touched (no claim of fulfilment): ISO/IEC 27002 A.5.35/A.5.36; C5:2026 COM-03/04; NIS2 IR No. 2.2; DORA Art. 6(5); NIST SP 800-137.

Control statement

Observance of security requirements is checked on an ongoing, automated basis against defined target states, rather than only in periodic audits. Requirements are, where possible, expressed as executable rules (policy as code) and integrated into the deployment and operations processes; deviations are alerted and tracked. Advanced hardening (Managed level): enforcement in operation (runtime enforcement) and automatically raised work items on deviation.

Purpose and threat relevance

Periodic audits check only at fixed points in time (quarterly, for instance); in between, deviations remain undetected. AI-supported attackers exploit precisely that gap: they create — or find — a misconfiguration and use it long before the next audit takes place. In addition, agentic attackers decompose their approach into steps that each appear policy-conformant. Ongoing, automated checking detects deviations immediately and brings them straight to response. The protective objective is to reduce the interval between a deviation and its detection to a minimum.

Effect across frameworks

These are the controls and requirements the MHC acts on. The classification shows how much each control loses its effect under AI-enabled attacks.

Effect across frameworks
Number	Title	Classification / Level
ISO/IEC 27001:2022, Annex A 4 controls
A.5.18	Access rights	partially degraded
A.5.35	Independent review of information security	partially degraded
A.5.36	Compliance with policies, rules and standards for information security	friction-only
A.8.9	Configuration management	robust
TISAX® ISA 2027 12 controls
1.1.1	Information security policies	partially degraded
1.2.1	Information security management (ISMS)	partially degraded
1.3.1	Inventory of information assets	partially degraded
1.3.3	Approval of external IT services	partially degraded
1.3.4	Approval of software	partially degraded
1.5.1	Compliance in procedures and processes	partially degraded
1.6.3	Crisis preparedness	partially degraded
4.1.3	User accounts and login information	partially degraded
4.2.1	Assignment of access rights	partially degraded
5.2.9	Backup and recovery	not affected
6.1.2	Non-disclosure agreements	partially degraded
6.1.3	Responsibilities between external IT service providers and the organization	not affected
IT-Grundschutz, MRIS.bd 1 requirements
MRIS.bd.1.A10	Establishing Continuous Automated Effectiveness Verification	Standard

All 93 controls in the analysis matrix · All 45 controls in the findings matrix · All 23 requirements of the module family

Maturity path

Initial: compliance dashboards maintained manually.
Defined: policy as code in the CI pipeline; real-time checks against target states; deviations are alerted and tracked.
Managed: enforcement in operation (runtime enforcement); automatically raised work items on deviation.

Measurement and audit evidence

Metric 1: automation eligibility — share of the requirements carried in the SoA that are technically capable of automated checking. This classification is documented once and reviewed annually; it excludes requirements that do not lend themselves to daily automated checking (personnel matters, contracts, physical measures, governance, management review, contact with authorities, policy maintenance).
Metric 2: continuous monitoring coverage — share of the requirements classified as automatable with active automated checking (at least daily, with alerting on deviation). Guide values: 60% or above after 12 months, 80% or above after 24 months. The denominator is expressly only the automatable requirements; measuring against all SoA controls would distort the metric and invites gaming. Optionally evaluate on a risk-weighted basis in addition.
Evidence: rule repository (policy as code), overview of the automatically checked controls, logs of work items raised on deviation.
Evidence logic (following ISO/IEC 27001, Clause 9): documented? — rule base and coverage overview; responsible? — ISMS leadership; frequency? — continuous (at least daily); tolerance? — essential controls without automated checking only on a time-limited and justified basis.

Typical mistakes

Automated checking is understood as a substitute for audits; in fact it supplements them — the required reviews remain necessary.
Dashboards are built, but deviations trigger no response; the finding remains without consequence.
Only easily checkable requirements are automated, while the essential ones are not; coverage appears high but does not cover what matters.
Target states are defined once and not maintained, so that checking measures against outdated requirements.

Delimitation and residual risk

Delimitation: concerns the ongoing checking of observance of requirements; the detection of active attacks is dealt with by MHC-05, and automated response by MHC-11.
Residual risk: only what is expressed as a rule is checked — unclear or non-machine-checkable requirements remain outside; policy-conformant but malicious activity becomes visible only in combination with behaviour-based detection (MHC-05).
ISO/IEC 27002:2022: A.5.18 Access rights; A.5.35 Independent review of information security; A.5.36 Compliance with policies, rules and standards for information security; A.8.9 Configuration management.
Framework: C5:2026 COM-03/COM-04; NIS2 IR No. 2.2; DORA Art. 6(5); OWASP SAMM; NIST SP 800-137 and 800-137A (ISCM); NIST OSCAL (machine-readable controls); policy engines Open Policy Agent (OPA/Rego), HashiCorp Sentinel.

Implementation in detail

Organizational and technical implementation, implementation examples and the prioritization within the overall programme are described in the Implementation Guide.

Implementation Guide (PDF)Back to the MHC catalog