ISO 27001 with OCTAVE Allegro on the UN Umoja case — Part 1

• We’ll follow OCTAVE Allegro for risk assessment; in Part 1 we prep what Part 2–7 will build on.

Why this series (and what you’ll get)

This is a practical, step-by-step series that rebuilds an ISO 27001 ISMS around Data & Applications in the UN Umoja context, using OCTAVE Allegro for risk assessment. It’s based on a structured audit case (simulated exercise) that documents the path from Clause 4 all the way to risk treatment, mapping threats to controls, and defining measurable KPIs.

Clause 4: Understand the context before you set the scope

ISO/IEC 27001 requires you to understand internal and external context (Clause 4) and only then define your ISMS scope (Clause 4.3). Internal context includes structure, roles, strategy, resources, culture, processes, and contracts. External context covers stakeholders and environmental factors (political, economic, social, technological, environmental).

• In the Umoja-style case, we focus on Data & Applications as the scoped domain for the ISMS.
• Part 2 will turn the external context into a practical PEST and a prioritized stakeholder map you can act on.

What is Clause 4 (ISO/IEC 27001): “Context of the Organization” ?

Clause 4 tells you to set the foundations of your ISMS before you touch risk numbers. It has four sub-clauses:

• 4.1 Understand the organization and its context

Identify internal and external factors that affect information security (structure, strategy, culture, tech stack; market, regulations, geopolitics, etc.).

• 4.2 Understand the needs and expectations of interested parties

List stakeholders (management, users, customers, regulators, suppliers, auditors) and the requirements they impose (laws, contracts, SLAs, policies).

• 4.3 Determine the scope of the ISMS

Draw the boundary of what’s in and out: locations, processes, systems, data, people, and interfaces with out-of-scope parties. Produce a one-paragraph scope statement.

• 4.4 ISMS

Declare that you will establish, implement, maintain, and continually improve the ISMS within that scope.

Typical outputs:

• 1–2 pages on internal/external context,
• a stakeholder/requirements list,
• a clear scope statement (with boundaries and interfaces).

Mini example (scope statement):

“The ISMS covers Data & Applications supporting the Umoja ERP, including production and staging environments hosted at X, identities managed in Y, and the SDLC process of teams A/B. Outsourced hosting (Z) and field-office networks are out of scope but treated as interfaces with defined controls and responsibilities.”

Some Explanations about the terms used in this reports.

ISMS = Information Security Management System

An ISMS is the management framework an organization uses to protect information systematically — not just with tech, but with policies, processes, roles, controls, and metrics. ISO/IEC 27001:2022 is the international standard that specifies how to establish, implement, maintain, and continually improve an ISMS.

What it aims to protect

• Confidentiality (only the right people see it)
• Integrity (it isn’t altered improperly)
• Availability (it’s there when needed)
• …often plus authenticity, traceability, and non-repudiation.

How 27001 structures an ISMS (PDCA cycle)

• Plan

Clause 4: Context & scope

Clause 5: Leadership & policy

Clause 6: Risk methodology, risk/objectives planning

Clause 7: Support (resources, competence, awareness, documented info)

• Do

Clause 8: Operation — run the risk assessment (e.g., OCTAVE Allegro), risk treatment, implement controls.

• Check

Clause 9: Monitoring & measurement, KPIs, internal audits, management review.

• Act

Clause 10: Nonconformities, corrective actions, continual improvement.

Controls & guidance

• Annex A (27001) → the control set to choose from (and justify in your Statement of Applicability, SoA).
• ISO/IEC 27002 → guidance/how-to for implementing those controls (now grouped into organizational, people, physical, technological).

Core ISMS artifacts (what auditors expect to see)

• Scope statement (what’s in/out + interfaces)
• ISMS policy
• Risk assessment method (criteria, scales) & Risk Register
• Statement of Applicability (SoA) & Risk Treatment Plan
• Policies/procedures (access control, change mgmt, backup, incident mgmt, supplier security, secure dev, etc.)
• Asset inventory & classification
• Training/awareness records
• KPIs/metrics & monitoring evidence
• Internal audit program & reports
• Management review minutes
• Corrective actions & improvements

