02 Build an ISMS

Welcome to the second project in:

Module 11 — Enterprise GRC Transformation Project

In the previous project, you performed an:

Enterprise Risk Assessment

You moved through:

Business Context
      ↓
Critical Services
      ↓
Assets & Dependencies
      ↓
Threats
      ↓
Risk Scenarios
      ↓
Controls
      ↓
Residual Risk
      ↓
Risk Treatment

Now the organization needs a structured system for managing those risks continuously.

You will build an:

Information Security
Management System

or:

ISMS

An ISMS transforms security from:

Individual Security
Activities

into:

Governed

Risk-Based

Documented

Measurable

Auditable

Continually Improving

enterprise security management.

Project Objective

Your objective is to design a practical ISMS for:

CloudNova Technologies

You will create:

Business Context
      ↓
ISMS Scope
      ↓
Leadership & Governance
      ↓
Risk Management
      ↓
Security Objectives
      ↓
Policies
      ↓
Control Framework
      ↓
Statement of Applicability
      ↓
Evidence
      ↓
Performance Monitoring
      ↓
Internal Audit
      ↓
Management Review
      ↓
Corrective Actions
      ↓
Continual Improvement

By the end of this project, you should understand how the different pieces of an enterprise security program fit together.

Mission Information

Project Type: Enterprise ISMS Design
Difficulty: Intermediate to Advanced
Estimated Time: 4–6 Hours
Primary Role: GRC Analyst / ISMS Analyst
Supporting Roles: CISO / Risk / Security / IT / HR / Legal / Privacy / Internal Audit / Business Leadership
Environment: Spreadsheet, documentation platform, ticketing system, or GRC platform
Reference: ISO/IEC 27001 principles
Deliverable: Enterprise ISMS Design Pack

Learning Objectives

By completing this project, you will learn how to:

understand the purpose of an ISMS.
define organizational context.
identify interested parties.
identify stakeholder requirements.
define ISMS boundaries.
create an ISMS scope statement.
establish information security governance.
define security roles and responsibilities.
establish an information security policy.
integrate enterprise risk management.
define risk assessment methodology.
create risk-treatment processes.
define information security objectives.
establish measurable security targets.
create an enterprise policy hierarchy.
select appropriate security controls.
build a Statement of Applicability.
assign control ownership.
identify control evidence.
establish security metrics and KPIs.
monitor ISMS performance.
design an internal audit program.
establish management reviews.
manage nonconformities.
create corrective actions.
establish continual improvement.
create an ISMS governance calendar.
prepare an organization for ISO 27001 readiness.

Scenario

CloudNova Technologies has completed its first formal enterprise cyber-risk assessment.

Management now understands risks including:

Privileged Account Compromise

Ransomware

Cloud Misconfiguration

Critical Vulnerabilities

Third-Party Compromise

Software Supply-Chain Risk

Service Availability

Privacy Risk

However, the assessment reveals another problem.

Security activities exist across the organization, but they operate independently.

For example:

IAM Team
Manages Access

Security Team
Manages Vulnerabilities

SOC
Monitors Events

HR
Manages Joiners and Leavers

Procurement
Manages Vendors

Engineering
Manages Cloud

BCM
Manages Recovery

Each team performs security-related work.

But management asks:

Who Governs
the Entire Security
Program?

Another question follows:

How Do We Know
All These Activities
Work Together?

That is the purpose of an ISMS.

Your Mission

Build a management system that allows CloudNova to:

Identify Risk

Select Controls

Assign Ownership

Operate Controls

Collect Evidence

Measure Performance

Audit Controls

Review Results

Correct Problems

Improve Continuously

Required Deliverables

Create:

01 ISMS Context Assessment

02 Interested Parties Register

03 ISMS Scope Statement

04 ISMS Governance Structure

05 Roles & Responsibilities Matrix

06 Information Security Policy

07 Risk Management Methodology

08 Risk Treatment Process

09 Information Security Objectives

10 Policy Framework

11 Control Register

12 Statement of Applicability

13 Evidence Register

14 ISMS Metrics Register

15 Internal Audit Program

16 Management Review Process

17 Corrective Action Register

18 Continual Improvement Register

19 ISMS Governance Calendar

20 ISMS Executive Summary

Part 1 — Understand the ISMS

An ISMS is not simply:

Security Policies

and it is not:

ISO Documentation

An ISMS is a:

Management System

for systematically managing information security.

Conceptually:

Business
   ↓
Security Risks
   ↓
ISMS
   ↓
Policies
   ↓
Controls
   ↓
Operations
   ↓
Measurement
   ↓
Assurance
   ↓
Improvement

Part 2 — Think in Management-System Terms

A mature ISMS asks:

What Are We
Protecting?

What Risks
Exist?

What Controls
Are Needed?

Who Owns Them?

Are They Operating?

Are They Effective?

Can We Prove It?

What Is Failing?

What Must Improve?

