Runbook 01 — ISO/IEC 27001 Implementation & Certification Readiness

Runbook Information

Item	Details
Runbook	01 — ISO/IEC 27001 Implementation & Certification Readiness
Module	ISO/IEC 27001
Difficulty	Advanced
Estimated Time	Multi-Week Enterprise Workflow
Primary Role	GRC Analyst / ISMS Manager
Supporting Roles	CISO, Risk Owners, Control Owners, Internal Audit, Legal, HR, IT, Security, Engineering
Primary Output	Certification-Ready ISMS
Runbook Type	ISO/IEC 27001 Implementation & Assurance

Purpose

This runbook provides a repeatable procedure for taking an organization from the initial decision to implement ISO/IEC 27001 through certification readiness.

The process covers:

ISO Initiative
      ↓
Context
      ↓
Scope
      ↓
Governance
      ↓
Gap Assessment
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Statement of Applicability
      ↓
Control Implementation
      ↓
Evidence
      ↓
Internal Audit
      ↓
Management Review
      ↓
Corrective Action
      ↓
Stage 1 Readiness
      ↓
Stage 2 Readiness
      ↓
Certification
      ↓
Surveillance

The objective is not merely to create documentation.

The objective is to build an ISMS that can demonstrate:

Clear business alignment.
Defined accountability.
Consistent risk management.
Appropriate control selection.
Operating security controls.
Reliable evidence.
Independent assurance.
Leadership oversight.
Continual improvement.

Runbook Success Outcome

The organization should be able to answer:

What is in our ISMS?

Why is it in scope?

What are our major risks?

How are those risks treated?

Which controls are applicable?

Who owns each control?

Is each control operating?

What evidence proves it?

What did internal audit find?

What has management reviewed?

What corrective actions remain?

Are we ready for certification?

Phase 1 — Initiate the ISO Program

Step 1 — Confirm the Business Driver

Document why the organization is implementing ISO/IEC 27001.

Common drivers include:

Customer requirement.
Enterprise sales.
Security maturity.
Regulatory expectations.
Contractual commitments.
Market expansion.
Supplier assurance.
Internal governance improvement.

Example:

Business Driver:
Enterprise customers increasingly require
independent information-security assurance.

Avoid beginning the program with:

We need the certificate.

Instead ask:

What business objective will the ISMS support?

Step 2 — Confirm Executive Sponsorship

Identify an executive sponsor.

Example:

Executive Sponsor:
CISO

Executive Oversight:
Risk Committee

The sponsor should have sufficient authority to:

Allocate resources.
Resolve disputes.
Escalate risk.
Approve direction.
Support cross-functional participation.

Step 3 — Appoint ISMS Leadership

Identify:

ISMS Owner

ISMS Manager

GRC Lead

Executive Sponsor

Record clear responsibilities.

Step 4 — Establish Project Governance

Create a project governance structure.

Example:

Executive Sponsor
      ↓
ISMS Steering Committee
      ↓
ISMS Manager
      ↓
GRC
      ↓
Workstream Owners

Create a governance calendar.

Phase 2 — Understand Organizational Context

Step 5 — Identify Internal Issues

Facilitate a context workshop.

Consider:

Business strategy.
Organizational growth.
Technology architecture.
Security maturity.
Staffing.
Legacy systems.
Cloud adoption.
Remote workforce.
Acquisitions.
Organizational dependencies.

Record each relevant issue.

Example:

Issue:
Rapid cloud adoption

Potential Impact:
Increased configuration and identity risk

Step 6 — Identify External Issues

Consider:

Threat landscape.
Regulatory changes.
Customer expectations.
Supply-chain risk.
Technology changes.
Market requirements.
Geopolitical factors.

Example:

Issue:
Increasing ransomware attacks

ISMS Impact:
Improve recovery assurance and privileged access

Step 7 — Build the Context Register

Use:

Field	Example
ID	CTX-001
Issue	Rapid cloud adoption
Type	Internal
Security Impact	Cloud governance risk
Owner	CIO
Review	Quarterly

Step 8 — Establish Context Review

Define:

Owner:
GRC

Review:
Quarterly / Event Driven

Triggers may include:

Major incidents.
Acquisitions.
New products.
New regulations.
New locations.
New critical vendors.

Phase 3 — Identify Interested Parties & Requirements

Step 9 — Identify Interested Parties

Typical parties include:

Customers

Employees

Regulators

Suppliers

Partners

Executive Management

Shareholders

Certification Body

Step 10 — Capture Requirements

For each party, determine relevant information-security requirements.

Example:

Interested Party:
Enterprise Customer

Requirement:
Protect confidential customer information
and notify material security incidents.

Step 11 — Build Requirements Register

Use:

ID	Requirement	Source	Owner	ISMS Impact
REQ-001	Encrypt customer data	Contract	Security	Encryption
REQ-002	Annual vendor review	Policy	GRC	TPRM
REQ-003	Incident notification	Regulation	Legal	IR

Step 12 — Assign Requirement Owners

Examples:

Legal
→ Regulatory requirements

GRC
→ Security framework requirements

Procurement
→ Supplier contractual requirements

Sales / Legal
→ Customer security commitments

Phase 4 — Define ISMS Scope

Step 13 — Identify Critical Business Services

Start with business services rather than systems.

Example:

Critical Service:
Enterprise SaaS Platform

Then map supporting:

Applications

Infrastructure

Identity

Data

People

Processes

Suppliers

Step 14 — Map Dependencies

Create:

Business Service
      ↓
Application
      ↓
Cloud Platform
      ↓
Identity
      ↓
Database
      ↓
Third Parties

Identify:

Upstream dependencies.
Downstream dependencies.
Shared services.
Out-of-scope interfaces.

Step 15 — Define Boundaries

Document:

Products

Services

Business Units

Locations

Personnel

Technology

Supporting Processes

Step 16 — Evaluate Exclusions

Ask:

Is the exclusion genuinely outside the ISMS?
Does it support an in-scope service?
Does it introduce an interface?
Can exclusion create unmanaged risk?

Do not exclude components merely to reduce audit effort.

Step 17 — Draft Scope Statement

Example:

The ISMS covers the design, development, operation, maintenance, and support of the organization’s enterprise SaaS platform and supporting production cloud infrastructure, identity services, security operations, engineering processes, and personnel supporting those services.

Step 18 — Obtain Scope Approval

Record:

Scope Owner

Version

Approval

Effective Date

Phase 5 — Establish ISMS Governance

Step 19 — Define Roles

Identify:

Executive Sponsor.
CISO.
ISMS Manager.
GRC.
Risk Owners.
Control Owners.
Process Owners.
Internal Audit.

Step 20 — Build the RACI

Include:

Scope

Policy

Risk Assessment

Risk Treatment

SoA

Control Operation

Internal Audit

Management Review

Corrective Action

Step 21 — Define Risk Authority

Example:

Residual Risk	Approval
Low	Manager
Moderate	Director
High	CISO
Critical	Executive Risk Committee

Step 22 — Establish Steering Committee

Typical participants:

CISO

GRC

IT

Engineering

Legal

HR

Procurement

Business Leadership

Step 23 — Create Governance Calendar

Track:

Risk review.
Policy review.
Control review.
Internal audit.
Management review.
Certification activities.

Phase 6 — Perform Initial ISO Gap Assessment

Step 24 — Build Clause-Level Checklist

Assess Clauses 4–10.

For each requirement record:

Requirement

Current State

Evidence

Status

Gap

Action

Owner

Target

Use statuses:

Conformant

Partially Conformant

Nonconformant

Not Assessed

Step 25 — Assess Annex A Readiness

Review the relevant control environment.

Do not immediately build a final SoA.

At this stage identify:

Existing controls.
Missing controls.
Unclear ownership.
Missing evidence.
Process weaknesses.

Step 26 — Create Gap Register

Example:

Gap	Area	Severity	Owner	Target
GAP-001	Internal Audit	High	GRC	Oct
GAP-002	Vendor Reviews	High	TPRM	Nov
GAP-003	Document Control	Medium	GRC	Sep

Step 27 — Prioritize Gaps

Consider:

Certification Criticality

Risk

Implementation Time

Dependencies

Resource Needs

Phase 7 — Establish Risk Assessment Methodology

Step 28 — Define Risk Model

Document:

Likelihood

Impact

Risk Matrix

Risk Ratings

Acceptance Criteria

Risk Ownership

Review Frequency

Step 29 — Define Likelihood

Example:

Score	Rating
1	Rare
2	Unlikely
3	Possible
4	Likely
5	Almost Certain

Step 30 — Define Impact

Consider:

Financial

Operational

Customer

Legal

Regulatory

Reputational

Step 31 — Define Risk Matrix

Example:

Risk Score =
Likelihood × Impact

Document rating thresholds.

Step 32 — Define Acceptance Criteria

Example:

Low
→ Acceptable

Moderate
→ Owner Review

High
→ Treatment / Senior Approval

Critical
→ Immediate Escalation

Phase 8 — Perform Information Security Risk Assessment

Step 33 — Define Assessment Scope

Align with the ISMS scope.

Step 34 — Identify Assets & Services

Include:

Information

Applications

Cloud Platforms

Identity

Endpoints

Processes

People

Third Parties

Step 35 — Identify Threats

Examples:

External attack.
Insider threat.
Ransomware.
Human error.
Cloud failure.
Supply-chain compromise.
Data leakage.

Step 36 — Identify Vulnerabilities

Examples:

Weak MFA

Excessive Access

Missing Patch

Cloud Misconfiguration

Weak Vendor Governance

Untested Recovery

Step 37 — Develop Risk Statements

Use:

There is a risk that [threat/event] may exploit [condition], resulting in [business impact].

Step 38 — Assess Inherent Risk

Score before existing controls.

Step 39 — Identify Existing Controls

For each risk record:

Control ID

Control Description

Owner

Evidence

Effectiveness

Step 40 — Evaluate Control Effectiveness

Use:

Effective

Partially Effective

Ineffective

Not Tested

Step 41 — Determine Residual Risk

Recalculate risk based on the existing control environment.

Step 42 — Assign Risk Owner

Every material risk requires an accountable owner.

Step 43 — Complete Risk Register

Minimum fields:

Risk ID

Risk Statement

Business Service

Asset

Threat

Vulnerability

Inherent Risk

Controls

Control Effectiveness

Residual Risk

Risk Owner

Treatment

Phase 9 — Develop Risk Treatment Plan

Step 44 — Evaluate Risks Against Acceptance Criteria

For each risk decide:

Mitigate

Avoid

Transfer

Accept

Step 45 — Select Controls

Consider:

Existing controls.
Annex A.
Legal requirements.
Contractual requirements.
Additional internal controls.

Step 46 — Create Treatment Actions

Weak:

Improve IAM.

Strong:

Deploy phishing-resistant MFA for all privileged production accounts.

Step 47 — Assign Treatment Owner

Distinguish:

Risk Owner

Treatment Owner

Control Owner

Step 48 — Set Target Dates

Prioritize based on risk and dependencies.

Step 49 — Define Target Residual Risk

Example:

Current:
High

Target:
Moderate

Step 50 — Obtain Risk Owner Approval

Document treatment approval.

Step 51 — Maintain RTP

Include:

Risk

Treatment

Control

Owner

Target

Target Residual Risk

Status

Evidence

Phase 10 — Build Statement of Applicability

Step 52 — Review Annex A

Consider the full Annex A control set.

For each control determine:

Applicable

