Prioritization · MRIS Implementation Guide 2.0 · ISO/IEC 27001
Roadmap: which hardening measure first?
The Mythos Hardening Controls are not a linear list. The roadmap orders them by coverage breadth and threat priority score into the tiers P0, P1 and P2, with dependency rules and a four-step approach.
Why prioritize?
The thirteen MHC are not to be understood as a linear sequence from MHC-01 to MHC-13. Without prioritization every control appears equally urgent — and that is precisely what makes the implementation decision harder. What is prioritized is not the control as such but its contribution to reducing the threats most relevant to the organization. This chapter combines two complementary views for that purpose: the measurable coverage breadth of each MHC (how many degraded controls it supports) and the threat- and effort-related sequence (threat correlation). The prioritization remains compatible with the overarching MRIS principle: structural controls before new detection or automation capabilities.
At a glance
- Purpose: a traceable, threat-oriented implementation roadmap instead of a linear MHC sequence.
- Basis: coverage breadth per MHC plus the threat priority score.
- Result: standard tiering P0/P1/P2 as an adaptable template, with dependency rules.
- Important: MHC-01 and MHC-13 have coverage 0 but may be P0 depending on architecture and data situation.
Coverage breadth: how many degraded controls each MHC supports
The following overview shows how many of the controls degraded under Mythos (categories "partially degraded" and "friction-only", 41 controls in total) each MHC flanks. The figures are verified against the assessment matrix in MRIS, Annex A (overall distribution 29 robust / 37 partially degraded / 4 friction-only / 23 not affected). Because a degraded control can be flanked by several MHC, the column total (44) is greater than 41. The column "also robust" additionally names flanked controls that are already robust — several MHC therefore harden robust controls further, beyond the degraded ones.
| MHC | Degraded controls | Also flanks robust | Character |
|---|---|---|---|
| MHC-05 Behaviour-based detection | 10 | A.8.15 | broadly cross-cutting |
| MHC-02 SBOM / build provenance | 6 | — | supply chain |
| MHC-03 Phishing-resistant MFA | 5 | — | identity / authentication |
| MHC-04 Workload identity / zero trust | 5 | A.5.16, A.8.2 | identity / access |
| MHC-09 AI security testing | 5 | A.8.29 | secure development |
| MHC-11 SOAR / tier 1 automation | 4 | — | incident response |
| MHC-10 Continuous control monitoring | 3 | A.8.9 | verification |
| MHC-07 Multi-tenancy isolation | 2 | — | cloud |
| MHC-08 Immutable backups | 2 | A.5.30, A.8.13, A.8.14 | resilience |
| MHC-06 Containers / confidential computing | 1 | A.8.31 | narrow |
| MHC-12 Threat-led penetration test | 1 | A.8.29 | narrow, validating |
| MHC-01 Post-quantum | 0 | A.8.24 | flanks robust controls only |
| MHC-13 AI agent governance | 0 | A.5.9, A.5.16, A.8.27 | flanks robust controls only |
MHC-05 is by far the broadest cross-cutting control. Effect is measurably unevenly distributed — that is the strongest argument against the perception that every MHC is equally important.
Two priority views and how they relate
- Coverage breadth: unconditional leverage — how many degraded controls an MHC supports. High coverage means high leverage across many risks at once.
- Threat and effort relevance: the sequence — dependent on the threat landscape, impact, exposure, control gap, dependencies and effort.
The two views do not contradict each other; they complement each other. Coverage alone would place MHC-01 and MHC-13 last, because they flank only robust controls. That would be wrong: MHC-13 is potentially P0 for any organization with AI agents (it addresses the core of the Mythos threat landscape), and MHC-01 for long-lived confidential data. The rule is therefore: order by leverage, but with a threat and applicability gate — never by coverage alone. "Low hanging fruit" then means controls with high leverage, a large control gap and low effort, having regard to the dependencies.
Assessment logic: threat priority score
For the sequence, a simple, transparent score is formed per threat scenario. It makes visible whether an MHC is being prioritized because of a high threat level, high impact, strong exposure or a large control gap.
Threat priority score = threat relevance × business impact × exposure × control gap
| Factor | Guiding question | Scale |
|---|---|---|
| Threat relevance | How realistic, current and relevant is the attack scenario for the organization? | 1 = low … 5 = very high |
| Business impact | How severe would the consequences be for DORA/BIA-critical services, customer data, availability, reputation or finances? | 1 = low … 5 = existential |
| Exposure | How strongly is the organization exposed (internet-facing, cloud, suppliers, admin access, external users)? | 1 = low … 5 = strongly exposed |
| Control gap | How large is the gap relative to the MHC target state? | 1 = well covered … 5 = barely covered |
Example: AI-supported phishing with threat relevance 5, business impact 4, exposure 5 and control gap 4 gives a score of 400 — very high priority, primarily for MHC-03, flanked by MHC-05 and MHC-11.
The threat priority score is a qualitative prioritization index, not a substitute for a formal risk analysis (ISO/IEC 27005) or an organization-specific risk matrix. Multiplying the factors makes relative action priorities visible; the value is ordinal, not metric — a score of 400 is not "twice as urgent" as 200 but serves ranking and triage.
Threat-to-MHC matrix
The matrix shows which MHC are particularly effective against which threat. It is suitable as a basis for the Statement of Applicability, the risk treatment plan and the implementation roadmap.
| Threat / attack scenario | Primary MHC | Rationale | Priority |
|---|---|---|---|
| AI-supported phishing / credential theft | MHC-03, MHC-05, MHC-11 | MHC-03 prevents credential abuse, MHC-05 detects anomalous use, MHC-11 automates the first response. | very high |
| Lateral movement after initial compromise | MHC-04, MHC-05, MHC-11, MHC-12 | MHC-04 limits lateral movement through workload identity, MHC-05 detects attack chains, MHC-12 validates effectiveness. | very high |
| Software supply chain attack | MHC-02, MHC-09, MHC-06 | SBOM, build provenance, pipeline testing and image signing interlock. | high |
| Ransomware / destructive attack | MHC-08, MHC-05, MHC-11, MHC-12 | Immutable backups secure recovery; detection and SOAR shorten response time; TLPT and purple teaming test resilience. | very high |
| Manipulated container image | MHC-06, MHC-02, MHC-09 | Signed images and admission control require provenance and vulnerability information from the supply chain controls. | medium to high |
| Tenant breakout / cross-tenant access | MHC-07, MHC-04, MHC-06 | Relevant for SaaS and multi-tenant platforms; separation must be technically enforced and tested. | high, where applicable |
| AI agent abuse / prompt injection / tool abuse | MHC-13, MHC-04, MHC-10, MHC-09 | Agents need their own identities, limited tool rights, policy control and a secure pipeline. | high, where AI agents are deployed |
| Harvest now, decrypt later / quantum risk | MHC-01 | Particularly relevant for long-lived confidential data and crypto agility. | medium to high |
| Undetected control deviations | MHC-10 | Continuous control monitoring detects deviations on an ongoing basis rather than only at audit points. | medium |
| False-positive security assumptions | MHC-12 | Threat-led tests show whether documented controls actually work. | high after baseline implementation |
Dependencies as roadmap rules
The following logic prevents controls from being implemented in isolation when they only become effective, or meaningfully verifiable, through other MHC.
| Dependency | Meaning |
|---|---|
| MHC-02 → MHC-09 | AI-supported security testing in the pipeline needs a build and CI basis and benefits directly from SBOM and component information. |
| MHC-04 → MHC-13 | AI agent governance needs technical identities, capability-scoped access and a clear separation from personal user accounts. |
| Logging (A.8.15) → MHC-05 → MHC-11 | SOAR automation is only robust where detection is based on reliable, central and tamper-resistant logs. |
| MHC-05 + MHC-11 → MHC-12 | Threat-led tests validate whether detection and response function in realistic attack chains. |
| MHC-02 + MHC-04 → MHC-06 | Container security is stronger where image provenance and workload identities are cleanly controlled. |
| MHC-04 + MHC-06 → MHC-07 | Multi-tenancy isolation draws on identity, network, resource and runtime separation. |
Standard prioritization P0 / P1 / P2
The following tiering is an example for typical enterprise environments. It must be reconciled with the actual threat landscape, asset criticality and applicability. MHC-01 and MHC-13 formally sit in P2 but move up where there is long-lived confidential data (MHC-01) or productive AI agent use (MHC-13). The standard tiering is not a universal implementation plan but a starting point; it is to be adjusted per organization to exposure, architecture, asset criticality, existing controls, resource position and regulatory context.
| Priority | MHC | Control | Rationale |
|---|---|---|---|
| P0 — immediate | MHC-03 | Phishing-resistant MFA | High likelihood of occurrence, rapid risk reduction for admins and external access. |
| P0 — immediate | MHC-08 | Immutable backups and recovery validation | Baseline capability against ransomware and destructive attacks. |
| P0 — immediate | MHC-05 | Behaviour-based detection and kill chain correlation | Without detection there is no robust response and no meaningful SOAR automation. |
| P0 — immediate | MHC-04 | Workload identity and zero trust | Reduces lateral movement and is an enabler for AI agents. |
| P1 — next | MHC-02 | SBOM and build provenance | The basis for supply chain transparency and pipeline testing. |
| P1 — next | MHC-09 | AI-supported security testing | Effective where a pipeline and SBOM basis exist. |
| P1 — next | MHC-11 | SOAR tier 1 automation | Automate only once detection is stable. |
| P1 — next | MHC-10 | Continuous control monitoring | A cross-cutting control for ongoing deviation detection. |
| P2 — risk-based | MHC-06 | Container security and confidential computing | Highly relevant for container and cloud platforms. |
| P2 — risk-based | MHC-07 | Multi-tenancy isolation | Directly applicable only for multi-tenant platforms or SaaS operations. |
| P2 — risk-based | MHC-13 | AI agent governance | Highly relevant where AI agents, tool calling or automation are in use; upgrade to P0 in that case. |
| P2 — risk-based | MHC-01 | Post-quantum strategy | Prioritize higher for long-lived confidential data. |
| P2 — risk-based | MHC-12 | Threat-led penetration testing | Validation after baseline implementation, then on a regular basis. |
Note on the market situation (July 2026): the multi-vendor development and the disclosure waves now beginning (MRIS Chapter 2.5) raise the threat-level values of the supply chain and exploit volume scenarios for most profiles; upgrading MHC-02 and MHC-09 within the tiering is then justified.
Approach in four steps
- Step 1 — establish the threat landscape: identify relevant attacker types, TTPs and attack scenarios; take account of sector-specific threats (financial services, critical services, supply chain, cloud, AI); assess threats by currency, likelihood of occurrence and proximity to the organization.
- Step 2 — map threats to MHC: determine for each threat which MHC act preventively, detectively, reactively or in a validating role; weight controls with several threat relationships more heavily; document a sound rationale in the Statement of Applicability for controls that are not applicable.
- Step 3 — calculate the score: rate threat relevance, business impact, exposure and control gap from 1 to 5 each; form the score and take account of effort and dependencies; where risk is equal, take quick wins first — those with high risk reduction and low dependency.
- Step 4 — derive the roadmap: P0 (immediate measures against high threats and large gaps), P1 (controls with dependencies or technical groundwork), P2 (context-dependent controls and validation); reassess regularly as soon as the threat landscape, architecture or regulation changes.
Wording for governance documents
For the risk-based prioritization of the Mythos Hardening Controls, the MHC are correlated with relevant threat scenarios. For each threat it is assessed which controls act preventively, detectively, reactively or in a validating role. The prioritization follows from threat relevance, business impact, exposure, the existing control gap, dependencies and implementation effort. The result is not a linear MHC sequence but a threat-oriented roadmap that justifies, for each control, why it is implemented at its particular point in time.
Reading the maturity levels
The Initial level documents the implementation path begun and does not necessarily represent full fulfilment of the respective MHC control statement. Only from Defined onwards is an MHC deemed implemented in principle; Managed describes the advanced or continuously effective implementation. The control statements of the modules describe the minimum requirements of the Defined level; requirements going beyond that are expressly marked in the statement as advanced hardening (Managed level). For reporting this means: an MHC at the Initial level is recorded as "in implementation", not as implemented. Those wishing to connect the levels to a common maturity model can read them as follows: not implemented – Initial (partial) – Defined (implemented) – Managed (governed and optimized).
Sensitivity of the threat priority score
The score is a qualitative ordinal index without factor weights: the four factors are multiplied with equal standing. Because ordinal values are multiplied, the result is a ranking and not a metric quantity — decimal places or percentage comparisons would be false precision. Check step per organization: the rating of each factor is varied individually by one rating step, so far as that is substantively plausible; if the priority class changes as a result, the classification must be specifically justified (documented in the risk process under ISO/IEC 27005).
For the standard tiering of this guide the following applies: the four P0 controls each rest on at least two dominant factors (threat level and impact, or an enabler role) as well as on the dependency rules from Section 5. If the priority class of an MHC changes on variation of a single factor by one rating step, the classification is to be marked as sensitive and justified separately. Without a documented organization-specific sensitivity calculation, no statement is made here about the stability of the P0 set. What can be expected to react are mainly the ranks within P1 and P2 (typical candidates for change: MHC-06 and MHC-12 depending on exposure). Organization-specific deviations remain permissible and are to be documented.
Source: MRIS Implementation Guide (ISO/IEC 27001), edition 2.0 (PDF), CC BY-SA 4.0. Chapter references in the text refer to the respective PDF edition.