Part 3 — Understand Organizational Context

Before designing controls, understand:

Organization

Business

Customers

Technology

Regulation

Threat Environment

Strategic Direction

For CloudNova:

Business:
Enterprise SaaS

Customers:
Global Enterprises

Technology:
AWS
Kubernetes
Microsoft 365
GitHub
SaaS Platforms

Operations:
India
United States
European Union

Security Goals:
Customer Trust
Risk Reduction
ISO 27001 Readiness
SOC 2 Readiness

Part 4 — Identify Internal Issues

Internal issues can affect the ISMS.

Examples:

Rapid Growth

Cloud-First Architecture

Remote Workforce

Limited GRC Automation

Decentralized Engineering

Multiple Product Teams

Growing Vendor Ecosystem

Security Skills Availability

Part 5 — Identify External Issues

External issues may include:

Cyber Threats

Customer Requirements

Regulatory Changes

Technology Changes

Supply-Chain Risk

Market Expectations

Industry Standards

Part 6 — Create Context Register

Create:

Issue	Type	ISMS Impact	Owner
Rapid Growth	Internal	Control scalability	COO
Cloud Adoption	Internal	Cloud governance	CTO
Cyber Threats	External	Risk exposure	CISO
Customer Assurance	External	Certification	Sales/GRC
Regulation	External	Compliance	Legal

Part 7 — Identify Interested Parties

An ISMS serves more than the security department.

Interested parties may include:

Customers

Employees

Executive Leadership

Board

Regulators

Shareholders

Suppliers

Cloud Providers

Business Partners

Auditors

Part 8 — Determine Their Requirements

Example:

Interested Party	Requirement
Customers	Protect customer information
Regulators	Meet applicable obligations
Employees	Protect employee information
Executives	Manage material cyber risk
Auditors	Demonstrate control effectiveness
Suppliers	Clear security requirements

Part 9 — Build Interested Parties Register

Record:

Party

Relationship

Security Requirement

Legal Requirement

Contractual Requirement

ISMS Relevance

Owner

Review Frequency

Part 10 — Define ISMS Scope

One of the most important decisions is:

What Is
Inside the ISMS?

Define:

Business Units

Products

Services

Locations

People

Processes

Technology

Information

Third Parties

Part 11 — Avoid an Ambiguous Scope

Weak:

CloudNova
Information Security

Better:

The ISMS covers the people,
processes, technology,
information assets, and
supporting services used
to develop, operate, secure,
and support CloudNova's
enterprise SaaS platform.

Part 12 — Define Physical Boundaries

Document locations such as:

Corporate Offices

Remote Workforce

Cloud Regions

Data Centers

Third-Party Facilities

Part 13 — Define Technology Boundaries

Include relevant:

AWS Accounts

Kubernetes Clusters

Microsoft 365

GitHub

Identity Platform

Corporate Endpoints

Security Platforms

Production Applications

Part 14 — Define Organizational Boundaries

Determine:

Which Legal Entities?

Which Departments?

Which Employees?

Which Contractors?

Part 15 — Define Interfaces and Dependencies

Your ISMS may depend on:

Cloud Providers

Identity Providers

Payment Providers

SaaS Vendors

Managed Services

Internet Providers

These dependencies should be understood.

Part 16 — Create ISMS Scope Statement

Example:

The CloudNova Technologies
Information Security Management
System covers the people,
processes, technologies,
information assets, and
third-party dependencies
supporting the development,
delivery, operation, and
security of CloudNova's
enterprise SaaS services.

The scope includes production
cloud infrastructure,
corporate IT, software
development, security
operations, customer support,
and supporting business
functions.

This is a project example.

Actual scope statements must reflect the real organization.

Part 17 — Establish Leadership Commitment

An ISMS cannot be owned only by:

GRC Analyst

Leadership must demonstrate commitment through:

Direction

Resources

Accountability

Risk Decisions

Management Review

Security Objectives

Part 18 — Establish ISMS Governance

Design:

Board / Executive Leadership
          ↓
Executive Risk Committee
          ↓
CISO
          ↓
ISMS Steering Committee
          ↓
GRC / Security Governance
          ↓
Control Owners
          ↓
Operational Teams

Part 19 — Define Governance Forums

Example:

Board Risk Review
Quarterly

Executive Risk Committee
Quarterly

ISMS Steering Committee
Monthly

Operational Security Review
Monthly

Control Owner Review
Quarterly

Part 20 — Define Roles

Identify:

Executive Sponsor

CISO

ISMS Manager

Risk Manager

Control Owner

Policy Owner

Asset Owner

Risk Owner

Internal Auditor

Evidence Owner

Part 21 — Define Responsibility Model

Example:

Role	Responsibility
Executive Sponsor	Strategic oversight
CISO	Security accountability
ISMS Manager	ISMS operation
Risk Owner	Risk decisions
Control Owner	Control effectiveness
Policy Owner	Policy maintenance
Internal Audit	Independent assurance