Not Applicable

Step 53 — Determine Applicability Drivers

Possible drivers:

Risk

Legal

Regulatory

Contract

Business

Internal Policy

Step 54 — Document Inclusion Justification

Example:

Applicable because the organization relies on privileged access to production cloud services, and strong authentication is necessary to treat credential-compromise risk.

Step 55 — Document Exclusion Justification

Avoid:

Not needed.

Provide specific organizational context.

Step 56 — Identify Inherited Controls

Example:

Data Center Physical Security
→ Cloud Provider

Document provider assurance.

Step 57 — Identify Shared Controls

Example:

Business Continuity

Provider:
Infrastructure resilience

Organization:
Application recovery

Step 58 — Record Implementation Status

Use consistent statuses:

Implemented

Partially Implemented

Planned

Not Implemented

Inherited

Shared

Step 59 — Assign Control Owners

Avoid generic ownership such as:

IT

where a specific accountable role exists.

Step 60 — Link Risks

Map:

Risk
      ↓
Treatment
      ↓
Control
      ↓
SoA

Step 61 — Link Evidence

Reference supporting evidence.

Step 62 — Approve the SoA

Record:

Owner.
Version.
Review.
Approval.

Phase 11 — Build Enterprise Control Library

Step 63 — Translate Reference Controls

Create testable internal controls.

Example:

Control ID:
IAM-003

Control:
Quarterly Privileged Access Review

Statement:

The IAM team reviews all privileged production access quarterly and removes unauthorized access within five business days.

Step 64 — Define Control Attributes

Include:

Control ID

Objective

Statement

Owner

Operator

Frequency

Population

Evidence

Risk Mapping

Framework Mapping

Step 65 — Distinguish Control Type

Classify:

Preventive

Detective

Corrective

and:

Manual

Automated

Hybrid

Phase 12 — Implement Control Gaps

Step 66 — Create Remediation Backlog

For every gap:

Gap

Risk

Action

Owner

Target

Status

Step 67 — Implement Controls

Work with responsible teams.

Examples:

IAM
→ MFA / PAM

Security
→ Logging / Monitoring

Engineering
→ Secure SDLC

IT
→ Backup / Recovery

GRC
→ Supplier Security

Step 68 — Document Exceptions

Where full implementation is not possible:

Exception
      ↓
Risk Assessment
      ↓
Compensating Controls
      ↓
Approval
      ↓
Expiration

Step 69 — Validate Implementation

Do not rely solely on:

Implemented.

Require evidence.

Phase 13 — Establish Evidence Management

Step 70 — Create Evidence Register

Fields:

Evidence ID

Control

Evidence

Owner

Frequency

Period

Location

Retention

Step 71 — Define Expected Evidence

Examples:

Control	Evidence
MFA	Coverage Report
Access Review	Review Record
Vulnerability Mgmt	Scan + Ticket
Backup	Recovery Test
Vendor Review	Assessment
Logging	SIEM Coverage

Step 72 — Establish Evidence Repository

Structure example:

ISO27001/
│
├── Governance
├── Risk
├── SoA
├── Controls
├── Evidence
├── Audit
├── Management Review
└── Corrective Actions

Step 73 — Protect Sensitive Evidence

Apply:

Access control.
Encryption.
Need-to-know access.
Appropriate retention.

Phase 14 — Establish Security Objectives & Metrics

Step 74 — Define Information Security Objectives

Example:

Achieve 100% privileged MFA coverage.

Complete all critical vendor assessments.

Improve critical vulnerability remediation SLA.

Step 75 — Define KPI/KRI

Example:

KPI:
% Critical vulnerabilities remediated within SLA

KRI:
Critical vulnerabilities older than 30 days

Step 76 — Define Owners & Targets

Track:

Objective	Target	Owner	Status

Step 77 — Establish Monitoring Cadence

Possible cadence:

Monthly

Quarterly

Annual

