Lab 01 — Build an ISO/IEC 27001 ISMS

Mission Information

Field	Details
Lab Type	GRC / ISO/IEC 27001 Implementation
Difficulty	Intermediate
Estimated Time	3–4 Hours
Primary Role	GRC Analyst / ISO 27001 Analyst
Environment	Simulated Enterprise
Primary Framework	ISO/IEC 27001:2022
Deliverable	Enterprise ISMS Package

Mission

You have joined CloudNova Technologies, a fictional SaaS organization that provides a cloud-hosted business platform to enterprise customers.

The company is growing rapidly and customers are increasingly asking:

Are you ISO/IEC 27001 certified?

CloudNova currently has security technologies and individual policies, but it does not have a formally structured Information Security Management System.

Senior management has approved an initiative to prepare the organization for ISO/IEC 27001 certification.

You have been assigned to the GRC team.

Your mission is to build the organization’s initial ISO/IEC 27001 ISMS package.

You will move through the same lifecycle used in a real implementation:

Understand Organization
        ↓
Define ISMS Scope
        ↓
Identify Interested Parties
        ↓
Establish Governance
        ↓
Create Risk Methodology
        ↓
Identify & Assess Risks
        ↓
Develop Risk Treatment Plan
        ↓
Build Statement of Applicability
        ↓
Assign Control Ownership
        ↓
Establish Policies
        ↓
Collect Evidence
        ↓
Prepare Internal Audit
        ↓
Management Review
        ↓
Certification Readiness

By the end of the lab, you will have created a practical collection of interconnected GRC artifacts rather than a collection of unrelated documents.

1. Learning Objectives

By completing this lab, you will be able to:

• Define organizational context for an ISMS.

• Identify relevant interested parties.

• Define an ISO/IEC 27001 ISMS scope.

• Establish basic ISMS governance.

• Create an information security risk methodology.

• Build an enterprise risk register.

• Evaluate inherent and residual risk.

• Determine risk-treatment decisions.

• Develop a Risk Treatment Plan.

• Build a Statement of Applicability.

• Map risks to security controls.

• Assign control ownership.

• Establish a security policy hierarchy.

• Build an ISMS evidence register.

• Prepare an internal audit plan.

• Prepare management-review information.

• Evaluate certification readiness.

• Present ISMS status to senior management.

2. Scenario

CloudNova Technologies has approximately:

Employees: 500

Locations:
India
United Kingdom
United States

Customers:
Enterprise SaaS Customers

Primary Platform:
CloudNova SaaS Platform

Cloud Provider:
AWS

Development:
GitHub-based development environment

Identity:
Centralized cloud identity provider

Endpoint Environment:
Corporate laptops

Security Operations:
Internal security team

Third Parties:
Cloud providers
Payment providers
Software vendors
Contractors
Support providers

The company’s core business service is:

Providing a secure and highly available cloud-based SaaS platform to enterprise customers.

3. Current Security Situation

CloudNova already has several security capabilities.

These include:

• MFA.

• Endpoint protection.

• Cloud logging.

• Vulnerability scanning.

• Backups.

• Security awareness training.

• Incident response.

• Vendor assessments.

• Access reviews.

However, the organization has several governance problems.

Security controls exist
        ↓
Ownership unclear

Policies exist
        ↓
Review dates inconsistent

Risks exist
        ↓
No central risk register

Controls operate
        ↓
Evidence scattered

Vendor reviews occur
        ↓
No consistent methodology

Management receives reports
        ↓
No formal ISMS management review

Your task is to convert this fragmented security environment into a structured ISMS.

4. Lab Deliverables

Create the following artifacts:

ISO27001-ISMS/
│
├── 01-ISMS-Scope.md
├── 02-Context-Register.md
├── 03-Interested-Parties-Register.md
├── 04-ISMS-Governance-RACI.md
├── 05-Risk-Assessment-Methodology.md
├── 06-Information-Security-Risk-Register.md
├── 07-Risk-Treatment-Plan.md
├── 08-Statement-of-Applicability.md
├── 09-Control-Ownership-Matrix.md
├── 10-Policy-Register.md
├── 11-Evidence-Register.md
├── 12-Internal-Audit-Plan.md
├── 13-Management-Review-Pack.md
└── 14-Certification-Readiness-Assessment.md