Part 22 — Build RACI Matrix

Example:

Activity	CISO	GRC	Control Owner	Internal Audit	Executive
Risk Assessment	A	R	C	I	I
Control Operation	I	C	R/A	I	I
Internal Audit	I	C	C	R/A	I
Management Review	R	C	C	I	A
Risk Acceptance	C	R	C	I	A

Adapt responsibilities to the organization’s governance model.

Part 23 — Establish Information Security Policy

The organization needs a top-level:

Information
Security Policy

It should establish management’s direction for information security.

Part 24 — Policy Should Address

Include:

Purpose

Scope

Security Objectives

Risk-Based Approach

Compliance

Responsibilities

Policy Enforcement

Review

Continual Improvement

Part 25 — Example Policy Statement

CloudNova Technologies
is committed to protecting
the confidentiality,
integrity, and availability
of information through
risk-based security controls,
defined accountability,
continuous monitoring,
compliance with applicable
requirements, and continual
improvement of the ISMS.

Part 26 — Create Policy Hierarchy

Design:

Information Security Policy
          ↓
Domain Policies
          ↓
Standards
          ↓
Procedures
          ↓
Guidelines
          ↓
Operational Records

Part 27 — Domain Policies

Create or reference policies for:

Access Control

Asset Management

Acceptable Use

Cryptography

Cloud Security

Vulnerability Management

Logging & Monitoring

Incident Response

Supplier Security

Secure Development

Business Continuity

Data Protection

Human Resources Security

Part 28 — Connect Policies to Risk

Do not create policies merely because:

ISO Says
We Need Documents

Instead:

Risk
      ↓
Security Requirement
      ↓
Policy
      ↓
Control
      ↓
Procedure
      ↓
Evidence

Part 29 — Integrate Risk Management

Your previous enterprise-risk project now becomes part of the ISMS.

Use:

Risk Identification

Risk Analysis

Risk Evaluation

Risk Treatment

Risk Acceptance

Risk Monitoring

Part 30 — Define Risk Methodology

Document:

Risk Identification Method

Likelihood Scale

Impact Scale

Risk Calculation

Risk Levels

Risk Appetite

Risk Acceptance Authority

Treatment Requirements

Review Frequency

Part 31 — Risk Assessment Workflow

Identify
   ↓
Analyze
   ↓
Evaluate
   ↓
Treat
   ↓
Accept
   ↓
Monitor
   ↓
Reassess

Part 32 — Define Risk Criteria

Example:

Likelihood:
1–5

Impact:
1–5

Risk Score:
Likelihood × Impact

Risk categories:

Low

Moderate

High

Critical

Part 33 — Establish Risk Acceptance Criteria

Example:

Low
Operational Acceptance

Moderate
Risk Owner Approval

High
Executive Approval

Critical
Executive Committee Review

This must reflect organizational authority.

Part 34 — Create Risk Treatment Process

For risks outside appetite:

Risk
   ↓
Treatment Decision
   ↓
Control Selection
   ↓
Action Plan
   ↓
Owner
   ↓
Target Date
   ↓
Implementation
   ↓
Validation
   ↓
Residual Risk

Part 35 — Treatment Options

Use:

Mitigate

Avoid

Transfer

Accept

Part 36 — Link Treatment to Controls

Example:

Risk:
Privileged Account
Compromise

Treatment:

Enforce MFA

Deploy PAM

Perform Access Reviews

Monitor Privileged Activity

These become part of the ISMS control environment.

Part 37 — Establish Security Objectives

Security objectives should support:

Business Objectives

Risk Treatment

Compliance

Customer Requirements

Security Strategy

Part 38 — Avoid Generic Objectives

Weak:

Improve Security

Better:

Achieve 100% MFA
coverage for privileged
accounts by Q2.

Part 39 — Example Objectives

100% Privileged MFA Coverage

95% Critical Vulnerabilities
Remediated Within SLA

100% Critical Vendors
Assessed Annually

100% Critical Services
Recovery Tested Annually

100% High-Risk Findings
Assigned Treatment Plans

Part 40 — Define Objective Record

Document:

Objective

Metric

Baseline

Target

Owner

Deadline

Measurement Method

Status

Part 41 — Select Security Controls

Control selection should be driven by:

Risk

Legal Requirements

Contractual Requirements

Business Requirements

ISO 27001 Requirements

not simply:

Copy Every
Control

Part 42 — Create Control Register

For each control record:

Control ID

Control Name

Control Objective

Control Description

Control Owner

Risk

Policy

Framework Mapping

Evidence

Frequency

Status

Part 43 — Example Control

Control ID:
IAM-001

Control:
Privileged MFA

Objective:
Prevent unauthorized
privileged access.

Owner:
IAM Manager

Frequency:
Continuous

Evidence:
Identity Configuration
Access Reports
Monitoring Logs

Part 44 — Understand the Statement of Applicability

