{"data":{"id":"SP-018","slug":"isms","joomla_id":279,"title":"Information Security Management System","description":"The Information Security Management System pattern is the catalogue umbrella under which every other OSA pattern operates. It defines the management capability -- context, leadership, policy, risk treatment, resources, supplier governance, performance evaluation and continual improvement -- that selects, governs, monitors and improves the technical and operational controls described elsewhere. Aligned with ISO/IEC 27001:2022, NIST CSF 2.0, BSI IT-Grundschutz, EU NIS2 and DORA, it speaks to organisations of any sector or size with structured management obligations under regulation, certification or executive accountability.","url":"https://www.opensecurityarchitecture.org/patterns/sp-018","metadata":{"release":"26.06.2","classification":"Governance & People","status":"published","type":"module","datePublished":"2010-05-09","dateModified":"2026-05-14","authors":["Aurelius","Vitruvius"],"reviewers":[],"provenance":"Originally published in 2010 by Aurelius as the OSA ISMS Module -- a vendor-neutral architectural view of an ISO 27001-aligned management system, drawn from direct experience implementing ISMS programmes in regulated industries. The pattern was reworked from first principles in 2026 by Aurelius and Vitruvius after a structured analysis of five frameworks: ISO/IEC 27001:2022 and 27002:2022 (the canonical management-system standard and its control catalogue), NIST CSF 2.0 with its newly first-class Govern function and NIST SP 800-53 Rev 5 (the underlying control library), BSI IT-Grundschutz with its 200-1/200-2/200-3 methodology and modular Compendium, EU NIS2 (Directive 2022/2555) with its management-body personal liability and mandatory minimum measures, and EU DORA (Regulation 2022/2554) with its prescriptive ICT risk framework, threat-led penetration testing and ICT third-party register. The 2026 rework adopts NIST CSF 2.0's six Govern categories as the structural decomposition while retaining ISO 27001's PDCA cycle as the management lifecycle. It positions SP-018 as the catalogue umbrella under which every other OSA pattern operates, with explicit cross-references to twelve sibling patterns. The pattern is regulator-aware but not regulator-prescriptive: sectoral specifics belong in framework-coverage data and future sectoral patterns. Source research preserved at osa-strategy/patterns/SP-018-rework/."},"diagram":{"svg":"/images/sp-018-isms.svg","png":""},"content":{"description":"

Context

\n\nAn Information Security Management System is the management capability that turns isolated controls into a governed, measurable, continuously improving security programme — the operating system of the security function. SP-018 is the OSA catalogue umbrella: it describes the management capability itself, while operational controls live in sibling patterns.\n\nThree forces have changed the ISMS conversation since 2024: NIS2 and DORA make the management body personally accountable and require board-level training; NIST CSF 2.0 elevated Govern to a first-class function; continuous-compliance tooling has shifted evidence from periodic to contemporaneous. Most in-scope organisations report against three to six frameworks simultaneously, and multi-framework drift is a leading source of audit findings.\n\n

Summary

\n\nAn ISMS is one process repeated in a loop: identify what matters, assess the risk to it, decide what level of risk you will accept, select controls proportionate to the risk, operate them, measure whether they are working, correct what isn't, improve the methodology each turn. Plan-Do-Check-Act is the canonical name. The management body owns the loop; the ISMS lead operates it; control and asset owners implement it in their domain.\n\nWhat it produces — and what justifies the overhead — is defensible evidence. Regulators (NIS2, DORA, sector authorities), certification bodies (ISO 27001, BSI Grundschutz, SOC 2), customers and insurers all increasingly demand contemporaneous, traceable, documented proof that security is being managed. One artefact set answers all of them: risk register · control-applicability artefact · plan of action and milestones · audit findings · management-review decisions. The ISMS is what produces this. The certifications are what acknowledge it.\n\n

Key principles

\n\nThree principles cut across all seven Key Control Areas. Risk drives controls, not the reverse — controls are selected because of risk, and the choice is documented in a control-applicability artefact (SoA for ISO, Current/Target Profile for CSF, Modellierung for BSI). The management body is responsible and accountable — in NIS2 and DORA jurisdictions, members may be personally liable; mandatory training is non-optional. Documented information is the evidence pipeline — what is not documented does not exist for assurance; tooling choice belongs to the implementer.","keyControlAreas":["Context, Scope and Stakeholders (PM-11, RA-03, RA-09, PL-10): Convergent: all five frameworks require structured understanding of context, stakeholders and scope before any controls are selected.
ISO 27001:2022
Cl. 4.1–4.3 — internal/external issues, interested parties, ISMS scope as a documented artefact.
NIST CSF 2.0
GV.OC (5 subcategories) — mission, stakeholders, legal/regulatory, dependencies.
BSI IT-Grundschutz
Strukturanalyse + Schutzbedarfsfeststellung — structured inventory + 3-tier protection-requirements analysis.
NIS2
Mostly implicit; sector-criticality drives essential/important entity classification (Annex I/II).
DORA
Art. 8 — ICT asset identification and classification.
Where they differ: ISO's interested parties is broader than NIST's stakeholders (includes society and regulators). BSI's three-tier Schutzbedarf adds an asset-classification dimension other frameworks defer to organisational policy. Owned threats: T-IS-012 shadow AI scope leakage.","Leadership and Management Body Accountability (PM-01, PM-02, PM-03, PM-13, PM-29, PS-09): Convergent: top-level executive owns the ISMS — non-delegable across all five frameworks.
ISO 27001:2022
Cl. 5.1 — top-management commitment via demonstrable actions (resourcing, communication, business-process integration).
NIST CSF 2.0
GV.RR-01 — leadership is responsible and accountable… fosters a culture that is risk-aware, ethical and continually improving.
BSI IT-Grundschutz
Mandates IT-Sicherheitsbeauftragter with defined reporting line to the management board.
NIS2
Art. 20(1) — personal liability of management body. Art. 20(2) — mandatory training.
DORA
Art. 5 — board approves digital operational resilience strategy. Art. 5(4) — mandatory ICT training.
Where they differ: NIS2 and DORA introduce personal liability and mandatory board training as regulatory floor. ISO is auditable but lacks personal-liability teeth. BSI is the most prescriptive on organisational reporting line. Owned threats: T-IS-015 management body insufficient training.","Policy Framework (PL-01, PL-04, PL-09, AT-01, PS-01): Convergent: a hierarchical policy framework, approved by the management body and reviewed periodically.
ISO 27001:2022
Cl. 5.2 + A.5.1 — top-level policy + topic-specific policies, approved, communicated, reviewed.
NIST CSF 2.0
GV.PO — policy created, reviewed, updated, communicated, enforced.
BSI IT-Grundschutz
Prescribed named documents: Sicherheitsleitlinie + topic policies (Krypto-Konzept etc.).
NIS2
Art. 21(2)(a) — policies on risk analysis and information-system security.
DORA
Art. 9(1) — ICT security policies, procedures, protocols, tools.
Where they differ: BSI prescribes named documents; ISO and NIST stay vendor-neutral. NIS2 makes policy existence a regulatory floor. DORA expands beyond policy to procedures, protocols and tools. Owned threats: T-IS-007 policy non-compliance by personnel · T-IS-014 multi-framework drift.","Risk Management and Treatment (RA-01, RA-02, RA-03, RA-07, RA-09, PM-09, PL-10, CA-05): Convergent: risk drives control selection — all five frameworks require a documented methodology, assessment, and treatment decisions.
ISO 27001:2022
Cl. 6.1, 8.2–8.3 — methodology, assessment, treatment; Statement of Applicability as the unique artefact.
NIST CSF 2.0
GV.RM + ID.RA — risk strategy with explicit appetite (strategic) vs tolerance (operational variance); CSF Profile (current/target).
BSI IT-Grundschutz
BSI 200-3 risk analysis invoked only for Hoch / Sehr Hoch protection requirements; Modellierung is the bottom-up applicability artefact.
NIS2
Art. 21(2)(a) — risk-analysis policy as a mandatory minimum measure.
DORA
Art. 6(2) — documented ICT risk assessment, reviewed at least annually by regulation.
Where they differ: ISO mandates the SoA. NIST distinguishes appetite from tolerance. BSI decouples baseline from formal risk analysis — risk methodology kicks in only above Normal protection. DORA prescribes the annual review cadence in regulation. Owned threats: T-IS-001 governance failure.","Resources, Competence and Documented Information (PM-03, PM-13, AT-01, AT-02, AT-03, PL-02, PL-04, AU-01, SA-02, IR-01): Convergent: the ISMS needs documented resources, demonstrable competence, and a defined documented-information lifecycle.
ISO 27001:2022
Cl. 7.1–7.5 — resources, competence, awareness, communication, documented information (unified create/update/distribute/retain/dispose lifecycle).
NIST CSF 2.0
GV.RR-03 adequate resources + AT family for awareness + PM-13 workforce + AT-06 training feedback (measurable).
BSI IT-Grundschutz
ORP.2 (personnel) + ORP.3 (awareness/training).
NIS2
Art. 21(2)(g) — basic cyber hygiene + training. Art. 21(2)(i) — HR security.
DORA
Art. 13(6) — awareness/training. Art. 13(1) — info gathering on vulnerabilities and threats.
Where they differ: ISO Cl. 7.5 is the unified documented information lifecycle — NIST and BSI lack this single concept. NIST adds AT-06 (training feedback) as a measurement step ISO doesn't require. Owned threats: T-IS-008 knowledge loss · T-IS-013 insurance evidence failure.","Supplier and Third-Party Governance (SR-01, SR-02, SR-03, CA-03): Convergent: every framework treats supply-chain risk as first-class; how varies dramatically.
ISO 27001:2022
A.5.19–A.5.23 — supplier relationships, agreements, ICT supply chain, monitoring, cloud.
NIST CSF 2.0
GV.SC promoted to a Govern category (10 subcategories) — reflecting SolarWinds / MOVEit / CrowdStrike learning.
BSI IT-Grundschutz
Embedded across ORP and CON modules.
NIS2
Art. 21(2)(d) — supply-chain security. Art. 22 — Union-level coordinated risk assessments.
DORA
Most prescriptive in any framework: Art. 28 register + due diligence + monitoring + exit. Art. 29 concentration risk. Art. 30 contractual minima. Art. 31–44 direct EU oversight of critical TPPs.
Where they differ: DORA is uniquely prescriptive — mandated register, exit strategies, concentration assessment, and EU oversight of critical providers. NIS2 adds sector-level coordination. ISO and NIST stay at programme level. Owned threats: T-IS-009 supply-chain gaps · T-IS-011 concentration risk.","Performance Evaluation, Audit and Continual Improvement (CA-01, CA-02, CA-04, CA-05, CA-07, AU-01, PM-06, PM-31, PL-09): Convergent: all five frameworks require monitoring + assessment + improvement; cadence and rigour vary.
ISO 27001:2022
Cl. 9.1 monitoring · Cl. 9.2 internal audit (independence mandated) · Cl. 9.3 management review · Cl. 10 continual improvement + nonconformity.
NIST CSF 2.0
GV.OV oversight · DE.CM continuous monitoring · ID.IM improvement · PM-31 monitoring strategy + CA-07 operation.
BSI IT-Grundschutz
Improvement embedded in BSI 200-1 PDCA cycle; tied to certification renewal.
NIS2
Art. 21(2)(f) — policies/procedures to assess effectiveness.
DORA
Art. 6(4) — annual review of ICT risk framework. Art. 13 — learning and evolving.
Where they differ: ISO Cl. 9.2 mandates auditor independence. NIST separates strategy (PM-31) from operation (CA-07). DORA prescribes the annual cadence in regulation. BSI ties improvement to the certification renewal cycle. Owned threats: T-IS-002 audit failure · T-IS-003 undetected incidents · T-IS-004 control drift · T-IS-013 insurance evidence · T-IS-014 multi-framework drift."],"assumptions":"PDCA-or-equivalent improvement methodology in place; senior management commitment exists, is visible, and is sustained over time; the ISMS scope is defined and documented; resources (budget, headcount, infrastructure, tooling) are allocated commensurate with scope; a risk methodology has been selected or will be established; a documented information lifecycle exists or will be operationalised; internal audit competence is available or will be developed; the organisation is aligned (or aligning) to current standards -- ISO/IEC 27001:2022 with the four-theme Annex A, NIST CSF 2.0 with its first-class Govern function, BSI IT-Grundschutz where applicable, and any sectoral regimes that apply (NIS2, DORA, sector-specific regulators); AI systems are either explicitly in ISMS scope or covered by a parallel ISO/IEC 42001 management system that integrates with the ISMS; the management body has been informed of its accountability and (where required by NIS2 Article 20(2) or DORA Article 5(4)) has access to mandatory training. The pattern assumes that the management body genuinely owns the ISMS rather than treating it as a delegated CISO concern, and that proportionality (ISO Cl. 4.3, NIS2 Art. 21(1), DORA Art. 4 and Art. 15) is applied honestly to scale measures with the organisation's size, exposure and risk profile.","typicalChallenges":"Sustaining management commitment over time is the primary challenge -- the Plan and Do phases generate visible progress, while the Check and Act phases require disciplined, repetitive work that is less visible. Policy fatigue is real: creating comprehensive policies is straightforward, but ensuring they are read, understood, followed, and kept current is a persistent challenge. Bridging the gap between governance documentation and operational reality is the central ISMS challenge -- organisations that treat the ISMS as a documentation exercise for certification purposes derive minimal security value. Internal audit independence can be difficult to achieve in smaller organisations where the security team may end up auditing its own work. Measuring ISMS effectiveness beyond compliance metrics (number of policies, audit findings closed) requires security metrics that demonstrate genuine risk reduction; ISO 27004 has not been refreshed for the continuous-compliance era. Multi-framework reporting load is now a leading source of dysfunction: organisations subject to ISO 27001, SOC 2, NIST CSF, NIS2, DORA and ISO 42001 simultaneously can spend more time mapping evidence between frameworks than improving controls, and divergence between framework-specific control sets creates inconsistency that auditors then cite as a finding. Concentration risk in shared GRC tooling and audit firms is rising: when a critical mass of an industry sector relies on the same SaaS GRC platform or audit provider, an outage or compromise of that provider becomes a sector-level event. Shadow AI adoption inside the business -- employees using ungoverned models for sensitive work -- expands ISMS scope faster than the ISMS can absorb it, and treating it as an awareness problem rather than a scope problem leaves a structural gap. Cyber-insurance underwriting has shifted from questionnaire-based assessment to evidence-based assessment, exposing gaps in evidence pipelines that ISMS programmes are sometimes slow to fill. Integration of the ISMS with adjacent management systems (quality, IT service management, privacy, AI governance under ISO 42001) adds complexity but also efficiency opportunities.","indications":"Any organisation with a computing environment that must be secured in a structured manner to meet business, legal, regulatory, or industry requirements. Organisations pursuing or maintaining ISO/IEC 27001 certification, SOC 2 Type II examination, or BSI IT-Grundschutz certification. Organisations classified as essential or important entities under EU NIS2. Financial-sector entities subject to EU DORA. Organisations in regulated industries (financial services, healthcare, government, critical infrastructure, energy, telecommunications, postal, waste, chemicals, food, manufacturing, digital providers, research) where structured security management is mandated. Organisations whose management body is required to demonstrate cybersecurity accountability to regulators, certification bodies, customers, partners, or insurers. Organisations operating AI systems requiring ISO/IEC 42001 alignment. Organisations preparing for cyber-insurance underwriting or claim defence in an evidence-based market. Any organisation where security has become a board-level concern and structured governance is expected.","contraIndications":"There are no legitimate contra-indications at meaningful organisational scale. Very small organisations may operate a lighter management system -- proportionality (ISO Cl. 4.3, NIS2 Art. 21(1), DORA Art. 4 and Art. 15) is built into every framework -- and may forgo formal certification. The underlying principles, however, are universal: risk-based control selection, documented intent and operation, top-management ownership, periodic review and continual improvement apply regardless of size. The objection 'we are too small for an ISMS' typically conflates the ISMS with formal certification; the management capability is independent of the audit regime. Organisations that operate exclusively through managed SaaS without any custom systems, internal data, or sensitive customer relationships may find a lighter ISMS sufficient -- but the existence of any one of those (which is rare in practice) reintroduces the need for a structured management system.","threatResistance":"The ISMS does not directly mitigate technical threats -- those are owned by operational patterns. It mitigates twelve organisational and governance threats by ensuring that technical controls are selected based on risk, implemented correctly, operated consistently, monitored for effectiveness, and improved over time. The pattern explicitly addresses: governance failure where security decisions are made without structured risk assessment (T-IS-001); regulatory non-compliance and audit failure (T-IS-002); undetected security incidents persisting due to absent or weak monitoring (T-IS-003); control degradation and operational drift (T-IS-004); policy non-compliance by personnel (T-IS-007); knowledge loss and undocumented security processes (T-IS-008); supply chain security gaps including inherited and concentration risk (T-IS-009); concentration risk in shared GRC platforms or audit firms (T-IS-011); shadow AI usage outside ISMS scope (T-IS-012); cyber-insurance evidence failure (T-IS-013); multi-framework drift across ISO 27001, SOC 2, NIS2, DORA and ISO 42001 (T-IS-014); and management body insufficient training or competence (T-IS-015). Three operational threats are stewarded by sibling patterns and named here for completeness: T-IS-005 (inadequate incident response leading to escalated impact) is owned by SP-036 Incident Response; T-IS-006 (unmanaged vulnerabilities exploited before remediation) by SP-038 Vulnerability Management and Patching; T-IS-010 (inadequate physical and environmental protection enabling tampering, theft or environmental damage) by physical-security patterns including SP-022 Board Room and SP-016 DMZ Module. The ISMS requires their respective programmes to exist; the operational detail lives in those patterns.","roleResponsibilities":{"introduction":"This pattern uses a three-tier role cut native to ISMS work: management body, ISMS lead, and control or asset owner. The cut differs from the developer / architect / business-owner cut used in operational OSA patterns because the audience differs -- this pattern speaks to security-management roles, not engineering roles. The management body is the board, executive committee, or equivalent collective leadership body responsible for the organisation's direction; under NIS2 Art. 20 and DORA Art. 5 its members may be personally accountable. The ISMS lead is the named accountable officer for the management system day-to-day -- the Information Security Manager, Senior Information Security Officer, IT-Sicherheitsbeauftragter (BSI), or CISO depending on context -- with a defined reporting line to the management body. Control or asset owners are the named individuals who implement and operate the controls in their domain and report on effectiveness. External roles (regulators, certification bodies, auditors, customers, insurers) are referenced where relevant but outside this matrix because they are outside the organisation's accountability boundary.","keyPrinciple":"The management body's most critical responsibilities are approving the ISMS scope and policy, defining the risk appetite, chairing periodic management review with documented decisions, and maintaining sufficient training to assess cybersecurity risks. NIS2 Art. 20 and DORA Art. 5 make these non-delegable; ISO Cl. 5.1 makes the commitment auditable; NIST GV.RR-01 makes leadership accountable for fostering a risk-aware, ethical, continually improving culture. Without explicit decisions from the management body, the ISMS lead makes them implicitly -- and will default to whichever interpretation is cheapest or easiest to defend in audit, which is rarely best for the business.","areas":[{"area":"Context, Scope and Stakeholders","controls":"PM-11, RA-03, RA-09, PL-10","managementBody":"Approves the ISMS scope statement, ratifies major scope changes (e.g., AI inclusion, geographic expansion, new sector entry, new regulatory regime), and signs off on the stakeholder register at least annually.","ismsLead":"Drafts and maintains the scope statement and stakeholder register. Runs the structured context analysis (PESTLE-style external issues plus internal issues plus dependencies) and presents findings to the management body.","controlOrAssetOwner":"Identifies their assets, processes, suppliers and dependencies that fall in scope. Reports scope-affecting changes (new systems, retired systems, new third parties, new AI usage) to the ISMS lead."},{"area":"Leadership and Management Body Accountability","controls":"PM-01, PM-02, PM-03, PM-13, PM-29, PS-09","managementBody":"Demonstrates commitment by allocating resources, communicating the importance of security across the organisation, integrating ISMS requirements into business decisions, and participating personally in management review. Maintains required training (NIS2 Art. 20(2), DORA Art. 5(4)) to assess cybersecurity risks competently. Owns concentration-risk decisions and the organisation's overall security culture.","ismsLead":"Reports directly to the management body or to a member designated for cybersecurity. Maintains the role-responsibility matrix; ensures every accountability is explicitly assigned to a named individual; raises cultural and resource constraints to the management body; coordinates the named-officer relationships (Senior Information Security Officer / IT-SiBe / CISO) with HR and legal.","controlOrAssetOwner":"Receives and acknowledges assigned accountabilities. Reports control effectiveness, exceptions, and resourcing constraints upward through the ISMS lead. Models security-aware behaviour for direct reports."},{"area":"Policy Framework","controls":"PL-01, PL-04, PL-09, AT-01, PS-01","managementBody":"Approves the top-level information security policy and ratifies major topic-specific policy changes. Authorises disciplinary consequences for material policy non-compliance.","ismsLead":"Drafts the policy framework hierarchy (top-level policy supported by topic-specific policies and procedures); manages policy lifecycle (drafting, approval, communication, training, periodic review); maintains compliance tracking against legal, regulatory and contractual obligations; owns multi-framework alignment decisions.","controlOrAssetOwner":"Implements policy in their domain; surfaces policy ambiguities or conflicts; reports compliance status; trains direct reports on relevant policies."},{"area":"Risk Management and Treatment","controls":"RA-01, RA-02, RA-03, RA-07, RA-09, PM-09, PL-10, CA-05","managementBody":"Defines and approves the risk appetite (NIST GV.RM-02). Approves treatment decisions for risks above defined thresholds. Ratifies the control-applicability artefact (Statement of Applicability, CSF Profile, or BSI Modellierung).","ismsLead":"Owns the risk methodology; maintains the risk register; aggregates risks from control or asset owners; recommends treatment options (mitigate, accept, transfer, avoid); maintains the control-applicability artefact; reports risk posture and trend to the management body; manages the POA&M (CA-05).","controlOrAssetOwner":"Identifies risks in their domain; assesses likelihood and impact using the established methodology; implements approved treatment; reports residual risk back to the ISMS lead; owns the closure of POA&M items in their domain."},{"area":"Resources, Competence and Documented Information","controls":"PM-03, PM-13, AT-01, AT-02, AT-03, PL-02, PL-04, AU-01, SA-02","managementBody":"Approves the ISMS resourcing plan (budget, headcount, tooling) and competence requirements for security-critical roles. Receives the documented-information artefact set as part of management review.","ismsLead":"Operates the documented-information lifecycle (creation, update, distribution, retention, disposal); manages the competence programme (training records, role-based competence, certifications, position descriptions); operates the named artefact set (policy, scope statement, risk register, control-applicability artefact, POA&M, audit reports, management-review minutes, performance-metrics dashboard, continuous-monitoring strategy, incident register, third-party register where applicable).","controlOrAssetOwner":"Maintains evidence for their domain (configuration baselines, control test results, exception logs, training completion); completes role-based training; produces and updates documented procedures for their controls."},{"area":"Supplier and Third-Party Governance","controls":"SR-01, SR-02, SR-03, CA-03","managementBody":"Approves engagements with critical suppliers and accepts residual third-party risk. Owns concentration-risk decisions when many critical suppliers depend on the same upstream provider. Ratifies exit strategies for ICT third-party arrangements where required (DORA Art. 28(8)).","ismsLead":"Owns the third-party risk programme requirement (operational details delegated to SP-042). Coordinates with SP-042 on the supplier register, criticality tiering, due diligence, monitoring, and exit. Surfaces concentration risk to the management body. Maintains alignment with NIS2 Art. 21(2)(d) + Art. 22 and DORA Art. 28-30 where applicable.","controlOrAssetOwner":"Operates supplier relationships in their domain; reports supplier security-relevant changes (incidents, contract changes, M&A, exit triggers) to the ISMS lead and the SP-042 programme; maintains contract clauses meeting the organisation's minimum standards."},{"area":"Performance Evaluation, Audit and Continual Improvement","controls":"CA-01, CA-02, CA-04, CA-05, CA-07, AU-01, PM-06, PM-31, PL-09","managementBody":"Chairs management review at planned intervals (minimum annually; ISO Cl. 9.3 and DORA Art. 6(4)+(5)). Receives audit reports and KPI dashboards; signs off corrective action; allocates additional resources where the cycle reveals gaps. Reviews the cyber-insurance evidence pipeline.","ismsLead":"Operates the internal audit programme with auditor independence (ISO Cl. 9.2). Operates the continuous-monitoring strategy (NIST PM-31) and performance-metrics pipeline (PM-06). Maintains the POA&M (CA-05) and the corrective-action process (ISO Cl. 10.2). Maintains framework mappings as a thin overlay (single internal control set; ISO 27001 / SOC 2 / NIS2 / DORA / ISO 42001 mapped on top) to mitigate T-IS-014 multi-framework drift.","controlOrAssetOwner":"Provides evidence on demand for their controls; closes findings within agreed timelines; maintains the metrics for their domain; participates in retrospectives after incidents and audits."}]}},"examples":{"ISMS platforms and GRC tools":["Vanta for automated evidence collection and continuous compliance monitoring against ISO 27001, SOC 2, NIST CSF, HIPAA, NIST AI RMF, and CIS frameworks","Drata for SOC 2 and ISO 27001 compliance automation with continuous control monitoring across 200+ integrations","Secureframe for multi-framework compliance automation (ISO 27001, SOC 2, HIPAA, PCI DSS, NIST AI RMF, FedRAMP)","OneTrust GRC for integrated risk, compliance and policy management across enterprise scale","ServiceNow GRC for enterprise governance, risk and compliance workflows with platform integration","Hyperproof for GRC programme management with multi-framework mapping","LogicGate Risk Cloud for risk and compliance automation"],"Risk assessment methodologies":["ISO/IEC 27005:2022 information security risk management framework","NIST SP 800-30 Rev 1 Guide for Conducting Risk Assessments","FAIR (Factor Analysis of Information Risk) for quantitative cyber risk analysis","OCTAVE Allegro for rapid asset-based security risk assessment","BSI-Standard 200-3 for risk analysis on assets with Hoch / Sehr Hoch protection requirements"],"Audit and certification":["ISO/IEC 27001:2022 certification audit by accredited certification bodies (BSI Group, DNV, SGS, Schellman, Bureau Veritas)","SOC 2 Type II examination by licensed CPA firms","BSI IT-Grundschutz certification (Basis-Absicherung, Standard-Absicherung, or Kern-Absicherung path)","TIBER-EU threat-led penetration testing under DORA Art. 26 (mandatory for in-scope significant financial entities)","Internal audit programmes using ISO 19011:2018 audit-management principles"],"Multi-framework mapping":["Common Controls Hub (CCH) for cross-framework control mapping across major standards","Secure Controls Framework (SCF) -- open metaframework with mappings to 200+ standards","OSA framework-coverage data (ISO 27001, ISO 27002, NIST CSF 2.0, NIS2, DORA, BSI Grundschutz, plus 50+ sectoral frameworks)","Unified Compliance Framework (UCF) for harmonised control mapping and authority documents","NIST SP 800-53 Rev 5 Appendix C cross-framework crosswalks"],"Continuous monitoring and metrics":["NIST SP 800-53 PM-31 Continuous Monitoring Strategy as the documented telemetry roadmap","ISO/IEC 27004:2016 for ISMS measurement, monitoring, analysis and evaluation methodology","CIS Critical Security Controls Implementation Group benchmarks (IG1, IG2, IG3) for tiered control adoption","OWASP Software Assurance Maturity Model (SAMM) for development-side ISMS metrics","Continuous Compliance Maturity Model (CCMM) frameworks for evidence-pipeline maturity assessment"],"Developing Areas":["Continuous compliance automation is now table stakes but the maturity gap is widening. Platforms automate evidence collection for perhaps 60-70% of ISO 27001:2022 controls and similar percentages for SOC 2 and NIST CSF, yet the remaining controls -- those requiring judgement, organisational context, or human-process evidence -- still require manual artefact collection. Auditors and certification bodies are only beginning to accept machine-generated evidence as primary audit artefacts, creating a transitional period where organisations run parallel manual and automated processes. The maturity model is unsettled: ISO/IEC 27004 has not been refreshed to address continuous-compliance metrics, and the dominant platform vendors each define their own maturity rubrics. Expect a Common Continuous Compliance Maturity Model to emerge from the standards bodies in the 2026-2028 window.","ISMS scope definition is being challenged by three forces simultaneously: cloud-native architectures with shared-responsibility boundaries that shift with each provider release; permanent remote and hybrid work with employees on personal networks and devices; and AI usage that expands faster than the management system can re-scope. Traditional scope statements assumed physical office locations, on-premises data centres, and a stable supplier set. Emerging approaches treat scope as dynamic and identity-centric rather than location-based, but ISO 27001:2022 certification audits have not fully adapted. The DORA scope-by-Critical-or-Important-Function model and the NIS2 essential/important-entity classification offer a regulatory shape, but neither addresses scope velocity. Shadow AI is the most acute manifestation: when employees adopt consumer AI tools for sensitive work, the ISMS scope leaks faster than re-scoping cycles can compensate, requiring scope to become a continuously assessed property rather than an annual documented artefact.","Metrics-driven ISMS operation is still immature despite three decades of management-system practice. Most organisations track lagging indicators (audit findings, incidents, training completion) rather than leading indicators that predict security posture degradation. Quantitative methodologies like FAIR are gaining traction but require data that few organisations systematically collect. NIST PM-06 Measures of Performance and ISO/IEC 27004 provide the structural backbone but the industry lacks consensus on which security metrics genuinely correlate with risk reduction versus which are compliance theatre. AI-assisted analytics applied to ISMS telemetry is opening new measurement possibilities -- anomaly detection on control-effectiveness data, NLP analysis of audit findings to surface latent themes -- but is too new to have produced validated case studies.","GRC platform integration remains fragmented in 2026, with most organisations operating multiple disconnected tools for risk register, policy library, audit tracking, vendor management, evidence repository, and metrics dashboards. True platform convergence -- where a single system of record drives every ISMS process -- is an emerging capability that fewer than 25% of mid-market enterprises have achieved. Simultaneously, concentration risk in the dominant continuous-compliance platforms is rising: when a critical mass of an industry sector relies on the same SaaS GRC platform, an outage or compromise of that provider becomes a sector-level event. The DORA Art. 31-44 oversight framework for critical ICT third-party providers is the regulatory response, but its operational impact on GRC tooling vendors is still emerging. Open data formats (OSCAL, the Open Security Controls Assessment Language by NIST) may reduce platform lock-in but adoption remains limited.","DORA's oversight framework for critical ICT third-party providers (Articles 31-44) has begun reshaping the ICT supply landscape from January 2025 onwards. The European Supervisory Authorities (ESAs) designate critical providers -- likely including hyperscale cloud providers, dominant authentication services, and major application platforms -- and assign Lead Overseers with direct supervisory authority. The downstream effect on ISMS programmes is significant: previously the regulatory burden on a SaaS or cloud provider was indirect (via customer financial entities); now the provider can be supervised, examined, and required to remediate findings directly. Financial-entity ISMS programmes will need to monitor their providers' Lead-Overseer engagement, factor it into concentration-risk decisions, and update third-party registers and exit strategies accordingly. The first round of designations and supervisory actions in 2025-2026 will define the operating practice."]},"references":[{"title":"ISO/IEC 27001:2022 Information Security Management Systems - Requirements","url":"https://www.iso.org/standard/27001","note":"The canonical ISMS standard. Specifies the management-system structure (Clauses 4-10) and the normative Annex A control catalogue. The 2022 revision reorganised Annex A into four themes and added 11 new controls. The vocabulary spine of this pattern is taken from this standard."},{"title":"ISO/IEC 27002:2022 Information Security Controls","url":"https://www.iso.org/standard/75652.html","note":"Companion to ISO 27001 providing implementation guidance for the Annex A controls. Reorganised in 2022 into four themes (organisational, people, physical, technological) with structured control attributes. Most controls are owned by sibling OSA patterns; this pattern owns the management-of-controls capability."},{"title":"ISO/IEC 27003:2017 ISMS Implementation Guidance","url":"https://www.iso.org/standard/63417.html","note":"Implementation guidance for ISO 27001. Useful as a methodology reference for organisations establishing an ISMS for the first time, or formalising one that has grown organically."},{"title":"ISO/IEC 27004:2016 Monitoring, Measurement, Analysis and Evaluation","url":"https://www.iso.org/standard/64120.html","note":"Guidance on ISMS measurement and metrics. Underutilised in practice; this pattern references it for the performance-evaluation discipline. A 2025-2026 refresh to address continuous-compliance metrics is overdue."},{"title":"ISO/IEC 27005:2022 Information Security Risk Management","url":"https://www.iso.org/standard/80585.html","note":"Risk management framework aligned with ISO 31000. The methodology reference for KCA 4 risk management."},{"title":"NIST Cybersecurity Framework 2.0 (2024)","url":"https://www.nist.gov/cyberframework","note":"The 2024 revision elevated Govern to a first-class function alongside Identify, Protect, Detect, Respond and Recover. The six Govern categories (OC, RM, RR, PO, OV, SC) provided the structural decomposition for this pattern's seven Key Control Areas."},{"title":"NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations","url":"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final","note":"The control catalogue from which this pattern's controls are drawn. The PM family (Program Management) provides the organisation-wide controls that constitute the management system itself, distinct from per-system controls in other families."},{"title":"NIST SP 800-37 Rev 2: Risk Management Framework for Information Systems and Organizations","url":"https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final","note":"Defines the seven-step Risk Management Framework (Prepare, Categorise, Select, Implement, Assess, Authorise, Monitor). The Prepare and Monitor steps map onto ISO 27001 Clauses 4-7 and 9-10 respectively. Useful for organisations operating against both NIST and ISO obligations."},{"title":"BSI-Standards 200-1, 200-2 and 200-3: IT-Grundschutz Methodology","url":"https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html","note":"BSI's prescriptive methodology for ISMS implementation. 200-1 is the management system itself; 200-2 defines three implementation paths (Basis-Absicherung, Standard-Absicherung, Kern-Absicherung); 200-3 covers risk analysis for higher protection requirements. The most prescriptive method-led standard in this synthesis."},{"title":"Directive (EU) 2022/2555 (NIS2) on Network and Information Security","url":"https://eur-lex.europa.eu/eli/dir/2022/2555/oj","note":"EU directive expanding cybersecurity obligations to essential and important entities across critical sectors. Article 20 establishes management body personal liability and mandatory training; Article 21 lists ten mandatory minimum risk-management measures; Article 23 specifies the 24h/72h/1-month incident reporting cadence."},{"title":"Regulation (EU) 2022/2554 (DORA) on Digital Operational Resilience","url":"https://eur-lex.europa.eu/eli/reg/2022/2554/oj","note":"EU regulation imposing structured ICT risk management on financial-sector entities. Article 5 requires a board-approved digital operational resilience strategy; Articles 28-30 mandate the ICT third-party register, due diligence, contract minima and exit strategies; Articles 26-27 mandate threat-led penetration testing for significant entities; Articles 31-44 establish direct EU oversight of critical ICT third-party providers."},{"title":"ISO/IEC 42001:2023 Artificial Intelligence Management System","url":"https://www.iso.org/standard/81230.html","note":"Parallel management system standard for AI. This pattern cross-references ISO 42001 for organisations whose ISMS scope includes AI systems; SP-045 (AI Governance) operates the AI-specific controls. ISO 42001 and ISO 27001 are designed to integrate."}],"relatedPatterns":["SP-010","SP-013","SP-014","SP-029","SP-031","SP-032","SP-034","SP-035","SP-036","SP-038","SP-042","SP-045"],"relatedPatternNames":["Identity Management","Data Security","Awareness and Training","Zero Trust Architecture","Security Monitoring and Response","Modern Authentication","Cyber Resilience","Offensive Security Testing","Incident Response","Vulnerability Management and Patching","Third Party Risk Management","AI Governance and Responsible AI"],"threats":[{"id":"T-IS-001","name":"Governance failure where security decisions are made without structured risk assessment","description":"Without a documented risk methodology and an approved risk appetite, individual security decisions are made by whichever team encounters the question first. The result is inconsistent treatment across the organisation -- one business unit accepts what another mitigates -- and aggregate residual risk exceeds what management would have approved had it been visible. This pattern is the root cause of most ISO 27001 nonconformities under Clause 6.1 and is consistently the highest-impact organisational risk in mature ISMS programmes. RA-01 establishes the methodology, PM-09 the strategy, CA-01 the assessment authority and PL-01 the planning artefact that ties them together.","mitigatedBy":["RA-01","PM-09","PL-01","CA-01"]},{"id":"T-IS-002","name":"Regulatory non-compliance and audit failure leading to fines, certification loss or commercial impact","description":"Failure to demonstrate structured security management to regulators, certification bodies, customers or insurers translates directly into fines (NIS2 up to EUR 10M or 2% of global turnover; DORA equivalent), certification withdrawal, lost contracts and underwriting penalties. The threat materialises when assessment evidence cannot be produced on demand, when findings are not closed within stated timelines, or when monitoring data does not exist for periods the auditor samples. CA-02 (security assessments), CA-04 (security certification), CA-05 (POA&M) and CA-07 (continuous monitoring) together ensure the organisation can substantiate its claims with contemporaneous evidence rather than reconstructed artefacts.","mitigatedBy":["CA-02","CA-04","CA-07","CA-05"]},{"id":"T-IS-003","name":"Undetected security incidents persisting in the environment due to absent or weak monitoring capability","description":"An incident the organisation does not detect cannot be contained, and dwell-time studies consistently show that detection failure is the dominant factor in incident impact. The threat manifests where monitoring is partial, alerts are not triaged, or there is no documented monitoring strategy. PM-31 (Continuous Monitoring Strategy) is the documented telemetry roadmap; CA-07 (Continuous Monitoring) is the operational implementation; PM-06 (Measures of Performance) provides the metrics that show monitoring is working. Operational detail is owned by SP-031 Security Monitoring and Response; this pattern requires the strategy and metrics to exist.","mitigatedBy":["CA-07","PM-31","PM-06"]},{"id":"T-IS-004","name":"Control degradation and operational drift where implemented controls silently lose effectiveness","description":"Controls that work on day one routinely stop working over time as systems are reconfigured, exceptions accumulate, monitoring gaps appear and ownership turns over. Without continuous monitoring (CA-07), periodic assessment (CA-02) and disciplined POA&M closure (CA-05), an organisation believes it is protected by controls that have effectively failed. Criticality analysis (RA-09) ensures that drift on the most critical components is detected first. The drift is invisible until an incident or audit forces it into view, by which point the residual risk has been carried for an unknown period.","mitigatedBy":["CA-07","CA-02","RA-09","CA-05"]},{"id":"T-IS-007","name":"Policy non-compliance by personnel due to weak awareness, training or enforcement","description":"Policies that are not understood, not followed and not enforced are decoration. The threat materialises through preventable incidents -- mishandled data, unauthorised access, social engineering success -- where the post-incident review traces back to a policy the personnel involved had never read or had read but not internalised. AT-01 establishes the awareness and training policy, AT-02 and AT-03 deliver the awareness and role-based training, PL-04 codifies rules of behaviour, and PS-01 covers the personnel security lifecycle. Without measurable awareness coverage, personnel are the highest-likelihood attack vector regardless of technical controls.","mitigatedBy":["AT-01","AT-02","AT-03","PL-04","PS-01"]},{"id":"T-IS-008","name":"Knowledge loss and undocumented security processes when expertise leaves the organisation","description":"Security teams in the post-pandemic labour market have seen turnover rates of 20-30% annually, and an ISMS where critical knowledge resides only in individuals collapses when those individuals leave. Symptoms include incident response that depends on a single named person, control operation nobody can audit independently, and risk assessments whose methodology nobody can re-explain. PL-01 (planning policy) and PL-02 (system security plan) require documented operational detail; PS-09 (position descriptions) ties responsibilities to roles rather than individuals; AT-03 (role-based training) builds competence breadth; PM-13 (security and privacy workforce) ensures the workforce plan addresses succession.","mitigatedBy":["PL-01","PL-02","PS-09","AT-03","PM-13"]},{"id":"T-IS-009","name":"Third-party and supply chain security gaps creating inherited and concentration risk","description":"An organisation's security posture is bounded by the weakest link in its supply chain. Recent supply chain incidents -- SolarWinds, MOVEit, Okta, CrowdStrike -- demonstrate that a single supplier compromise can produce simultaneous incidents across hundreds of customer organisations, often with no contractual remedy proportionate to the loss. SR-01 (Supply Chain Risk Management Policy) and SR-02 (Supply Chain Risk Management Plan) establish the programme; SR-03 (Supply Chain Controls and Processes) provides operational controls; CA-03 (Information Exchange) governs the technical interconnections. Operational detail is owned by SP-042 Third-Party Risk Management; this pattern requires the programme to exist and be aligned with NIS2 Art. 21(2)(d) and DORA Art. 28-30 where applicable.","mitigatedBy":["SR-01","SR-02","SR-03","CA-03"]},{"id":"T-IS-011","name":"Concentration risk in shared GRC platforms and audit firms creating sector-level exposure","description":"Continuous-compliance platforms (Vanta, Drata, Secureframe, Hyperproof) and a small number of large audit firms now hold ISMS-critical evidence and credentials for substantial portions of entire industry sectors. A compromise, prolonged outage or systemic methodology error at one of these providers becomes a sector-level event rather than an isolated incident. PM-09 (Risk Management Strategy) requires explicit treatment of concentration risk in the risk strategy; SR-01 and SR-02 govern the supply chain dependency; RA-09 (Criticality Analysis) ranks the providers by criticality. The structural mitigation is to keep evidence portable and reproducible without the platform.","mitigatedBy":["PM-09","SR-01","SR-02","RA-09"]},{"id":"T-IS-012","name":"Shadow AI usage outside ISMS scope expanding the attack surface faster than the management system can adapt","description":"Employees adopting consumer AI tools for sensitive work -- contract drafting, customer data analysis, source code review -- create unmanaged data flows that bypass every ISMS control over data classification, retention, vendor management and access. Treating shadow AI as an awareness problem is insufficient: the ISMS scope itself must absorb AI-system risk through alignment with ISO/IEC 42001 or NIST AI RMF, with explicit policy (PL-01), enforcement of acceptable-use boundaries (AT-01), risk methodology (RA-01), and continuous monitoring (CA-07) of which AI services receive enterprise data. PM-09 requires the risk strategy to recognise AI-system risk as a distinct category. Operational AI-specific controls live in SP-045 AI Governance.","mitigatedBy":["PM-09","RA-01","PL-01","AT-01","CA-07"]},{"id":"T-IS-013","name":"Cyber-insurance evidence failure leading to coverage exclusions, claim denial or premium escalation","description":"Cyber-insurance underwriting has shifted from questionnaire-based assessment to evidence-based assessment, and organisations that cannot produce on-demand evidence of MFA coverage, EDR deployment, backup integrity, patching SLAs and IR readiness face premium increases, coverage exclusions or outright claim denial after an incident. CA-07 (continuous monitoring) and PM-31 (continuous monitoring strategy) provide the evidence pipeline; CA-05 (POA&M) closes findings in a way the underwriter can verify; AU-01 (audit and accountability policy) provides the evidentiary spine that makes the evidence defensible. The risk is not just financial -- a denied claim after a major incident also carries reputational and regulatory consequences.","mitigatedBy":["CA-07","PM-31","CA-05","AU-01"]},{"id":"T-IS-014","name":"Multi-framework drift where ISO 27001, SOC 2, NIS2, DORA and ISO 42001 control sets diverge over time","description":"Organisations subject to multiple frameworks simultaneously frequently end up operating parallel control sets per framework, which then drift apart -- the same control is described differently, evidenced differently and remediated differently in each programme. Auditors increasingly cite the divergence as a finding under all the affected frameworks, and the maintenance overhead diverts resources from actual control improvement. PM-31 (continuous monitoring strategy) and CA-07 require a single monitoring backbone; PL-01 (planning) and CA-01 (assessment policy) require unified policy and assessment authority; PL-09 (Central Management) operationalises the single-set discipline. The architectural mitigation is a single internal control set with framework mappings maintained as a thin overlay rather than separate control implementations per framework.","mitigatedBy":["PM-31","CA-07","PL-01","CA-01","PL-09"]},{"id":"T-IS-015","name":"Management body insufficient training or competence to discharge ISMS accountability under NIS2 and DORA","description":"NIS2 Article 20(2) and DORA Article 5(4) require members of the management body to maintain sufficient knowledge and skills to understand and assess cybersecurity risks. The threat materialises where the management body delegates cybersecurity competence wholesale to the CISO and treats ISMS oversight as a status-update exercise -- making approval decisions (risk appetite, scope changes, supplier engagements) without the technical literacy to evaluate trade-offs. Post-incident, regulators and prosecutors examine whether the management body could competently exercise its accountability; gaps invite personal liability under NIS2 Art. 20(1). PM-02 names the Senior Information Security Officer who supports the management body; PM-29 (Risk Management Program Leadership) names the senior-leadership risk role; AT-02 and AT-03 deliver the role-based training; PM-13 (Security and Privacy Workforce) ensures the workforce plan includes management-body competence as a workforce element.","mitigatedBy":["PM-02","PM-29","AT-02","AT-03","PM-13"]}],"controls":[{"id":"AT-01","name":"Policy and Procedures","family":"AT","emphasis":"important"},{"id":"AT-02","name":"Literacy Training and Awareness","family":"AT","emphasis":"important"},{"id":"AT-03","name":"Role-based Training","family":"AT","emphasis":"important"},{"id":"AU-01","name":"Policy and Procedures","family":"AU","emphasis":"important"},{"id":"CA-01","name":"Policy and Procedures","family":"CA","emphasis":"critical"},{"id":"CA-02","name":"Control Assessments","family":"CA","emphasis":"critical"},{"id":"CA-03","name":"Information Exchange","family":"CA","emphasis":"standard"},{"id":"CA-04","name":"Security Certification","family":"CA","emphasis":"important"},{"id":"CA-05","name":"Plan of Action and Milestones","family":"CA","emphasis":"critical"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"critical"},{"id":"IR-01","name":"Policy and Procedures","family":"IR","emphasis":"standard"},{"id":"PL-01","name":"Policy and Procedures","family":"PL","emphasis":"critical"},{"id":"PL-02","name":"System Security and Privacy Plans","family":"PL","emphasis":"important"},{"id":"PL-04","name":"Rules of Behavior","family":"PL","emphasis":"important"},{"id":"PL-09","name":"Central Management","family":"PL","emphasis":"important"},{"id":"PL-10","name":"Baseline Selection","family":"PL","emphasis":"important"},{"id":"PM-01","name":"Information Security Program Plan","family":"PM","emphasis":"critical"},{"id":"PM-02","name":"Information Security Program Leadership Role","family":"PM","emphasis":"critical"},{"id":"PM-03","name":"Information Security and Privacy Resources","family":"PM","emphasis":"important"},{"id":"PM-06","name":"Measures of Performance","family":"PM","emphasis":"important"},{"id":"PM-09","name":"Risk Management Strategy","family":"PM","emphasis":"critical"},{"id":"PM-11","name":"Mission and Business Process Definition","family":"PM","emphasis":"important"},{"id":"PM-13","name":"Security and Privacy Workforce","family":"PM","emphasis":"important"},{"id":"PM-29","name":"Risk Management Program Leadership Roles","family":"PM","emphasis":"important"},{"id":"PM-31","name":"Continuous Monitoring Strategy","family":"PM","emphasis":"critical"},{"id":"PS-01","name":"Policy and Procedures","family":"PS","emphasis":"important"},{"id":"PS-09","name":"Position Descriptions","family":"PS","emphasis":"important"},{"id":"RA-01","name":"Policy and Procedures","family":"RA","emphasis":"critical"},{"id":"RA-02","name":"Security Categorization","family":"RA","emphasis":"important"},{"id":"RA-03","name":"Risk Assessment","family":"RA","emphasis":"critical"},{"id":"RA-07","name":"Risk Response","family":"RA","emphasis":"critical"},{"id":"RA-09","name":"Criticality Analysis","family":"RA","emphasis":"important"},{"id":"SA-02","name":"Allocation of Resources","family":"SA","emphasis":"important"},{"id":"SR-01","name":"Policy and Procedures","family":"SR","emphasis":"critical"},{"id":"SR-02","name":"Supply Chain Risk Management Plan","family":"SR","emphasis":"critical"},{"id":"SR-03","name":"Supply Chain Controls and Processes","family":"SR","emphasis":"important"}],"controlFamilySummary":{"AT":3,"AU":1,"CA":6,"IR":1,"PL":5,"PM":9,"PS":2,"RA":5,"SA":1,"SR":3}}}