These documents together form your initial ISMS implementation package.

5. Architecture You Are Protecting

Assume the following simplified architecture:

                    Internet
                       │
                       ▼
                  CloudFront
                       │
                       ▼
                Application Load
                    Balancer
                       │
                       ▼
                SaaS Application
                       │
              ┌────────┴────────┐
              ▼                 ▼
          Database          Object Storage
              │                 │
              └────────┬────────┘
                       │
                       ▼
                Backup Services


Employees
    │
    ▼
Identity Provider
    │
    ├──── SaaS Applications
    │
    ├──── AWS
    │
    ├──── GitHub
    │
    └──── Corporate Systems


Security Telemetry
        │
        ▼
Central Logging / SIEM
        │
        ▼
Security Operations

You will use this environment throughout the lab.

Part 1 — Define Organizational Context

6. Step 1 — Identify Internal Issues

Create:

02-Context-Register.md

Start by identifying internal issues that could affect the ISMS.

Example:

ID	Internal Issue	ISMS Impact
INT-01	Rapid business growth	New assets and users introduced rapidly
INT-02	Distributed workforce	Increased identity and endpoint risk
INT-03	Cloud-native infrastructure	Strong cloud governance required
INT-04	Multiple engineering teams	Secure SDLC consistency required
INT-05	Heavy SaaS usage	Third-party dependencies increase

Add at least five internal issues.

7. Step 2 — Identify External Issues

Add external factors.

Example:

ID	External Issue	ISMS Impact
EXT-01	Enterprise customer requirements	Security assurance required
EXT-02	Cyber threat landscape	Continuous security monitoring required
EXT-03	Privacy obligations	Data protection controls required
EXT-04	Supply-chain attacks	Vendor risk management required
EXT-05	Cloud dependency	Cloud resilience required

Add at least five external issues.

8. Expected Result

Your Context Register should demonstrate that the ISMS is based on the organization’s actual business environment.

You should be able to explain:

Business Environment
        ↓
Security Context
        ↓
ISMS Requirements

Part 2 — Identify Interested Parties

9. Step 3 — Build Interested Parties Register

Create:

03-Interested-Parties-Register.md

Identify stakeholders relevant to information security.

Example:

Party	Requirement / Expectation	ISMS Relevance
Customers	Protection of customer data	High
Employees	Secure access to systems	High
Management	Risk visibility	High
Regulators	Compliance	High
Cloud Provider	Shared responsibility	High
Vendors	Security obligations	Medium
Auditors	Evidence of conformity	High

Add at least eight interested parties.

10. Think Like a GRC Analyst

Do not simply ask:

Who interacts with the company?

Ask:

Which parties have requirements or expectations relevant to information security and the ISMS?

Part 3 — Define the ISMS Scope

11. Step 4 — Identify Critical Services

The primary service is:

CloudNova SaaS Platform

Identify supporting components:

AWS Infrastructure

Application Services

Databases

Identity Systems

Corporate Endpoints

Development Environment

Security Monitoring

Backup Services

12. Step 5 — Define Organizational Boundaries

Determine which teams support the service.

Example:

Engineering

Cloud Operations

Security

GRC

IT

Customer Support

HR

Procurement

13. Step 6 — Define Physical Boundaries

Consider:

Corporate Offices

Remote Workforce

Cloud Infrastructure

Third-Party Data Centers

Remember that cloud infrastructure creates dependencies even when the organization does not physically own the data center.

14. Step 7 — Write the ISMS Scope Statement

Create:

01-ISMS-Scope.md

Example:

The Information Security Management System applies to the design, development, operation, maintenance, and support of the CloudNova SaaS Platform and its supporting cloud infrastructure, identity services, security operations, corporate IT systems, personnel, and third-party services involved in delivering the platform to customers.