depending on metric.

Phase 15 — Perform Pre-Audit Control Readiness Review

Step 78 — Select Critical Controls

Prioritize:

IAM.
Logging.
Vulnerability management.
Vendor security.
Incident response.
Recovery.

Step 79 — Validate Control Design

Ask:

Does the control address the risk?

Is scope defined?

Is ownership clear?

Is frequency appropriate?

Does it generate evidence?

Step 80 — Validate Operating Effectiveness

Check actual execution.

Example:

Quarterly Review Required

Q1 ✓
Q2 ✓
Q3 ✗
Q4 ✓

Do not mark this fully effective.

Step 81 — Update SoA Status

SoA should reflect actual control implementation.

Phase 16 — Perform Internal Audit

Step 82 — Establish Audit Program

Define:

Scope

Criteria

Frequency

Auditor

Schedule

Step 83 — Maintain Auditor Objectivity

Avoid uncontrolled self-audit.

Step 84 — Prepare Audit Plan

Include:

Clauses.
Processes.
Controls.
Evidence.
Interviews.
Sampling.

Step 85 — Perform Testing

Audit:

ISMS Clauses
+
Applicable Controls

Step 86 — Document Findings

Use:

Criteria

Condition

Evidence

Risk

Finding

Step 87 — Issue Audit Report

Provide:

Executive summary.
Scope.
Findings.
Overall conclusion.
Corrective actions.

Phase 17 — Correct Internal Audit Findings

Step 88 — Perform Correction

Address immediate issue.

Step 89 — Perform Root Cause Analysis

Avoid:

Human error.

Identify systemic cause.

Step 90 — Develop Corrective Action

Example:

Problem:
Quarterly review missed

Corrective Action:
Automate scheduling and escalation

Step 91 — Assign Owner & Target

Track centrally.

Step 92 — Retest

Do not close solely on owner statement.

Verify evidence.

Step 93 — Close or Reopen

Use:

Pass
→ Close

Fail
→ Continue Remediation

Phase 18 — Conduct Management Review

Step 94 — Prepare Management Review Pack

Include:

Previous Actions

Context Changes

Risk Status

Objectives

Metrics

Audit Results

Incidents

Supplier Risk

Corrective Actions

Improvement Opportunities

Step 95 — Conduct Formal Review

Leadership should participate.

Step 96 — Capture Decisions

Example:

Decision:
Accelerate PAM implementation

Owner:
IAM Director

Target:
Q1

Step 97 — Capture Resource Needs

Management review should address resource constraints.

Step 98 — Maintain Minutes

Record:

Attendees.
Inputs.
Decisions.
Actions.
Owners.
Dates.

Phase 19 — Perform Certification Readiness Assessment

Step 99 — Reassess Clauses 4–10

Verify:

Implemented

Operating

Evidenced

Step 100 — Reconcile Key Artifacts

Compare:

Risk Register
vs
RTP
vs
SoA
vs
Control Library
vs
Evidence

Resolve contradictions.

Step 101 — Confirm Internal Audit Complete

Check open findings.

Step 102 — Confirm Management Review Complete

Check decisions and actions.

Step 103 — Review Open Gaps

Classify:

Certification Blocking

High Priority

Manageable / Monitored

Step 104 — Determine Readiness

Use:

Ready

Conditionally Ready

Not Ready

Document rationale.

Phase 20 — Select Certification Body

Step 105 — Define Certification Requirements

Document:

Scope.
Locations.
Target date.
Industry requirements.
Customer expectations.

Step 106 — Evaluate Providers

Consider:

Accreditation

Industry Experience

Auditor Competence

Geographic Coverage

Timeline

Cost

Step 107 — Confirm Audit Schedule

Schedule:

Stage 1

Stage 2

Potential Follow-Up

Phase 21 — Prepare for Stage 1

Step 108 — Create Stage 1 Evidence Pack

Include:

Scope

Context

Interested Parties

