Designing and Implementing an ISMS

Scope definition is the most consequential early decision in an ISMS implementation. A scope that excludes a critical asset or system means that asset is unprotected by the management framework and unexamined in the certification audit. A scope that includes every system and process in a large organisation from the start often means the risk assessment never reaches an actionable level of detail and the implementation stalls.

ISO/IEC 27001 clause 4.3 requires the scope to be determined by considering the external and internal issues identified in clause 4.1, the requirements of interested parties identified in clause 4.2, and the interfaces and dependencies between the organisation's own activities and those of external entities. In practice, this means the scope document should explicitly list: which legal entities are included, which sites or data centre locations are covered, which information assets and services are in scope, and which are explicitly excluded. The exclusions are as important as the inclusions; an auditor will probe whether excluded items should reasonably be inside.

A practical scoping approach is to start with the information assets that carry the highest sensitivity or regulatory significance: customer personal data, financial records, intellectual property, or systems that underpin a regulated service. Map those assets to the processes and locations that handle them. The resulting boundary is the initial scope. Once the first certification cycle is complete, the scope can be extended. Certification bodies will review and certify a scope extension at a subsequent surveillance or recertification audit.

The risk assessment is the engine of an ISMS. It identifies what information assets exist within scope, what threats and vulnerabilities affect them, what the likelihood and impact of harm would be, and what the resulting risk level is. The risk treatment step decides what to do: accept the risk, transfer it (for example via insurance or a contract clause), avoid it by discontinuing the activity, or reduce it by applying controls.

ISO/IEC 27001 does not mandate a specific risk assessment methodology. It requires only that the process is consistent, repeatable, and produces comparable results. Organisations commonly use qualitative scoring matrices (likelihood 1-5 by impact 1-5, yielding a risk score), qualitative-ordinal scales (high/medium/low), or quantitative approaches such as annualised loss expectancy calculations. See Risk Assessment Methodologies for a comparison of the main approaches and their trade-offs.

The risk treatment plan records the output of treatment decisions. For each risk selected for reduction, it identifies which Annex A controls (or other controls) will be applied, who is responsible for implementing them, and by when. This document is the direct link between the risk assessment and the SoA. An auditor who finds an Annex A control in the SoA with no corresponding risk or business requirement in the risk treatment plan will raise a nonconformity.

Annex A is not a mandatory checklist: it is a reference set of controls. The organisation selects which controls to implement based on the risk treatment plan. If a risk has been accepted or transferred, the corresponding Annex A controls may be excluded, provided the justification is documented. If a risk has been identified for reduction, the controls that address it are selected and included.

Implementing a control means more than writing a policy that describes what should happen. The auditor looks for evidence that the control operates in practice. For access control (Annex A 5.15 to 5.18), evidence includes: provisioning and de-provisioning records, access review logs, privileged account inventories, and authentication configuration screenshots. For cryptography (Annex A 8.24), evidence includes: a cryptography policy, key management procedures, and configuration records showing which algorithms are in use. Each control needs an evidence owner, a review cadence, and a record.

The 2022 revision introduced 11 new controls that organisations upgrading from the 2013 edition must address. These include: threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23), and secure coding (8.28). Many organisations already implement these practices; the 2022 edition makes them explicit control requirements.

The Statement of Applicability is required by ISO/IEC 27001 clause 6.1.3(d). It must: list the necessary controls determined from the risk assessment and treatment process; include all applicable Annex A controls and justify any exclusions; and state whether each control has been implemented. In practice most organisations structure the SoA as a spreadsheet or table with one row per Annex A control.

A well-constructed SoA row contains: the Annex A control reference (for example, 8.5 Secure authentication), a statement of inclusion or exclusion, the justification (for inclusions, typically the risk or legal requirement that drives it; for exclusions, the reason it does not apply), the implementation status (not started, in progress, implemented, or not applicable), and a reference to the evidence document or system. Keeping the evidence reference in the SoA makes the auditor's job straightforward and reduces interview time.

The SoA must be authorised by management before the certification audit. It is a living document: whenever the risk assessment is updated or a new control is implemented or removed, the SoA must be updated to reflect the change. Version control and a change history are therefore essential. Some certification bodies require that the SoA version submitted for the stage 2 audit matches the version reviewed at the stage 1 audit; discrepancies cause delays.

ISO/IEC 27001 specifies a minimum set of documents and records that must exist for the management system to be certifiable. These are not optional: their absence is an automatic major nonconformity. The mandatory documented information includes: scope document, information security policy, risk assessment process and results, risk treatment plan, Statement of Applicability, information security objectives, evidence of competence, results of monitoring and measurement, internal audit programme and results, management review results, and corrective action records.

Audit readiness means two things. First, the documents exist and are current. Second, staff can demonstrate that the documented controls are actually operating. An auditor who asks a system administrator how access provisioning works should get an answer that matches the access control procedure. An auditor who asks when the last management review was held should be able to see the minutes and the action log. The gap between documented practice and actual practice is the most common cause of major nonconformities in first-time certification audits.

Internal audits are a prerequisite for external certification. Clause 9.2 requires the organisation to plan and conduct internal audits at planned intervals to check whether the ISMS conforms to the standard's requirements and whether it has been effectively implemented. The internal audit must be carried out by someone who is not responsible for the area being audited, and the results must be reported to management. Certification auditors review internal audit reports to assess whether the organisation has already identified and addressed its own gaps.

Most ISMS implementation failures follow recognisable patterns. Scope creep is the most common: the organisation includes every system and location from the start, the risk assessment takes six months to complete, and the momentum collapses before controls are in place. The remedy is a deliberately narrow initial scope with a documented expansion plan.

Policy-only implementation is the second failure mode. The organisation produces a complete set of ISO/IEC 27001-shaped policies, marks all controls as implemented in the SoA, and arrives at the audit with no records showing the controls operate. Auditors call this a paper ISMS. The stage 2 audit will find major nonconformities against almost every clause. The test is simple: for each included control, ask what evidence would convince a sceptical auditor that the control is working today. If the answer is "our policy says so", more work is needed.

Management disengagement is the third pitfall. ISO/IEC 27001 places explicit requirements on top management in clause 5: demonstrating leadership, setting the information security policy, ensuring roles are assigned, and integrating security requirements into business processes. If the ISMS is run entirely by an IT manager with no visible senior leadership involvement, the management review evidence is thin and the corrective action loop has no authority behind it. This produces recurring nonconformities rather than genuine improvement.

• Readiness indicator 1: The risk assessment has been reviewed by asset owners, not just written by the security team.
• Readiness indicator 2: The SoA exclusion justifications are specific to the organisation's context, not copied from a template.
• Readiness indicator 3: At least one full internal audit cycle has been completed, with findings and corrective actions documented.
• Readiness indicator 4: Staff in scope can describe the controls that apply to their work without reading from a document.
• Readiness indicator 5: Management review minutes include actual performance data (audit results, incidents, objective measurements) and decisions, not just attendance records.