Document:

Included Services

Included Locations

Included Teams

Included Technologies

Interfaces

Dependencies

Justified Exclusions

15. Scope Validation

Verify:

• Critical service included.

• Supporting infrastructure included.

• Relevant employees included.

• Security operations included.

• Important suppliers considered.

• Interfaces identified.

• Dependencies identified.

• Exclusions justified.

Part 4 — Establish ISMS Governance

16. Step 8 — Identify ISMS Roles

Create:

04-ISMS-Governance-RACI.md

Use these roles:

Executive Management

CISO

ISMS Manager

GRC Team

Risk Owners

Control Owners

Security Engineering

IT

HR

Procurement

Internal Audit

17. Step 9 — Build the RACI

Example:

Activity	Management	CISO	GRC	Control Owner	Internal Audit
ISMS Scope	A	R	R	C	I
Risk Assessment	I	A	R	C	I
Risk Treatment	I	A	R	R	I
Control Operation	I	A	C	R	I
Internal Audit	I	I	C	C	R
Management Review	A	R	C	I	I

Legend:

R = Responsible
A = Accountable
C = Consulted
I = Informed

Expand this matrix for your ISMS.

Part 5 — Build the Risk Assessment Methodology

18. Step 10 — Define Risk Model

Create:

05-Risk-Assessment-Methodology.md

Use:

Risk = Likelihood × Impact

Both values will use a 1–5 scale.

19. Likelihood Scale

Score	Rating	Description
1	Rare	Highly unlikely
2	Unlikely	Could occur
3	Possible	May occur
4	Likely	Expected
5	Almost Certain	Frequently expected

20. Impact Scale

Score	Rating	Description
1	Insignificant	Minimal impact
2	Minor	Limited impact
3	Moderate	Noticeable business impact
4	Major	Significant operational/customer impact
5	Severe	Critical business impact

21. Risk Rating

Calculate:

Risk Score = Likelihood × Impact

Use:

Score	Rating
1–4	Low
5–9	Medium
10–16	High
17–25	Critical

22. Risk Treatment Options

Define:

Mitigate

Avoid

Transfer

Accept

Risk acceptance should require appropriate authorization.

Part 6 — Build the Information Security Risk Register

23. Step 11 — Identify Assets

Create:

06-Information-Security-Risk-Register.md

Start with assets.

Examples:

Customer Data

AWS Environment

Production Database

Source Code

Identity Platform

Employee Endpoints

Security Logs

Backup Data

Vendor Services

24. Step 12 — Identify Threats

Examples:

Credential Theft

Malware

Ransomware

Insider Threat

Cloud Misconfiguration

Software Vulnerability

Supply-Chain Attack

Data Leakage

Service Outage

25. Step 13 — Identify Vulnerabilities

Examples:

Weak Authentication

Excessive Privileges

Missing Patches

Misconfiguration

Poor Monitoring

Weak Vendor Controls

Inadequate Backup Testing

26. Step 14 — Write Risk Statements

Use:

Because of [vulnerability], [threat] could affect [asset], resulting in [business impact].

Example:

Because privileged cloud accounts are not consistently reviewed, compromised or inappropriate privileged access could result in unauthorized changes to production infrastructure and customer data exposure.

27. Step 15 — Create Risk Register

Use:

ID	Asset	Threat	Vulnerability	Risk	L	I	Score	Rating	Owner
R-001	AWS	Credential theft	Weak privileged governance	Unauthorized cloud access	4	5	20	Critical	CISO
R-002	Customer DB	Data breach	Excessive access	Customer data exposure	3	5	15	High	CTO
R-003	Endpoints	Ransomware	Unpatched software	Endpoint compromise	3	4	12	High	IT
R-004	Vendors	Supply-chain attack	Weak assessment	Third-party compromise	3	5	15	High	Procurement
R-005	Backups	Service outage	Untested recovery	Extended downtime	3	5	15	High	IT

Create at least 10 risks.