Policy

Risk Methodology

Risk Register

RTP

SoA

Objectives

Internal Audit

Management Review

Step 109 — Prepare Key Stakeholders

Likely participants:

ISMS Manager.
GRC.
CISO.
Relevant process owners.

Step 110 — Track Audit Requests

Use:

Request	Owner	Due	Status

Step 111 — Address Stage 1 Issues

Immediately:

Issue
      ↓
Owner
      ↓
Action
      ↓
Evidence
      ↓
Validation

Phase 22 — Prepare for Stage 2

Step 112 — Confirm Stage 1 Actions Complete

Do not proceed blindly if significant readiness issues remain.

Step 113 — Build Stage 2 Interview Schedule

Include:

Leadership

GRC

IAM

Security Operations

Engineering

IT

HR

Procurement

Step 114 — Prepare Evidence Owners

They should know:

What control they own.
How it works.
Where evidence exists.
Known exceptions.

Step 115 — Prepare Audit Request Tracker

Track:

Request ID

Auditor

Owner

Evidence

Time

Status

Follow-Up

Step 116 — Perform Evidence Quality Review

Before submission confirm:

Correct Period?

Correct Scope?

Complete?

Sensitive Data Minimized?

Current Version?

Phase 23 — Support Stage 2 Audit

Step 117 — Coordinate Opening Meeting

Confirm:

Scope.
Schedule.
Audit team.
Communication.
Evidence process.

Step 118 — Support Interviews

Do not coach scripted answers.

Personnel should describe real processes.

Step 119 — Support Control Walkthroughs

Auditor may follow:

Risk
      ↓
Control
      ↓
Procedure
      ↓
Evidence
      ↓
Sample

Step 120 — Respond to Findings Professionally

If factual disagreement exists:

Clarify requirement.
Present evidence.
Correct misunderstandings.

Do not hide valid weaknesses.

Phase 24 — Manage Certification Findings

Step 121 — Record Every Finding

Maintain:

Finding ID

Requirement

Classification

Condition

Root Cause

Action

Owner

Target

Evidence

Status

Step 122 — Correct Immediate Issue

Where needed.

Step 123 — Perform Root Cause Analysis

Determine why failure occurred.

Step 124 — Define Corrective Action

Prevent recurrence.

Step 125 — Submit Evidence

Follow certification-body requirements.

Step 126 — Support Follow-Up Verification

Where required.

Phase 25 — Certification Decision

Step 127 — Confirm Closure Status

Ensure required findings are satisfactorily addressed.

Step 128 — Review Certificate Scope

Verify wording reflects intended ISMS boundaries.

Step 129 — Record Certification Details

Maintain:

Certification Body

Certificate Number

Scope

Issue Date

Expiry / Cycle Dates

Surveillance Schedule

Phase 26 — Transition to Continuous ISMS Operation

Certification is not the end.

Move immediately to operational maintenance.

Step 130 — Maintain Risk Register

Update when:

Risks change.
Controls fail.
New technologies appear.
Incidents occur.

Step 131 — Maintain RTP

Track outstanding treatments.

Step 132 — Maintain SoA

Update after:

New Risk

Control Change

Scope Change

Requirement Change

Supplier Change

Step 133 — Maintain Evidence Calendar

Collect evidence throughout the year.

Avoid audit-season scrambling.

Step 134 — Maintain Policy Calendar

Track review dates.

Step 135 — Continue Control Testing

Use periodic assurance.

Phase 27 — Prepare for Surveillance Audits

Step 136 — Review Previous Findings

Confirm ongoing effectiveness.

Step 137 — Review Changes Since Last Audit

Examples:

New Cloud Provider

Acquisition

New Product

Major Incident

New Regulation

Step 138 — Update Audit Package

Include:

Updated risks.
Updated SoA.
Internal audit.
Management review.
Metrics.
Corrective actions.

Step 139 — Verify Continuous Improvement

