The DMDU coupling analysis and ABM simulation we've built for ISO 27001 isn't just an ISMS tool — it's the foundation for implementing the entire 27000 family properly. Here's how each standard maps onto the framework.
Our DMDU approach IS the correct 27005 implementation. Scenario discovery replaces the likelihood × impact matrix. The ABM stress-tests risk treatment effectiveness across uncertain futures.
The cluster analysis reveals which controls to audit together because they fail together. The ABM shows emergent gaps that pass individual inspection. Computational audit support, not checklist sampling.
Our incident management cluster (A.5.24–A.5.28 + A.6.8) is already identified and modellable. DMDU asks: across what range of incident types and severities does your response plan remain effective?
Maps directly to our data-regulated sector cluster, with healthcare-specific amplification: patient safety coupling, clinical workflow integration, medical device security, consent management.
ISO 27005 provides the methodology for information security risk assessment. The traditional implementation uses a risk matrix: list threats, estimate likelihood and impact, multiply to get a risk score, treat the top-ranked risks. This approach has a fundamental flaw that's well-documented in the decision science literature — it assumes you can assign meaningful probabilities to threats you may not have imagined.
Our approach replaces each step of the 27005 process with its DMDU equivalent:
| ISO 27005 requirement | Traditional approach | DMDU approach | Our tool |
|---|---|---|---|
| Context establishment (Cl. 7) | Define scope and criteria | Define scope + identify deep uncertainties (what we don't know and can't agree on) | Coupling discovery |
| Risk identification (Cl. 8.2) | Threat catalogue + vulnerability list | Coupling analysis — identify interaction pathways between controls, not just individual threats | Coupling discovery |
| Risk analysis (Cl. 8.3) | Likelihood × impact scoring | Computational exploration of the scenario space — test control configurations against thousands of futures | Connectivity analysis |
| Risk evaluation (Cl. 8.4) | Rank risks, compare to appetite | Scenario discovery (PRIM/CART) — identify which combinations of conditions produce system failure | ABM simulation |
| Risk treatment (Cl. 8.5) | Select controls from Annex A | Design control configurations robust across the scenario space, not optimised for the most likely scenario | Cluster ABM spec |
| Risk monitoring (Cl. 8.6) | Periodic review | Monitor for scenario discovery conditions — the leading indicators of systemic failure, not lagging incident counts | ABM simulation |
Lists known threats, assigns subjective probabilities, ranks by expected value, treats the top N. Misses compound failures, cascading interactions, and novel threats entirely.
Maps control interactions, explores the scenario space computationally, discovers the conditions under which the ISMS fails, designs controls that work across that failure space — not just the most likely scenario.
ISO 27006 sets requirements for certification bodies. ISO 27007 provides audit guidance. Both assume the audit process involves sampling individual controls and verifying their implementation. The problem: controls that pass individual inspection can fail systemically when they interact under stress.
Our tools give auditors three capabilities they don't currently have:
Instead of sampling controls randomly or by category, the cluster analysis identifies which controls form coupled subsystems. Audit these together — because they fail together. An auditor who checks A.6.3 (training) independently from A.8.8 (vulnerability management) misses the cascade pathway between them.
The ABM reveals failure modes that emerge from interactions, not from individual control weakness. A traditional audit finds "training is current" and "patching SLA is met" — both pass. The ABM reveals that when training recency exceeds 4 months and patch backlog exceeds 20, workaround adoption hits a tipping point. Both controls pass their individual checks but the system is fragile.
The ABM's drift accumulator models normalisation of deviance — the slow divergence between documented procedures and actual practice. The rate of drift, given the organisation's maturity and investment cycle, determines how frequently audits need to occur to catch issues before they cascade. This is computable, not a scheduling convention.
ISO 27035 structures incident management into five phases: planning/preparation, detection/reporting, assessment/decision, response, and lessons learned. Our cluster analysis has already identified these as a tightly coupled subsystem:
Density: 1.27 — the tightest cluster in the universal analysis. These controls are so interdependent that failure in any one rapidly degrades all others. The hub is A.5.24 (planning) — if the plan is weak, everything downstream fails.
The DMDU question for 27035 is: across what range of incident types, severities, and timing does your response plan remain effective? Traditional incident management tests against a few tabletop scenarios. Our ABM tests against the full parameter space — including compound incidents (two things going wrong simultaneously), incidents during resource-constrained periods (during holidays, during layoffs, during another crisis), and novel incident types that don't match any existing playbook.
| 27035 phase | DMDU enhancement | ABM parameter |
|---|---|---|
| Planning & preparation | Plans designed for robustness across incident scenarios, not optimised for "most likely" incident | Sweep threat-novelty, shock-severity, external-shock-probability |
| Detection & reporting | Reporting rate modelled as function of culture (workaround-level), not just mechanism availability | workaround-contagion-rate, management-attention |
| Assessment & decision | Decision quality under stress — degrades with cognitive load and competing priorities | budget-pressure, staff-turnover-rate |
| Response | Response effectiveness depends on pre-positioned capability (investment-effectiveness) not just plan existence | investment-effectiveness, coupling-strength |
| Lessons learned | Learning loop modelled — do lessons actually improve controls, or does normalisation of deviance reassert? | drift-accumulator dynamics, audit-cycle-length |
ISO 27799 applies ISO 27001/27002 to health informatics. It doesn't define new controls — it specifies how existing controls apply in healthcare contexts. This means our existing coupling analysis applies directly, but with healthcare-specific coupling amplifications that our data-regulated sector cluster partially captures but 27799 demands be made explicit.
What's different about healthcare:
Data integrity failures can directly harm patients. The coupling from A.5.34 (PII) cascades through clinical decision support into treatment outcomes — a pathway that doesn't exist in finance or legal.
Healthcare systems can't tolerate downtime the way other sectors can. A.5.30 (ICT continuity) carries a higher effective weight because unavailability = delayed treatment = patient harm.
Connected medical devices create OT/IT convergence similar to manufacturing — but with patient safety stakes. A.8.20 (network security) and A.8.1 (endpoints) couple differently when the endpoint is an infusion pump.
To model 27799 properly, we apply the data-regulated sector cluster as the base, then add healthcare-specific coupling amplifications:
| Control | Standard weight | Healthcare amplification | 27799 rationale |
|---|---|---|---|
| A.5.34 PII / PHI | 2.5× | 3.5× | Patient health information under HIPAA/GDPR health data provisions; breach consequences include clinical risk |
| A.5.30 ICT continuity | 1.0× | 3.0× | Clinical system unavailability directly impacts patient care; 27799 mandates stricter RTOs |
| A.8.1 Endpoint devices | 1.0× | 2.5× | Medical devices as endpoints; FDA/MDR cybersecurity requirements; can't patch without clinical validation |
| A.5.15 Access control | 1.0× | 2.5× | Break-glass access for emergencies creates permanent exception pathways; role complexity (clinician, admin, researcher) |
| A.8.15 Logging | 1.0× | 2.5× | Audit trail for clinical access is both regulatory requirement and patient safety mechanism |
| A.5.14 Information transfer | 1.0× | 2.0× | Clinical data exchange (HL7/FHIR); inter-provider transfer creates complex custody chains |
| A.6.3 Training | 1.4× | 2.5× | Clinical staff have lowest security training engagement (time pressure, patient priority); highest phishing susceptibility |
| A.8.24 Cryptography | 2.0× | 2.5× | PHI encryption at rest and in transit mandated; key management complexity with legacy clinical systems |
These amplifications can be loaded directly into our coupling discovery engine as a healthcare sub-cluster within the data-regulated sector. The ABM then models healthcare-specific dynamics: clinical workflow integration, break-glass access patterns, medical device patching constraints, and the tension between care delivery speed and security control compliance.
The key insight is that these standards aren't separate systems requiring separate tools. They're different lenses on the same underlying complex adaptive system — your organisation's information security posture. Our DMDU framework models that system once, then applies standard-specific analysis:
| Standard | What it adds to the base ISMS model | Primary tool | Key parameters |
|---|---|---|---|
| ISO 27001 | The base — 93 controls, 4 coupling types, 3-tier architecture | Full suite | All 18 ABM parameters |
| ISO 27005 | Risk assessment methodology → replaced by scenario discovery on the same model | ABM + BehaviorSpace | threat-novelty, failure-threshold, coupling-strength |
| ISO 27006/27007 | Audit scope → derived from cluster structure; audit frequency → derived from drift rate | Cluster analysis | audit-cycle-length, drift-accumulator, management-attention |
| ISO 27035 | Incident response → the incident cluster modelled under stress scenarios | Incident cluster ABM | external-shock-probability, shock-severity, staff-turnover-rate |
| ISO 27799 | Healthcare coupling amplifications → data-regulated cluster + PHI weights + clinical dynamics | Healthcare preset | Sector weights amplified for patient safety, availability, device security |
Every standard maps back to the same analytical framework. Start with the coupling discovery engine and apply the standard-specific lens you need.
Coupling discovery → Run ABM simulation → DMDU framework →