One of the most important ISMS artifacts is the:

Statement of
Applicability

or:

SoA

The SoA explains:

Which Controls
Are Applicable?

Which Are Not?

Why?

Are They
Implemented?

Part 45 — Do Not Treat the SoA as a Checklist

Weak approach:

Control
✓ Yes

Professional approach:

Control

Applicability

Justification

Implementation Status

Control Owner

Evidence

Internal Control Mapping

Part 46 — Build SoA

Example:

Control	Applicable	Justification	Status	Owner
Access Control	Yes	Privileged systems	Implemented	IAM
Logging	Yes	Detection requirement	Implemented	SOC
Supplier Security	Yes	Critical SaaS vendors	Partial	TPRM
Physical Control	Review	Cloud operating model	Review	Security

The actual SoA must use the applicable ISO control structure and organizational context.

Part 47 — Link SoA to Risk

Example:

Risk R-001
Privileged Compromise
        ↓
Risk Treatment
        ↓
Access Controls
        ↓
Internal Controls
        ↓
ISO Mapping
        ↓
Statement of Applicability

Part 48 — Establish Control Ownership

Every control should answer:

Who Is
Accountable?

Example:

IAM Controls
→ IAM Manager

Vulnerability Controls
→ Security Engineering

Logging Controls
→ SOC

Vendor Controls
→ TPRM

HR Controls
→ HR

Part 49 — Control Owner Responsibilities

Control owners should:

Operate Control

Maintain Procedures

Collect Evidence

Monitor Performance

Remediate Failures

Support Audits

Part 50 — Establish Evidence

A control without evidence creates an assurance problem.

For each control determine:

What Evidence
Proves This
Control Operated?

Part 51 — Evidence Examples

Access Reviews

System Configurations

Screenshots

Logs

Tickets

Reports

Approvals

Meeting Minutes

Training Records

Test Results

Part 52 — Create Evidence Register

Example:

Control	Evidence	Frequency	Owner	Location
IAM-001	MFA Report	Monthly	IAM	GRC Repository
VM-001	Vulnerability Report	Weekly	Security	Scanner
TPRM-001	Vendor Assessment	Annual	TPRM	GRC Platform
BCM-001	Recovery Test	Annual	BCM	Evidence Repository

Part 53 — Evidence Must Be Reliable

Good evidence should be:

Relevant

Complete

Accurate

Traceable

Current

Protected

Part 54 — Establish Document Control

ISMS documents require lifecycle management.

Use:

Draft
   ↓
Review
   ↓
Approve
   ↓
Publish
   ↓
Communicate
   ↓
Review
   ↓
Update
   ↓
Retire

Part 55 — Document Metadata

Maintain:

Document ID

Title

Owner

Approver

Version

Effective Date

Review Date

Classification

Status

Part 56 — Establish Competence

People operating controls need appropriate:

Knowledge

Skills

Training

Experience

Identify roles that require specialized competence.

Part 57 — Security Awareness

The ISMS should establish awareness of:

Security Policy

Employee Responsibilities

Threats

Incident Reporting

Acceptable Use

Data Handling

Part 58 — Role-Based Training

General awareness is not enough.

Examples:

Developers
→ Secure Coding

Administrators
→ Privileged Access

SOC
→ Incident Detection

GRC
→ Risk & Compliance

Executives
→ Cyber Risk Governance

Part 59 — Establish Communication

Define:

What Is Communicated?

To Whom?

When?

By Whom?

How?

Examples:

Security Policies

Risk Decisions

Incidents

Audit Results

Metrics

Management Review Outcomes

Part 60 — Establish Operational Planning

Security controls must operate consistently.

For each critical process document:

Trigger

Input

Activity

Owner

Frequency

Evidence

Escalation

Output

Part 61 — Example Operational Process

Critical Vulnerability
Detected
      ↓
Ticket Created
      ↓
Owner Assigned
      ↓
SLA Applied
      ↓
Remediation
      ↓
Validation
      ↓
Closure Evidence

Part 62 — Establish Change Management

Changes can create new risks.

Integrate security into:

Technology Changes

Cloud Changes

Application Releases

Infrastructure Changes

Vendor Changes

Business Changes

Part 63 — Risk-Based Change Review

High-risk changes may require:

Security Review

Threat Modeling

Architecture Review

Testing

Approval

Part 64 — Establish Supplier Security

The ISMS should govern:

Vendor Selection

Due Diligence

Contract Requirements

Security Assessment

Monitoring

Offboarding

Part 65 — Supplier Lifecycle

Need
 ↓
Due Diligence
 ↓
Risk Assessment
 ↓
Contract
 ↓
Onboarding
 ↓
Monitoring
 ↓
Reassessment
 ↓
Offboarding

Part 66 — Establish Incident Management

Connect:

Detection
   ↓
Triage
   ↓
Containment
   ↓
Investigation
   ↓