Auditor should see evidence that the ISMS evolved.

Phase 28 — Recertification Preparation

Step 140 — Reperform Comprehensive Readiness Review

Review the complete ISMS.

Step 141 — Confirm Scope Still Accurate

Business may have changed significantly.

Step 142 — Confirm Control Environment Still Appropriate

Risks and technology evolve.

Step 143 — Reconcile All Governance Artifacts

Ensure consistency.

Step 144 — Prepare for Recertification Assessment

Use the same disciplined evidence and coordination process.

Operational ISO Implementation Checklist

Program Initiation

Business driver documented.
Executive sponsor identified.
ISMS Manager assigned.
Governance established.
Resources identified.

Context & Scope

Internal issues documented.
External issues documented.
Interested parties identified.
Requirements captured.
Critical services mapped.
Dependencies mapped.
ISMS scope approved.

Risk

Risk methodology approved.
Risk criteria defined.
Acceptance criteria defined.
Risk assessment completed.
Risk owners assigned.
Residual risks documented.

Treatment

Treatment strategy selected.
Controls selected.
Treatment owners assigned.
Target dates established.
Target residual risk defined.
RTP approved.

SoA

Annex A reviewed.
Applicability determined.
Inclusion justifications documented.
Exclusions justified.
Inherited/shared controls documented.
Implementation status validated.
Owners identified.
Risks mapped.
Evidence linked.
SoA approved.

Controls & Evidence

Enterprise controls defined.
Owners assigned.
Frequencies defined.
Evidence expectations defined.
Control gaps remediated.
Exceptions governed.
Evidence repository established.

Performance Evaluation

Security objectives defined.
KPIs defined.
KRIs defined.
Internal audit completed.
Audit findings recorded.
Corrective actions tracked.
Retesting completed.

Management Review

Review pack prepared.
Leadership participated.
Decisions documented.
Resources reviewed.
Actions assigned.

Certification

Readiness assessment complete.
Certification body selected.
Stage 1 evidence prepared.
Stage 1 issues addressed.
Stage 2 interviews scheduled.
Evidence tracker ready.
Findings remediation process ready.
Certification scope verified.

Continuous Operation

Risk register maintained.
RTP maintained.
SoA maintained.
Evidence collected continuously.
Policies reviewed.
Controls monitored.
Surveillance readiness maintained.

Quick Reference — Certification Readiness Decision Tree

ISMS Scope Defined?
      │
      ├── No → Define Scope
      │
      └── Yes
             ↓
Risk Assessment Current?
      │
      ├── No → Complete Assessment
      │
      └── Yes
             ↓
RTP & SoA Current?
      │
      ├── No → Update
      │
      └── Yes
             ↓
Controls Implemented?
      │
      ├── No → Remediate / Govern Exceptions
      │
      └── Yes
             ↓
Evidence Available?
      │
      ├── No → Establish Evidence
      │
      └── Yes
             ↓
Internal Audit Complete?
      │
      ├── No → Perform Audit
      │
      └── Yes
             ↓
Material Findings Closed?
      │
      ├── No → Correct & Retest
      │
      └── Yes
             ↓
Management Review Complete?
      │
      ├── No → Conduct Review
      │
      └── Yes
             ↓
Certification Ready

Recommended ISMS Repository

ISO27001-ISMS/
│
├── 01-Governance/
│   ├── ISMS-Scope
│   ├── Context-Register
│   ├── Interested-Parties
│   └── RACI
│
├── 02-Risk/
│   ├── Risk-Methodology
│   ├── Risk-Register
│   └── Risk-Acceptance
│
├── 03-Risk-Treatment/
│   └── RTP
│
├── 04-SoA/
│   ├── Statement-of-Applicability
│   └── Risk-Control-Mapping
│
├── 05-Controls/
│   ├── Control-Library
│   └── Ownership
│
├── 06-Policies/
│
├── 07-Evidence/
│
├── 08-Internal-Audit/
│
├── 09-Management-Review/
│
├── 10-Corrective-Actions/
│
└── 11-Certification/