Part 7 — Develop the Risk Treatment Plan

28. Step 16 — Select Treatment

Create:

07-Risk-Treatment-Plan.md

For each High or Critical risk, determine the treatment.

Example:

Risk	Treatment	Planned Action
R-001	Mitigate	MFA + privileged access review
R-002	Mitigate	RBAC + access review
R-003	Mitigate	Patch management + EDR
R-004	Mitigate	Vendor security assessment
R-005	Mitigate	Recovery testing

29. Step 17 — Assign Treatment Owner

Add:

Treatment Owner

Target Date

Status

Example:

Risk	Owner	Target	Status
R-001	IAM Lead	30 Sep	In Progress

30. Step 18 — Calculate Residual Risk

After controls:

Inherent Risk
      ↓
Security Controls
      ↓
Residual Risk

Example:

Inherent:

Likelihood = 4
Impact = 5

Score = 20 Critical


After Treatment:

Likelihood = 2
Impact = 5

Residual Score = 10 High

Residual risk must be evaluated and, where appropriate, formally accepted.

Part 8 — Build the Statement of Applicability

31. Step 19 — Create the SoA

Create:

08-Statement-of-Applicability.md

Your SoA should contain:

Control	Applicable?	Justification	Implementation	Owner	Evidence

32. Example Entries

Control Area	Applicable	Justification	Status
Access Control	Yes	Protect production systems	Implemented
Security Awareness	Yes	Employees handle information	Implemented
Supplier Security	Yes	Critical vendors used	Partial
Logging	Yes	Security monitoring required	Implemented
Secure Development	Yes	SaaS software developed internally	Implemented

Use the applicable ISO/IEC 27001:2022 Annex A control set when building the complete SoA.

33. SoA Decision Logic

For each control:

Risk / Requirement
        ↓
Is Control Relevant?
        ↓
Yes / No
        ↓
Document Justification
        ↓
Document Implementation Status

Do not mark a control:

Not Applicable

simply because implementation is difficult.

Part 9 — Map Risks to Controls

34. Step 20 — Create Risk-to-Control Traceability

Add control mappings to the Risk Treatment Plan.

Example:

R-001
Unauthorized Cloud Access
      ↓
Identity Controls
      ↓
MFA
      ↓
Privileged Access Management
      ↓
Access Review

Your goal is to establish:

Risk
      ↓
Treatment
      ↓
Control
      ↓
Owner
      ↓
Evidence

35. Why This Matters

When an auditor asks:

Why did you implement this control?

you should be able to trace it back to:

Risk

Requirement

Contractual Obligation

Legal Obligation

Business Need

Part 10 — Build the Control Ownership Matrix

36. Step 21 — Assign Control Owners

Create:

09-Control-Ownership-Matrix.md

Example:

Control Area	Owner	Operator	Evidence Owner
IAM	IAM Manager	IAM Team	IAM Manager
Vulnerability Management	Security Manager	Security Engineering	Security Manager
Incident Response	SOC Manager	SOC	SOC Manager
Supplier Security	GRC Manager	GRC	GRC Manager
Backup	IT Manager	IT Operations	IT Manager

37. Control Accountability

Every important control should answer:

Who Owns It?

Who Operates It?

Who Reviews It?

Who Provides Evidence?

Avoid:

Owner:
Security Team

when a specific accountable role can be identified.

Part 11 — Establish the Policy Framework

38. Step 22 — Build Policy Register

Create:

10-Policy-Register.md

Include:

Policy	Owner	Approver	Review Frequency	Status
Information Security Policy	CISO	CEO	Annual	Approved
Access Control Policy	IAM Manager	CISO	Annual	Approved
Incident Response Policy	SOC Manager	CISO	Annual	Approved
Vendor Security Policy	GRC	CISO	Annual	Draft
Backup Policy	IT Manager	CTO	Annual	Approved

39. Suggested Policy Hierarchy

Information Security Policy
        ↓
Topic-Specific Policies
        ↓
Standards
        ↓