Recovery
   ↓
Lessons Learned
   ↓
ISMS Improvement

Part 67 — Incidents Feed Risk Management

An incident may reveal:

New Risk

Control Failure

Incorrect Likelihood

Incorrect Impact

Missing Control

Therefore:

Incident
   ↓
Risk Reassessment

Part 68 — Establish Business Continuity Integration

Security must support:

Availability

Resilience

Recovery

Connect:

BIA
 ↓
Critical Services
 ↓
RTO / RPO
 ↓
Recovery Strategy
 ↓
Testing
 ↓
Improvement

Part 69 — Establish Performance Monitoring

Management must know:

Is the ISMS
Working?

This requires:

Metrics

KPIs

KRIs

Control Testing

Audits

Management Reviews

Part 70 — Define ISMS Metrics

Examples:

MFA Coverage

Patch SLA Compliance

Security Training Completion

Vendor Assessment Coverage

Incident Response Time

Recovery Test Success

Control Failure Rate

Audit Finding Closure

Part 71 — Create Metrics Register

Metric	Target	Frequency	Owner
Privileged MFA	100%	Monthly	IAM
Critical Patch SLA	≥95%	Monthly	IT
Training Completion	100%	Quarterly	HR
Critical Vendor Reviews	100%	Quarterly	TPRM
High Findings Closed	≥95%	Monthly	GRC

Part 72 — Distinguish KPI and KRI

KPI:

Are We
Performing?

KRI:

Is Risk
Increasing?

Example KPI:

95% Critical
Patches Completed
Within SLA

Example KRI:

12 Critical
Vulnerabilities
Currently Overdue

Part 73 — Establish Control Testing

Controls should periodically be evaluated for:

Design Effectiveness

Implementation

Operating Effectiveness

Part 74 — Design Effectiveness

Ask:

Would This Control,
If Operating Correctly,
Reduce the Intended Risk?

Part 75 — Operating Effectiveness

Ask:

Did the Control
Actually Operate
as Designed?

Part 76 — Example

Control:

Quarterly
Access Review

Design:

Appropriate

Evidence:

Q1 Completed

Q2 Missing

Q3 Completed

Operating effectiveness:

Partially Effective

Part 77 — Establish Internal Audit

Internal audit provides independent assurance.

Audit should evaluate whether the ISMS:

Meets Requirements

Operates as Designed

Is Effectively Maintained

Part 78 — Internal Audit Program

Create:

Audit Scope

Audit Criteria

Audit Frequency

Auditor

Audit Method

Evidence

Findings

Corrective Actions

Part 79 — Auditor Independence

Avoid:

Control Owner
Audits
Own Control

Ensure appropriate independence.

Part 80 — Audit Schedule

Example:

Q1
Governance & Risk

Q2
IAM & HR Security

Q3
Cloud & Operations

Q4
Incident Response,
BCM & Supplier Security

Part 81 — Classify Findings

Possible categories:

Major Nonconformity

Minor Nonconformity

Observation

Opportunity for Improvement

Use the organization’s defined audit methodology.

Part 82 — Establish Corrective Action

Finding:

Access Reviews
Not Performed
Quarterly

Do not simply:

Complete
Access Review

Determine:

Why Did
the Process Fail?

Part 83 — Root Cause Analysis

Example:

Finding
   ↓
Access Review Missed
   ↓
Why?
No Reminder
   ↓
Why?
No Central Schedule
   ↓
Why?
Control Governance
Not Established

Part 84 — Correct Root Cause

Better corrective action:

Establish Central
Control Calendar

Assign Owner

Automate Reminder

Track Completion

Escalate Overdue Reviews

Part 85 — Corrective Action Register

Create:

Finding	Root Cause	Action	Owner	Due	Status
Access Review Missed	Governance gap	Control calendar	IAM	TBD	Open
Vendor Review Missing	Ownership gap	Assign TPRM owner	GRC	TBD	Open

Part 86 — Verify Corrective Action

Do not close because:

Action
Completed

Verify:

Was the
Root Cause Removed?

Part 87 — Establish Management Review

Senior management periodically reviews the ISMS.

This is not merely:

Security Team
Status Meeting

It is management-level evaluation of the ISMS.

Part 88 — Management Review Inputs

Include:

Previous Actions

Business Changes

Risk Changes

Security Objectives

Metrics

Audit Results

Incidents

Nonconformities

Corrective Actions

Resource Needs

Improvement Opportunities

Part 89 — Management Review Outputs

Management may decide:

Approve Investment

Change Risk Treatment

Change Security Objectives

Accept Risk

Allocate Resources

Modify Scope

Improve Controls

Part 90 — Management Review Agenda

Example:

01 Business Changes

02 Threat & Risk Changes

03 Security Objectives

04 KPI / KRI Performance

05 Incidents

06 Audit Results

07 Control Failures

08 Corrective Actions

09 Resource Requirements

10 Decisions Required

