Appearance
Operationalizing ISO/IEC 27001:2022 in Modulos
ISO 27001 becomes manageable when the ISMS is treated as an operating model — scope, risk assessment, control execution, evidence, continual improvement, repeated. This page is the implementation playbook for running the ISMS on Modulos using the OFF-9 + MFF-9 framework templates.
Quick decision
- You are starting a fresh ISMS rollout → one organisation project with OFF-9, plus AI-system projects with MFF-9.
- You already run ISO 42001 (AIMS) or 27701 (PIMS) → add OFF-9 to the existing organisation project; reuse the shared Annex SL management-system processes (document control, internal audit, management review, corrective action); only stand up information-security-specific work.
- You are building the Statement of Applicability → the SoA is mandatory under Clause 6.1.3 d. Store as control-level evidence on
ORF-205. Every Annex A control gets a position. - You need to scope the AI-system MFF-9 work → MFF-9 records the per-AI-system information-security overlap (operational Clause 8.2 risk assessment + 8.3 risk treatment). One MFF-9 project per AI system in scope.
TL;DR
- Two framework templates map ISO 27001:
OFF-9(org, 28 ORF requirements) +MFF-9(app, 2 MRF requirements). - Two project layers: organisation project for the ISMS spine; AI-system projects for per-system overlap.
- ISMS spine on the org project: scope, policy, risk method + SoA, internal audit, management review, corrective action.
- Per-AI-system overlap on the app project: information-security risk assessment + treatment for each AI deployment.
- Statement of Applicability = mandatory under Clause 6.1.3 d. Owner-authored documentation stored as evidence on
ORF-205. - IMS integration with ISO 42001 / 27701: share Clauses 4–10 processes; keep standard-specific risk and control work explicit.
Primary source
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Modulos framework templates: OFF-9 (org) and MFF-9 (app) in modulos_platform/content/templates/frameworks/. Available via the ISO Online Browsing Platform. © ISO.
Recommended project structure
| Project | Template | When to use |
|---|---|---|
| One organisation project | OFF-9 (add to existing org project if you already run ISO 42001 / 27701) | Scope statement, information-security policy, Annex SL processes, Statement of Applicability, internal audit, management review, corrective action |
| AI-system projects | MFF-9 | Per-AI-system information-security risk assessment + treatment |
The split mirrors the standard's logic: organisation-wide ISMS spine on one side; per-system operational work on the other.
Set up: a sequence that works
1
Add OFF-9 to your org project
Apply the ISMS template alongside any existing ISO 42001 / 27701 templates.
2
Define the ISMS scope
Clause 4.3 scope statement: boundaries, locations, systems, interfaces.
3
Build the Statement of Applicability
Every Annex A control gets a position. SoA is mandatory under Clause 6.1.3 d.
4
Run info-security risk + treatment
Clause 6.1.2 risk assessment and 6.1.3 treatment with Annex A selection.
5
Add MFF-9 per AI system
Per-system information-security risk assessment + treatment.
6
Operate, audit, review, improve
Annex A control evidence, internal audit, management review, corrective action.
How to operationalise ISO 27001 in Modulos
OFF-9 (org-level) mapping:
| ISMS element | OFF-9 requirement | Clause |
|---|---|---|
| Organisational context | ORF-196 | 4.1 |
| Interested parties | ORF-197 | 4.2 |
| ISMS scope | ORF-198 | 4.3 |
| ISMS itself | ORF-199 | 4.4 |
| Leadership commitment | ORF-200 | 5.1 |
| Information-security policy | ORF-201 | 5.2 |
| Roles and responsibilities | ORF-202 | 5.3 |
| Risk and opportunities — general | ORF-203 | 6.1.1 |
| Information-security risk assessment | ORF-204 | 6.1.2 |
| Information-security risk treatment + Statement of Applicability | ORF-205 | 6.1.3 (incl. 6.1.3 d) |
| Information-security objectives | ORF-206 | 6.2 |
| Planning of changes | ORF-207 | 6.3 |
| Resources / competence / awareness / communication | ORF-208–ORF-211 | 7.1–7.4 |
| Documented information | ORF-212 / ORF-213 / ORF-214 | 7.5.1–7.5.3 |
| Operational planning and control | ORF-215 | 8.1 |
| Monitoring + measurement | ORF-216 | 9.1 |
| Internal audit + audit programme | ORF-217 / ORF-218 | 9.2.1 / 9.2.2 |
| Management review (process / inputs / outputs) | ORF-219 / ORF-220 / ORF-221 | 9.3.1 / 9.3.2 / 9.3.3 |
| Continual improvement | ORF-222 | 10.1 |
| Nonconformity and corrective action | ORF-223 | 10.2 |
MFF-9 (app-level) mapping:
| Requirement | Clause | Topic |
|---|---|---|
MRF-221 | 8.2 | Information-security risk assessment (per AI system) |
MRF-222 | 8.3 | Information-security risk treatment (per AI system) |
Operating rules:
- Scope, policy, risk method, SoA, internal audit, management review live on OFF-9. One organisation project per organisation.
- Per-AI-system information-security risk + treatment live on MFF-9. One MFF-9 project per AI system in scope.
- The Statement of Applicability is owner-authored documentation stored as control-level evidence on
ORF-205. The SoA carries the per-Annex-A-control decisions; operational evidence for each control sits on Modulos controls that link to the relevant Clauses 6.1.3 / 8.1 requirements.
What is first-class UI vs evidence-attached
- First-class — Modulos exposes the OFF-9 / MFF-9 framework template on the project (Settings → Frameworks) and the requirement readiness signal on each ORF / MRF requirement.
- Evidence-attached (no dedicated UI) — Statement of Applicability, risk-assessment method document, risk register, control execution records, internal-audit programme + reports, management-review minutes, corrective-action records, supplier assessments. Each is owner-authored documentation stored as control-level evidence on the relevant requirement.
ISO 27001 doesn't prescribe the form of these artefacts — only that they exist, are current and are reviewable. Locking them into a prescribed workflow would defeat the standard's risk-driven intent.
Cross-framework mapping (preview)
| ISO 27001 element | Adjacent provision |
|---|---|
| Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope |
| Clause 5.2 information-security policy | ISO 42001 Clause 5.2 AI policy; ISO 27701 Clause 5.2 privacy policy |
| Clause 6.1.2 information-security risk assessment | ISO 42001 Clause 6.1.2 AI risk assessment; ISO 31000 |
| Clause 6.1.3 risk treatment + SoA | ISO 42001 Clause 6.1.3; EU AI Act Article 9 RMS |
| Annex A theme 5 (supplier relationships) | EU AI Act Article 25 value chain; NIS2 Article 21(2)(d); ISO 42001 Annex A.10 |
| Annex A theme 5 (incident management) | EU AI Act Article 73 serious-incident reporting; GDPR Article 33 |
| Annex A theme 8 (cryptography, logging) | EU AI Act Article 12 logging; Article 15(5) cybersecurity |
| Clauses 7.5 / 9.2 / 9.3 / 10.2 (shared Annex SL) | ISO 42001 / 27701 same clauses — implement once, share evidence |
IMS integration — ISO 27001 + 42001 + 27701
ISO management-system standards share the Annex SL backbone, which makes IMS integration realistic. The shared layer is document control (Clause 7.5), internal audit (Clause 9.2), management review (Clause 9.3), corrective action (Clause 10.2), competence (Clause 7.2) and communication (Clause 7.4). What stays standard-specific:
- ISO 27001: information-security risk + treatment + Annex A (normative) information-security controls.
- ISO 42001: AI policy, AI risk + impact (6.1.2/3/4), Annex A (informative) AI lifecycle and data controls.
- ISO 27701: privacy risk, PII controller / processor distinctions, Annex A / Annex B privacy controls.
Practical pattern in Modulos: add the relevant OFF templates to the same organisation project; share evidence across them where a single control satisfies multiple obligations (e.g., a single internal-audit programme that covers ISMS + AIMS + PIMS).
Related: Integration with AI governance · ISO 42001 vs ISO 27001 comparison.
Common pitfalls
- Treating Annex A as a checklist. "We have all Annex A controls" with thin evidence does not pass Stage 2.
- Stale SoA. Controls remain "implemented" after the system or vendor has changed. The SoA needs to live with the ISMS.
- Internal audit as document review. Auditors expect operational sampling — control execution records, decisions, evidence — not just policy completeness.
- Mixing ISMS work with product execution. The org project holds the management-system spine; per-AI-system MFF projects hold the operational evidence. Keeping them separate keeps review queues legible.
- Reproducing Annex A control text. © ISO. Reference Annex A controls by theme and reference number; describe the implementation in your own words.
Related pages
ISO 27001 overview
Hub: ISMS structure, Annex SL backbone, Annex A themes, certification path
ISMS foundations (scope + SoA + certification)
Scope, Statement of Applicability, Stage 1 / Stage 2 / surveillance / recertification
Clauses 4–10 (implementation guide)
Annex SL backbone — Context, Leadership, Planning, Support, Operation, Performance evaluation, Improvement
Annex A (controls reference)
93 controls in four themes — organizational, people, physical, technological
Integration with AI governance
How ISO 27001 supports ISO 42001 AIMS and the EU AI Act
Source attribution
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements, Clauses 4–10 + Annex A. © ISO/IEC. Available via the ISO Online Browsing Platform. Modulos framework templates OFF-9 and MFF-9 in modulos_platform/content/templates/frameworks/.
Disclaimer
This page is for general informational purposes and does not constitute legal or certification advice.