Mapped to ISO/IEC 27001:2022 clauses. 12 steps and the PDCA grouping from the footer, with clause references and compressed each deliverable into the subtitle.
The obligation to connect security to business direction lives in:
- 5.1 a) — top management ensures the IS policy and objectives are compatible with the strategic direction of the organization
- 6.2 — IS objectives must be consistent with the IS policy, measurable, monitored, and resourced
So 4.1/4.2 is where you capture what's true about the business and who has a claim on it. The objectives linkage is a separate thread. Auditors will ask about both, and conflating them is why context documents so often read as filler.
What goes in the document
4.1 — internal and external issues. Two tables, not a narrative. Each row needs a "so what" or it doesn't belong.
| Issue | Type | Relevance to the ISMS | Traced to |
|---|---|---|---|
| Enterprise buyers require SOC 2 + ISO cert before procurement | External | Certification is a revenue gate, not a compliance cost | OBJ-01, scope decision SD-02 |
| Single-tenant deployments for 3 largest clients | Internal | Divergent control environments, patching lag | R-014, R-021 |
| DORA applies to our EU financial-sector clients from Jan 2025 | External | Contractual flow-down of ICT risk obligations | R-008, A.5.19 |
| Engineering team of 11, no dedicated security headcount | Internal | Constrains control design toward automation | Resourcing decision, 7.1 |
Keep it to 10–20 rows total. A 60-row context register signals you copied a template.
4.2 — interested parties. The 2022 version added a third requirement most 2013-era documents miss: you must record which of those requirements the ISMS will address. Deciding "no" is legitimate — but the decision has to be visible.
| Interested party | Requirement | Source | Addressed by ISMS | Where |
|---|---|---|---|---|
| Enterprise customers | Encryption at rest, breach notice ≤ 24h | MSA §7, DPA | Yes | A.8.24, A.5.26 |
| Data subjects (EU) | Lawful basis, DSAR fulfilment | GDPR Art. 6, 15 | Partial | PIMS, not ISMS scope |
| Certification body | Evidence of clauses 4–10 | ISO 27001:2022 | Yes | Full ISMS |
| Investors | No material security events pre-raise | Board mandate | Yes | 9.3 review inputs |
| Insurer | MFA on all admin access | Cyber policy Q14 | Yes | A.5.17, A.8.5 |
Where the objectives linkage actually goes
Add a short section — half a page — that puts each business objective next to the IS objective serving it. This is what satisfies 5.1 a) and gives 6.2 somewhere to land:
| Business objective | IS objective | Measure | Owner |
|---|---|---|---|
| Close 3 enterprise deals in FY26 | Maintain ISO 27001 cert with zero majors | Audit outcome | CEO |
| Reduce security questionnaire cycle time | Standing evidence pack, 5-day turnaround | Days to respond | Head of Ops |
| Launch EU region | Zero unresolved high risks at go-live | Risk register | CTO |
Audit tips
- Date it and revise it. A context register with one version and a creation date two years old is a finding waiting to happen. Review at least annually and after any material change — new region, new regulation, acquisition, major client class.
- Point the risk register back at it. When an auditor asks "why is this risk on your register," the strongest answer is a context row ID. Bidirectional traceability is rare and it reads as maturity.
- Feed 4.3 explicitly. Your scope statement should cite context issues as justification for what's in and out. Exclusions justified by context survive scrutiny; exclusions justified by convenience don't.
- Make it a management review input. 9.3.2 requires review of changes in external and internal issues relevant to the ISMS. If the context register isn't a standing agenda item, you have a gap in two clauses at once.
Print 