Part 91 — Document Management Review

Maintain:

Date

Participants

Inputs

Discussion

Decisions

Actions

Owners

Due Dates

Part 92 — Establish Continual Improvement

The ISMS should continuously evolve.

Sources of improvement include:

Audits

Incidents

Risk Assessments

Metrics

Control Testing

Threat Intelligence

Employee Feedback

Management Review

Regulatory Changes

Part 93 — Improvement Cycle

Identify
   ↓
Prioritize
   ↓
Approve
   ↓
Implement
   ↓
Measure
   ↓
Validate
   ↓
Standardize

Part 94 — Create Improvement Register

Example:

Improvement	Source	Priority	Owner	Status
Automate evidence	Audit	High	GRC	Planned
Improve MFA	Risk	Critical	IAM	Active
Improve recovery	Test	High	BCM	Active

Part 95 — Apply PDCA

A useful management-system model is:

PLAN
 ↓
DO
 ↓
CHECK
 ↓
ACT

Part 96 — PLAN

Define:

Context

Scope

Risks

Objectives

Controls

Responsibilities

Part 97 — DO

Operate:

Policies

Processes

Controls

Training

Risk Treatments

Part 98 — CHECK

Evaluate:

Metrics

Testing

Audits

Incidents

Management Review

Part 99 — ACT

Improve:

Corrective Actions

Control Improvements

Policy Updates

Risk Treatments

Governance Changes

Part 100 — ISMS Lifecycle

Your complete system now becomes:

Organizational Context
          ↓
Interested Parties
          ↓
ISMS Scope
          ↓
Leadership
          ↓
Risk Assessment
          ↓
Risk Treatment
          ↓
Security Objectives
          ↓
Policies
          ↓
Controls
          ↓
Operations
          ↓
Evidence
          ↓
Measurement
          ↓
Internal Audit
          ↓
Management Review
          ↓
Corrective Action
          ↓
Continual Improvement
          ↺

Part 101 — Build ISMS Governance Calendar

Example:

Activity	Frequency
Risk Review	Quarterly
KPI/KRI Review	Monthly
Control Review	Quarterly
Policy Review	Annual
Internal Audit	Annual / Risk-Based
Management Review	At Planned Intervals
Vendor Review	Risk-Based
Access Review	Quarterly
Recovery Testing	Annual / Risk-Based

Actual frequencies should reflect organizational requirements.

Part 102 — Create ISMS Dashboard

Management should see:

ISMS HEALTH

Risks Above Appetite

Security Objectives

Control Effectiveness

Policy Status

Audit Findings

Corrective Actions

Incidents

Supplier Risk

Evidence Readiness

Improvement Actions

Part 103 — Example Executive Dashboard

ISMS STATUS

Critical Risks             3

Risks Above Appetite       4

Security Objectives
On Track                   8/10

Effective Controls         92%

Open Audit Findings        7

Overdue Actions            2

Policies Current           96%

Critical Vendors
Assessed                   94%

Values are illustrative.

Part 104 — Define ISMS Health

Avoid a single:

ISMS Score
87%

without context.

Management should understand:

Where Are
the Problems?

What Risks
Do They Create?

What Decision
Is Required?

Part 105 — Connect ISMS to Enterprise GRC

Your ISMS should not operate independently.

Connect:

Enterprise Risk

Compliance

Privacy

Third-Party Risk

Business Continuity

Internal Audit

Security Operations

Executive Governance

Part 106 — Connect ISMS to Compliance Frameworks

Your architecture can become:

Business Requirements
        ↓
Enterprise Risks
        ↓
ISMS
        ↓
Common Controls
        ↓
ISO 27001
SOC 2
NIST CSF
CSA CCM
PCI DSS
Other Requirements

This avoids rebuilding the security program for every framework.

Part 107 — Connect ISMS to Common Control Framework

Example:

Risk:
Privileged Access
      ↓
Internal Control:
IAM-001
      ↓
ISO Mapping
      ↓
SOC 2 Mapping
      ↓
NIST Mapping
      ↓
Customer Requirement

One control can support:

Multiple
Assurance Requirements

Part 108 — Build Evidence Once

A mature approach:

Control
      ↓
Evidence
      ↓
Common Evidence Repository
      ↓
Multiple Frameworks

instead of:

ISO Evidence

SOC Evidence

Customer Evidence

NIST Evidence

being separately recreated.

Part 109 — Establish Evidence Repository

Suggested structure:

ISMS Evidence
│
├── Governance
├── Risk
├── IAM
├── Asset Management
├── Vulnerability Management
├── Logging
├── Incident Response
├── Supplier Security
├── Secure Development
├── Business Continuity
├── HR Security
└── Internal Audit

Part 110 — Evidence Naming Convention

Example:

IAM-001_
Privileged-MFA_
2026-08

This supports:

Traceability

Searchability

Audit Readiness

Part 111 — Build ISMS Document Repository