Procedures
        ↓
Technical Configurations

Example:

Access Control Policy
        ↓
IAM Standard
        ↓
User Provisioning Procedure
        ↓
Identity Platform Configuration

Part 12 — Build the Evidence Register

40. Step 23 — Identify Control Evidence

Create:

11-Evidence-Register.md

Example:

Evidence ID	Control	Evidence	Owner	Frequency	Location
E-001	Access Review	Quarterly Review	IAM	Quarterly	GRC Repository
E-002	Awareness	Training Report	HR	Annual	LMS
E-003	Vulnerability	Scan Report	Security	Monthly	Scanner
E-004	Backup	Recovery Test	IT	Quarterly	IT Repository
E-005	Vendor Risk	Vendor Assessment	GRC	Annual	GRC Repository

41. Evidence Mapping

Build:

Control
      ↓
Expected Evidence
      ↓
Evidence Owner
      ↓
Collection Frequency
      ↓
Repository

This prepares the organization for internal and external audits.

Part 13 — Perform a Control Evidence Review

42. Step 24 — Test Five Controls

Select:

MFA

Privileged Access Review

Vulnerability Management

Vendor Assessment

Backup Recovery

For each control, determine:

Design Appropriate?

Implemented?

Evidence Available?

Operating Consistently?

Exceptions?

43. Control Testing Worksheet

Use:

Control	Design	Evidence	Effective?	Exception
MFA	Effective	Configuration	Yes	None
Access Review	Effective	Review Reports	Partial	Q2 missing
Vulnerability Management	Effective	Scan Reports	Yes	None
Vendor Assessment	Effective	Assessments	Partial	2 vendors overdue
Backup Recovery	Effective	Recovery Tests	Yes	None

44. Identify Findings

Based on the sample above:

Finding 01:
Quarterly access review not completed in Q2.

Finding 02:
Two critical vendors have overdue reassessments.

Document these for internal audit.

Part 14 — Prepare the Internal Audit

45. Step 25 — Build Internal Audit Plan

Create:

12-Internal-Audit-Plan.md

Include:

Audit Objective

Audit Scope

Audit Criteria

Auditor

Audit Period

Processes

Controls

Interviews

Evidence

Schedule

46. Audit Objective

Example:

Determine whether the CloudNova ISMS conforms to organizational and ISO/IEC 27001 requirements and is effectively implemented and maintained.

47. Audit Scope

Include:

ISMS Governance

Risk Management

Access Control

Vulnerability Management

Supplier Security

Incident Management

Business Continuity

48. Audit Criteria

Use:

ISO/IEC 27001

Statement of Applicability

Internal Policies

Standards

Procedures

Applicable Requirements

49. Build Audit Schedule

Example:

Day	Activity
Day 1	Governance & ISMS
Day 2	Risk & Controls
Day 3	IAM & Security Operations
Day 4	Vendor & Resilience
Day 5	Findings & Closing Meeting

Part 15 — Simulate Internal Audit Findings

50. Finding 01 — Access Review

Requirement:

Quarterly privileged access review

Condition:

Q2 review not completed.

Risk:

Inappropriate privileged access may remain active.

51. Finding 02 — Vendor Reassessment

Requirement:

Critical vendors reassessed annually.

Condition:

Two vendors overdue.

Risk:

Changes in third-party security posture may remain unidentified.

52. Step 26 — Determine Root Cause

For Finding 01:

Problem:
Access review missed

Why?
No reminder

Why?
Manual calendar process

Why?
No centralized GRC workflow

Root cause:

Reliance on an informal manual control scheduling process.

53. Step 27 — Define Corrective Action

Correction:

Complete Q2 review.

Corrective action:

Implement centralized quarterly
control scheduling and escalation.

Owner:

IAM Manager

Part 16 — Prepare Management Review

54. Step 28 — Build Management Review Pack

Create:

13-Management-Review-Pack.md

Include:

ISMS Status

Risk Status

Security Objectives

Audit Results

Control Performance

Incidents