Certification (optional but common)

• Independent accredited auditors certify against 27001.
• Cycle: 3 years (year 1 certification, years 2–3 surveillance audits), then recert.

Where this fits the article series

• Part 1 : Clause 4 context + scope, and how that feeds your risk method (OCTAVE).
• Later parts: run the RA, compute RRS, select controls → SoA, define KPIs, and close the loop with audits & management review.

Quick starter checklist

• One-paragraph scope (systems, data, locations, people, interfaces)
• ISMS policy signed by leadership
• Risk method (criteria, scales, acceptance) chosen (e.g., OCTAVE)
• Asset inventory & classification
• First Risk Register + SoA + Treatment Plan
• Metrics/KPIs to track effectiveness
• Internal audit plan & management review cadence

OCTAVE Allegro — how we’ll use it in this series

We’ll follow OCTAVE Allegro (SEI/CMU) because it scales well, uses practical worksheets, and cleanly separates criteria, asset profiles, threat scenarios, and risk analysis. In Part 1 we prepare Step 1 and Step 2; later parts will cover Steps 3–8 (threats, RRS scoring, risk pools, treatment options).

• Step 1 — Risk Measurement Criteria. Define impact areas and what High/Moderate/Low mean for yourorganization. These criteria drive later decisions (RRS and prioritization).
• Step 2 — Critical Information Asset Profiles. Profile key information assets (boundaries, CIA needs, owner/custodian, containers, dependencies) using Worksheet 8. In this case we integrate NIST SP 800–60 and FIPS 199/200 so “information asset” is treated as an information type with a security category.

https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-60v1r1.pdf?utm_source=chatgpt.com

The Relative Risk Score (RRS) we’ll use later

Later (Step 7), OCTAVE Allegro applies a Relative Risk Score: multiply the area rank by the impact value (H=3, M=2, L=1), sum by columns to get the RRS, then place each risk in pools for treatment. It’s a relative ordering tool, not an absolute risk value.

Pre-work checklist (finish this before Part 2)

• Write the project purpose and the ISMS scope in 5 lines each.
• One-page internal & external context summary (Clause 4).
• Draft a list of 8–12 stakeholders with influence/impact ranking.
• Quick PEST draft (political, economic, social, technological, environmental) with one “so-what for security?” line per factor.
• Draft asset classes & owners for your inventory (A.8).
• Draft impact areas and initial H/M/L criteria (for Step 1).

What “PEST” means

PEST is a simple framework to structure the external part of Clause 4. It groups macro factors into:

• P — Political: laws, regulations, public policy, geopolitical stability.
• Security angle: compliance obligations, export controls, sanctions, data-sovereignty.
• E — Economic: budgets, market cycles, exchange rates, supply-chain health.
• Security angle: control affordability, vendor risk, capacity to patch/monitor.
• S — Social: culture, media scrutiny, privacy expectations, workforce skills.
• Security angle: awareness programs, incident communication, insider risk.
• T — Technological: cloud/SaaS adoption, legacy systems, new threats, automation.
• Security angle: hardening, patching cadence, IAM/MFA, encryption, logging.

Variants you may see: PESTEL/PESTLE adds Legal and Environmental explicitly.

How it fits together:

• Use PEST to capture the external context (Clause 4.1).
• Map stakeholders (Clause 4.2).
• Use both to justify your ISMS scope (4.3) and to set risk criteria for OCTAVE Step 1.

References

• ISO/IEC 27001 (ISMS) — overview and Online Browsing Platform: iso.org
• OCTAVE Allegro (SEI/CMU) — official page and technical report PDF: overview
• NIST SP 800–60 Vol. I Rev. 1 — mapping information types to security categories: CSRC page
• FIPS 199 — security categorization of federal information/systems: CSRC page
• FIPS 200 — minimum security requirements: CSRC page

Several definitions, process choices, and the use of an RRS as a relative ordering tool are derived from the underlying case document.

What’s next (Part 2)

Stakeholders & PEST for Umoja — a practical map of interests and expectations, plus a concise PEST with “so-what for security” for each factor. We’ll then lock our Step-1 criteria and Step-2 asset profiles with concrete examples.