Suggested:

ISMS
│
├── 01 Context
├── 02 Scope
├── 03 Governance
├── 04 Risk Management
├── 05 Policies
├── 06 Controls
├── 07 Statement of Applicability
├── 08 Objectives
├── 09 Metrics
├── 10 Evidence
├── 11 Internal Audit
├── 12 Management Review
├── 13 Corrective Actions
└── 14 Continual Improvement

Part 112 — Prepare for Audit Readiness

Before an external assessment, verify:

Scope Defined?

Risk Assessment Current?

Treatment Plan Current?

SoA Current?

Policies Approved?

Controls Operating?

Evidence Available?

Objectives Measured?

Internal Audit Completed?

Management Review Completed?

Corrective Actions Managed?

Part 113 — Do Not Build an ISMS Only for Certification

Weak:

Build Documents
      ↓
Pass Audit
      ↓
Ignore Until
Next Year

Better:

Build ISMS
      ↓
Manage Risk
      ↓
Improve Security
      ↓
Generate Evidence
      ↓
Certification Becomes
an Assurance Outcome

Part 114 — Common Mistake: ISMS = ISO 27001

ISO/IEC 27001 provides requirements for an ISMS.

But the business objective should be:

Manage Information
Security Effectively

not simply:

Get ISO
Certificate

Part 115 — Common Mistake: GRC Owns Every Control

GRC may coordinate the ISMS.

But controls belong across:

IAM

Security

Engineering

HR

Legal

Procurement

BCM

IT

Business

Part 116 — Common Mistake: Policies Without Operations

Policy:

Privileged Access
Must Be Reviewed
Quarterly

requires:

Procedure

Owner

Schedule

Evidence

Escalation

Otherwise it is only a statement.

Part 117 — Common Mistake: Controls Without Risk

Every important control should answer:

What Risk
Does This
Control Reduce?

Part 118 — Common Mistake: Evidence Created for Auditors

Evidence should be generated by:

Normal Control
Operation

not manufactured shortly before an audit.

Part 119 — Common Mistake: No Measurement

Without metrics:

"We Think
Controls Work."

With measurement:

"We Can Demonstrate
Whether Controls Work."

Part 120 — Common Mistake: No Leadership Involvement

Without management participation, the ISMS becomes:

Security Department
Documentation Project

rather than:

Enterprise
Management System

Part 121 — Common Mistake: No Continual Improvement

The ISMS must change when:

Business Changes

Technology Changes

Threats Change

Regulations Change

Controls Fail

Incidents Occur

Part 122 — ISMS Maturity Model

Level 1 — Ad Hoc

Security Activities
Exist Independently

Level 2 — Defined

Policies and
Responsibilities Defined

Level 3 — Managed

Risk and Controls
Managed Consistently

Level 4 — Measured

Metrics and
Assurance Established

Level 5 — Optimized

Automation

Continuous Monitoring

Integrated GRC

Continual Improvement

Part 123 — Future-State CloudNova ISMS

CloudNova should move from:

Security Team
      +
IT Team
      +
Engineering
      +
GRC
      +
Audit

working independently,

to:

Enterprise ISMS
        ↓
Shared Governance
        ↓
Shared Risk Model
        ↓
Common Controls
        ↓
Defined Ownership
        ↓
Common Evidence
        ↓
Integrated Assurance

Practical Assignment

Build the following for CloudNova.

Task 1 — Context Assessment

Document:

Business Model

Customers

Markets

Technology

Internal Issues

External Issues

Security Drivers

Task 2 — Interested Parties

Identify at least:

8 Interested Parties

and their security requirements.

Task 3 — ISMS Scope

Create a formal scope statement covering:

Organization

Technology

Processes

Information

Locations

Dependencies

Task 4 — Governance Model

Create:

Executive Governance

ISMS Steering Committee

ISMS Manager

Control Owners

Risk Owners

Task 5 — Security Policy

Draft a one-page:

Information
Security Policy

Task 6 — Risk Methodology

Reuse your enterprise risk assessment and define:

Likelihood

Impact

Risk Levels

Risk Appetite

Risk Acceptance

Task 7 — Security Objectives

Create at least:

10 Measurable
Security Objectives

Task 8 — Control Register

Create at least:

20 Enterprise
Security Controls

across:

IAM

Cloud

Vulnerability

Logging

Incident Response

Supplier Risk

Secure Development

BCM

Task 9 — Statement of Applicability

Create an SoA containing:

Control

Applicability

Justification

Implementation

Owner

Internal Mapping

Task 10 — Evidence Register

Identify evidence for each selected control.

Task 11 — Metrics

Create:

10 KPIs

10 KRIs

Task 12 — Internal Audit

Develop a:

12-Month
Audit Program

Task 13 — Management Review

Create a management review agenda and decision log.

Task 14 — Improvement Register

Create at least:

10 Improvement
Opportunities

Final ISMS Validation Checklist