Common Implementation Failures

Failure 1 — Starting With Policies

The organization writes dozens of policies before understanding scope and risk.

Better:

Context
→ Scope
→ Risk
→ Controls
→ Policies

Failure 2 — Treating ISO as Annex A Only

Clauses 4–10 are central to the ISMS.

Failure 3 — Risk Register Built Only for Audit

Risk should drive decisions throughout the year.

Failure 4 — SoA Copied From a Template

Applicability should reflect actual context.

Failure 5 — No Control Owners

Controls degrade without accountability.

Failure 6 — Evidence Collected at the Last Minute

Continuous evidence management is stronger.

Failure 7 — Internal Audit Is Superficial

Internal audit should test operation, not just documents.

Failure 8 — Management Review Is a Presentation

Management should make decisions.

Failure 9 — Corrective Actions Address Symptoms

Root causes remain.

Failure 10 — Certification Becomes the End Goal

The ISMS must continue operating after certification.

Practical GRC Mindset

A weak ISO implementation asks:

What documents does the auditor want?

A better implementation asks:

What processes and controls do we need to demonstrate conformity?

A mature implementation asks:

How do we build a sustainable management system that continuously connects business requirements, risk, controls, evidence, assurance, leadership, and improvement?

That is the mindset required to operate ISO/IEC 27001 effectively.

Runbook Deliverables

A completed implementation package should contain:

01 — Business Case & Governance

02 — Context Register

03 — Interested Parties Register

04 — Requirements Register

05 — ISMS Scope

06 — ISMS RACI

07 — ISO Gap Assessment

08 — Risk Assessment Methodology

09 — Information Security Risk Register

10 — Risk Treatment Plan

11 — Statement of Applicability

12 — Enterprise Control Library

13 — Control Ownership Matrix

14 — Evidence Register

15 — Security Objectives & Metrics

16 — Internal Audit Program

17 — Internal Audit Report

18 — Corrective Action Register

19 — Management Review Pack

20 — Management Review Minutes

21 — Certification Readiness Assessment

22 — Stage 1 Evidence Pack

23 — Stage 2 Audit Tracker

24 — Certification Finding Tracker

25 — Surveillance Calendar

Runbook Completion Criteria

The organization is ready to proceed confidently toward certification when:

Scope is defensible

Leadership is engaged

Risk methodology is operational

Risk register is current

RTP is current

SoA reflects reality

Controls are implemented

Evidence is available

Internal audit is complete

Material findings are addressed

Management review is complete

Certification evidence is organized

Control owners understand their responsibilities

Runbook Complete

You now have a repeatable end-to-end workflow for taking an organization from:

ISO Initiative

to:

Certification-Ready ISMS

and then into:

Surveillance
      ↓
Continuous Improvement
      ↓
Recertification

This workflow can be used by GRC Analysts, ISO/IEC 27001 Consultants, ISMS Managers, Security Compliance Analysts, Security Assurance professionals, and internal governance teams implementing ISO/IEC 27001 in enterprise environments.

What’s Next?

➡️ Next: Runbook 02 — ISO/IEC 27001 Internal Audit, Nonconformity & Corrective Action Management

In the next and final runbook for this ISO/IEC 27001 module, you will operationalize the ongoing assurance lifecycle:

Build Audit Program
      ↓
Plan Audit
      ↓
Collect Evidence
      ↓
Test Controls
      ↓
Identify Nonconformities
      ↓
Perform Root Cause Analysis
      ↓
Define Corrective Actions
      ↓
Track Remediation
      ↓
Retest
      ↓
Close Findings
      ↓
Feed Results Into Management Review

The runbook will focus on how a GRC or ISMS team manages the internal audit and corrective-action process continuously, rather than treating it only as a pre-certification exercise.