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.

MHCDegraded controlsAlso flanks robustCharacter
MHC-05 Behaviour-based detection10A.8.15broadly cross-cutting
MHC-02 SBOM / build provenance6—supply chain
MHC-03 Phishing-resistant MFA5—identity / authentication
MHC-04 Workload identity / zero trust5A.5.16, A.8.2identity / access
MHC-09 AI security testing5A.8.29secure development
MHC-11 SOAR / tier 1 automation4—incident response
MHC-10 Continuous control monitoring3A.8.9verification
MHC-07 Multi-tenancy isolation2—cloud
MHC-08 Immutable backups2A.5.30, A.8.13, A.8.14resilience
MHC-06 Containers / confidential computing1A.8.31narrow
MHC-12 Threat-led penetration test1A.8.29narrow, validating
MHC-01 Post-quantum0A.8.24flanks robust controls only
MHC-13 AI agent governance0A.5.9, A.5.16, A.8.27flanks 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

FactorGuiding questionScale
Threat relevanceHow realistic, current and relevant is the attack scenario for the organization?1 = low … 5 = very high
Business impactHow severe would the consequences be for DORA/BIA-critical services, customer data, availability, reputation or finances?1 = low … 5 = existential
ExposureHow strongly is the organization exposed (internet-facing, cloud, suppliers, admin access, external users)?1 = low … 5 = strongly exposed
Control gapHow 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 scenarioPrimary MHCRationalePriority
AI-supported phishing / credential theftMHC-03, MHC-05, MHC-11MHC-03 prevents credential abuse, MHC-05 detects anomalous use, MHC-11 automates the first response.very high
Lateral movement after initial compromiseMHC-04, MHC-05, MHC-11, MHC-12MHC-04 limits lateral movement through workload identity, MHC-05 detects attack chains, MHC-12 validates effectiveness.very high
Software supply chain attackMHC-02, MHC-09, MHC-06SBOM, build provenance, pipeline testing and image signing interlock.high
Ransomware / destructive attackMHC-08, MHC-05, MHC-11, MHC-12Immutable backups secure recovery; detection and SOAR shorten response time; TLPT and purple teaming test resilience.very high
Manipulated container imageMHC-06, MHC-02, MHC-09Signed images and admission control require provenance and vulnerability information from the supply chain controls.medium to high
Tenant breakout / cross-tenant accessMHC-07, MHC-04, MHC-06Relevant for SaaS and multi-tenant platforms; separation must be technically enforced and tested.high, where applicable
AI agent abuse / prompt injection / tool abuseMHC-13, MHC-04, MHC-10, MHC-09Agents need their own identities, limited tool rights, policy control and a secure pipeline.high, where AI agents are deployed
Harvest now, decrypt later / quantum riskMHC-01Particularly relevant for long-lived confidential data and crypto agility.medium to high
Undetected control deviationsMHC-10Continuous control monitoring detects deviations on an ongoing basis rather than only at audit points.medium
False-positive security assumptionsMHC-12Threat-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.

DependencyMeaning
MHC-02 → MHC-09AI-supported security testing in the pipeline needs a build and CI basis and benefits directly from SBOM and component information.
MHC-04 → MHC-13AI agent governance needs technical identities, capability-scoped access and a clear separation from personal user accounts.
Logging (A.8.15) → MHC-05 → MHC-11SOAR automation is only robust where detection is based on reliable, central and tamper-resistant logs.
MHC-05 + MHC-11 → MHC-12Threat-led tests validate whether detection and response function in realistic attack chains.
MHC-02 + MHC-04 → MHC-06Container security is stronger where image provenance and workload identities are cleanly controlled.
MHC-04 + MHC-06 → MHC-07Multi-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.

PriorityMHCControlRationale
P0 — immediateMHC-03Phishing-resistant MFAHigh likelihood of occurrence, rapid risk reduction for admins and external access.
P0 — immediateMHC-08Immutable backups and recovery validationBaseline capability against ransomware and destructive attacks.
P0 — immediateMHC-05Behaviour-based detection and kill chain correlationWithout detection there is no robust response and no meaningful SOAR automation.
P0 — immediateMHC-04Workload identity and zero trustReduces lateral movement and is an enabler for AI agents.
P1 — nextMHC-02SBOM and build provenanceThe basis for supply chain transparency and pipeline testing.
P1 — nextMHC-09AI-supported security testingEffective where a pipeline and SBOM basis exist.
P1 — nextMHC-11SOAR tier 1 automationAutomate only once detection is stable.
P1 — nextMHC-10Continuous control monitoringA cross-cutting control for ongoing deviation detection.
P2 — risk-basedMHC-06Container security and confidential computingHighly relevant for container and cloud platforms.
P2 — risk-basedMHC-07Multi-tenancy isolationDirectly applicable only for multi-tenant platforms or SaaS operations.
P2 — risk-basedMHC-13AI agent governanceHighly relevant where AI agents, tool calling or automation are in use; upgrade to P0 in that case.
P2 — risk-basedMHC-01Post-quantum strategyPrioritize higher for long-lived confidential data.
P2 — risk-basedMHC-12Threat-led penetration testingValidation 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.