Supplier Risks

Nonconformities

Corrective Actions

Changes Affecting ISMS

Improvement Opportunities

Decisions Required

55. Executive Dashboard

Create:

Metric	Status
Critical Risks	1
High Risks	4
Controls Implemented	85%
Internal Audit Findings	2
Overdue Vendor Reviews	2
Open Corrective Actions	2

56. Management Decisions

Request decisions such as:

Approve Risk Treatment Plan

Accept Residual Risks

Approve Additional IAM Resources

Approve Vendor Remediation

Approve Certification Timeline

Management review should result in decisions and actions, not merely a presentation.

Part 17 — Certification Readiness Assessment

57. Step 29 — Build Readiness Assessment

Create:

14-Certification-Readiness-Assessment.md

Use:

Area	Status	Evidence	Gap	Action
ISMS Scope	Green	Scope Document	None	None
Risk Assessment	Green	Risk Register	None	None
RTP	Green	Treatment Plan	None	None
SoA	Green	SoA	None	None
Internal Audit	Amber	Audit Report	2 findings	Remediate
Management Review	Green	Minutes	None	None
Vendor Controls	Amber	Assessments	2 overdue	Complete reviews

58. Use Readiness Ratings

Green
=
Ready

Amber
=
Improvement Required

Red
=
Not Ready

59. Certification Decision

Based on the scenario, your recommendation should be:

Certification Readiness
        ↓
CONDITIONALLY READY

Reason:

• ISMS structure established.

• Risk process established.

• SoA established.

• Controls largely implemented.

• Internal audit completed.

• Management review completed.

• Limited corrective actions remain.

Recommendation:

Complete and verify the open corrective actions before proceeding to the certification audit.

Part 18 — Build the ISMS Traceability Model

60. Step 30 — Select One Risk

Use:

R-001
Unauthorized Cloud Access

Trace it through the ISMS.

R-001
Unauthorized Cloud Access
        ↓
Risk Treatment
Mitigate
        ↓
Controls
MFA
Privileged Access Management
Access Review
        ↓
Control Owner
IAM Manager
        ↓
Evidence
MFA Configuration
Quarterly Access Review
        ↓
Internal Audit
Control Tested
        ↓
Finding
Q2 Review Missing
        ↓
Corrective Action
Centralized Control Scheduling
        ↓
Management Review
Remediation Monitored

61. Why Traceability Matters

This is one of the most important concepts in GRC.

A mature ISMS should allow you to move:

Business Requirement
        ↓
Risk
        ↓
Control
        ↓
Owner
        ↓
Evidence
        ↓
Testing
        ↓
Finding
        ↓
Remediation
        ↓
Management Oversight

This is how separate GRC documents become an actual management system.

Part 19 — Final ISMS Package

62. Verify Your Deliverables

Your final folder should contain:

ISO27001-ISMS/
│
├── 01-ISMS-Scope.md
├── 02-Context-Register.md
├── 03-Interested-Parties-Register.md
├── 04-ISMS-Governance-RACI.md
├── 05-Risk-Assessment-Methodology.md
├── 06-Information-Security-Risk-Register.md
├── 07-Risk-Treatment-Plan.md
├── 08-Statement-of-Applicability.md
├── 09-Control-Ownership-Matrix.md
├── 10-Policy-Register.md
├── 11-Evidence-Register.md
├── 12-Internal-Audit-Plan.md
├── 13-Management-Review-Pack.md
└── 14-Certification-Readiness-Assessment.md

63. Final Quality Review

Before completing the lab, verify:

Scope

• ISMS boundaries defined.

• Critical services identified.

• Interfaces documented.

• Dependencies documented.

Context

• Internal issues identified.

• External issues identified.

• Interested parties documented.

• Security requirements identified.

Governance

• ISMS owner identified.

• Roles assigned.

• RACI created.

• Leadership accountability established.

Risk

• Risk methodology documented.

• Likelihood defined.

• Impact defined.

• Acceptance criteria defined.

• At least 10 risks documented.