Context

internal issues documented.
external issues documented.
interested parties identified.
requirements documented.
business context understood.

Scope

organizational boundaries defined.
physical boundaries defined.
technology boundaries defined.
information included.
dependencies identified.
exclusions justified.

Leadership

executive sponsor identified.
ISMS owner assigned.
governance forums established.
responsibilities defined.
leadership review established.

Risk

risk methodology documented.
risk criteria established.
risk assessment current.
risk owners assigned.
treatment plans documented.
residual risk evaluated.
acceptance authority established.

Objectives

measurable objectives established.
owners assigned.
targets established.
measurement defined.
progress monitored.

Policies

information security policy established.
supporting policies identified.
owners assigned.
approvals recorded.
review dates established.

Controls

controls selected based on risk.
control owners assigned.
control objectives defined.
evidence identified.
control frequencies established.

Statement of Applicability

applicability determined.
exclusions justified.
implementation status recorded.
control mappings maintained.
SoA reviewed.

Evidence

evidence requirements identified.
evidence owners assigned.
evidence repository established.
retention requirements defined.
evidence traceability maintained.

Performance

KPIs established.
KRIs established.
thresholds defined.
performance reported.
control effectiveness monitored.

Internal Audit

audit program established.
audit scope defined.
independence considered.
findings documented.
corrective actions tracked.

Management Review

reviews scheduled.
required inputs available.
leadership participates.
decisions documented.
actions tracked.

Improvement

nonconformities tracked.
root causes investigated.
corrective actions implemented.
effectiveness verified.
improvements tracked.

Expected Project Folder

02 Build an ISMS
│
├── 01 ISMS Context Assessment
├── 02 Interested Parties Register
├── 03 ISMS Scope Statement
├── 04 ISMS Governance Structure
├── 05 Roles & Responsibilities
├── 06 Information Security Policy
├── 07 Risk Management Methodology
├── 08 Risk Treatment Process
├── 09 Information Security Objectives
├── 10 Policy Framework
├── 11 Control Register
├── 12 Statement of Applicability
├── 13 Evidence Register
├── 14 ISMS Metrics Register
├── 15 Internal Audit Program
├── 16 Management Review
├── 17 Corrective Action Register
├── 18 Continual Improvement Register
├── 19 ISMS Governance Calendar
└── 20 ISMS Executive Summary

Success Criteria

You successfully complete this project when you can demonstrate:

Business Context
        ↓
ISMS Scope
        ↓
Risk Assessment
        ↓
Risk Treatment
        ↓
Policies
        ↓
Controls
        ↓
Control Ownership
        ↓
Evidence
        ↓
Metrics
        ↓
Internal Audit
        ↓
Management Review
        ↓
Corrective Action
        ↓
Continual Improvement

and answer:

What Is
Inside Our ISMS?

What Are
We Protecting?

What Risks
Are We Managing?

Which Controls
Address Those Risks?

Why Did
We Select Them?

Who Owns
Each Control?

How Do We
Know Controls Work?

What Evidence
Proves It?

What Are
Our Security Objectives?

Are We
Meeting Them?

What Has
Internal Audit Found?

What Does
Leadership Need
to Decide?

What Are
We Improving?

Career Connection

This project reflects work performed by:

ISMS Analysts

GRC Analysts

ISO 27001 Consultants

Information Security Managers

Security Governance Leads

Compliance Managers

Cyber Risk Managers

GRC Architects

A beginner may think an ISMS is:

Policies
+
ISO Controls
+
Audit Evidence

A professional understands it as:

Business
      ↓
Risk
      ↓
Governance
      ↓
Controls
      ↓
Operations
      ↓
Assurance
      ↓
Management Decisions
      ↓
Continual Improvement

That is the foundation of a sustainable enterprise information security program.

What’s Next?

➡️ Next: 03 — Conduct an ISO 27001 Gap Assessment

You have now designed:

Organizational Context
        ↓
ISMS Scope
        ↓
Governance
        ↓
Risk Management
        ↓
Security Objectives
        ↓
Policies
        ↓
Controls
        ↓
Statement of Applicability
        ↓
Evidence
        ↓
Metrics
        ↓
Audit
        ↓
Management Review
        ↓
Continual Improvement

The next question is:

How Do We Know
Whether This ISMS
Actually Meets
ISO 27001
Requirements?

In the next project, you will perform a structured:

ISO 27001
Gap Assessment

You will move through:

ISO Requirements
      ↓
Current State
      ↓
Evidence Review
      ↓
Control Assessment
      ↓
Gap Identification
      ↓
Risk Prioritization
      ↓
Remediation Planning
      ↓
Readiness Reporting

The goal is to move from:

"We Have
an ISMS"

to:

"We Can Demonstrate
Where We Meet
ISO 27001,
Where We Do Not,
and What Must
Be Remediated."

➡️ Next: 03 — Conduct an ISO 27001 Gap Assessment