• Risk owners assigned.

• Residual risk evaluated.

Treatment

• Treatment decisions documented.

• Actions assigned.

• Target dates assigned.

• Controls mapped.

Statement of Applicability

• Applicability evaluated.

• Justifications documented.

• Implementation status recorded.

• Ownership established.

Controls

• Control owners assigned.

• Control operators identified.

• Evidence owners identified.

• Evidence expectations defined.

Policies

• Policy register created.

• Owners identified.

• Approvers identified.

• Review frequencies defined.

Assurance

• Internal audit planned.

• Control testing performed.

• Findings documented.

• Root causes evaluated.

• Corrective actions assigned.

Management

• Management review prepared.

• Risk status presented.

• Findings presented.

• Decisions identified.

Certification

• Readiness assessment completed.

• Gaps identified.

• Remediation actions assigned.

• Certification recommendation documented.

64. Final Management Summary

Prepare a one-page executive summary.

Use the following structure:

ISMS Status

Overall Status:
Conditionally Ready for Certification

Key Strengths

• ISMS scope established.

• Risk methodology implemented.

• Risk register established.

• Risk Treatment Plan created.

• SoA established.

• Control ownership assigned.

• Evidence model established.

• Internal audit completed.

• Management review completed.

Key Gaps

Quarterly Access Review Finding

Two Overdue Vendor Assessments

Recommendation

Complete corrective actions, verify remediation effectiveness, update certification-readiness status, and proceed to Stage 1 certification assessment when the remaining readiness issues are satisfactorily resolved.

65. Skills You Practiced

By completing this lab, you have practiced:

ISMS Scoping

Organizational Context Analysis

Stakeholder Analysis

GRC Governance

Risk Assessment

Risk Register Development

Risk Treatment

Residual Risk

Statement of Applicability

Control Mapping

Control Ownership

Policy Governance

Evidence Management

Control Testing

Internal Audit

Corrective Action

Management Review

Certification Readiness

These are practical responsibilities performed by:

• GRC Analysts.

• GRC Consultants.

• Information Security Analysts.

• ISO 27001 Consultants.

• ISMS Managers.

• Security Compliance Analysts.

• Security Assurance Analysts.

66. Portfolio Challenge

For additional practice, package your work as:

CloudNova
ISO/IEC 27001 ISMS Implementation Project

Include:

Executive Summary

ISMS Scope

Context Register

Interested Parties Register

Risk Methodology

Risk Register

Risk Treatment Plan

Statement of Applicability

Control Ownership Matrix

Policy Register

Evidence Register

Internal Audit Plan

Management Review Pack

Certification Readiness Assessment

This demonstrates that you understand how ISO/IEC 27001 artifacts connect across an enterprise ISMS.

Do not include confidential information from a real employer or customer in a public portfolio.

67. Lab Completion Criteria

You have successfully completed the mission when you can demonstrate:

Business Context
      ↓
ISMS Scope
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Controls
      ↓
Evidence
      ↓
Audit
      ↓
Management Review
      ↓
Certification Readiness

The key lesson is:

An ISMS is not a collection of documents. It is a management system connecting business requirements, risks, controls, evidence, assurance, leadership, and continuous improvement.

What’s Next?

➡️ Next: Lab 02 — Build an ISO/IEC 27001 Statement of Applicability & Control Mapping

In the next lab, you will go deeper into one of the most important ISO/IEC 27001 implementation artifacts: the Statement of Applicability (SoA).

You will take organizational risks and requirements and build traceability across:

Business Requirement
        ↓
Information Security Risk
        ↓
Risk Treatment
        ↓
Annex A Control
        ↓
Applicability Decision
        ↓
Implementation Status
        ↓
Control Owner
        ↓
Evidence
        ↓
Testing

You will create an enterprise-style Statement of Applicability, Risk-to-Control Mapping Matrix, Control Ownership Matrix, Evidence Mapping Register, and SoA Review Checklist, preparing you for real-world ISO/IEC 27001 implementation and audit work.