02 — Build an ISO/IEC 27001

Mission Information

Field	Details
Lab Type	ISO/IEC 27001 / GRC Control Mapping
Difficulty	Intermediate
Estimated Time	3–4 Hours
Primary Role	GRC Analyst / ISO 27001 Analyst
Environment	Simulated Enterprise
Primary Framework	ISO/IEC 27001:2022
Primary Deliverable	Statement of Applicability & Control Mapping Package

Mission Scenario

CloudNova Technologies has completed its initial ISO/IEC 27001 risk assessment.

The organization now has:

An approved ISMS scope.
Organizational context.
Interested-party requirements.
An information-security risk register.
A Risk Treatment Plan.
Existing security controls.
Multiple customer and contractual security requirements.

However, the control environment is fragmented.

Different teams describe similar controls differently.

For example:

IAM Team
→ Privileged MFA

Security Team
→ Strong Authentication

GRC
→ Access Control Requirement

Customer Contract
→ Multi-Factor Authentication Required

These may all relate to the same underlying control.

Management now needs a structured Statement of Applicability that explains:

Which Annex A controls are applicable?

Why are they applicable?

Which risks do they address?

Which business or contractual requirements drive them?

Who owns each control?

Is each control actually implemented?

What evidence proves operation?

Which controls are inherited or shared?

Where are the gaps?

You have been assigned to build CloudNova’s first enterprise-style SoA and control mapping package.

Mission Objectives

By completing this lab, you will learn how to:

Review ISO/IEC 27001:2022 Annex A controls.
Determine control applicability.
Document inclusion justifications.
Document exclusion justifications.
Identify inherited and shared controls.
Map risks to controls.
Map requirements to controls.
Translate Annex A concepts into enterprise control statements.
Build an enterprise control library.
Assign control ownership.
Define control frequency.
Identify expected control evidence.
Track implementation status.
Link open control gaps to treatment actions.
Reconcile the SoA with the risk register.
Reconcile the SoA with the Risk Treatment Plan.
Prepare the SoA for internal and certification audits.

Mission Architecture

You will build the following governance model:

Business Context
      ↓
Interested-Party Requirements
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Annex A Review
      ↓
Applicability Decision
      ↓
Enterprise Control
      ↓
Control Owner
      ↓
Implementation
      ↓
Evidence
      ↓
Testing
      ↓
Statement of Applicability

Lab Deliverables

Create the following artifacts:

ISO27001-Lab02-SoA/
│
├── 01-Annex-A-Control-Register.md
├── 02-Statement-of-Applicability.md
├── 03-Risk-to-Control-Mapping.md
├── 04-Requirement-to-Control-Mapping.md
├── 05-Enterprise-Control-Library.md
├── 06-Control-Ownership-Matrix.md
├── 07-Control-Evidence-Matrix.md
├── 08-Control-Gap-Register.md
├── 09-SoA-Reconciliation-Checklist.md
└── 10-SoA-Executive-Summary.md

Part 1 — Review the Input Data

Step 1 — Review the Existing Risk Register

Assume CloudNova has identified the following risks.

Risk ID	Risk	Residual Rating
RISK-001	Privileged account compromise	High
RISK-002	Public cloud data exposure	High
RISK-003	Ransomware service disruption	High
RISK-004	Critical SaaS vendor breach	High
RISK-005	Unauthorized source code access	Moderate
RISK-006	Sensitive data leakage	High
RISK-007	Inadequate logging and detection	High
RISK-008	Cloud service outage	Moderate
RISK-009	Employee phishing compromise	High
RISK-010	Insecure software deployment	High

These risks will drive your control analysis.

Step 2 — Review Requirements

CloudNova also has several relevant requirements.

Requirement ID	Requirement	Source
REQ-001	Protect confidential customer information	Customer Contract
REQ-002	MFA required for privileged access	Internal Security Standard
REQ-003	Notify customers of material incidents	Customer Contract
REQ-004	Annual critical-vendor assessment	Vendor Security Policy
REQ-005	Encrypt customer data	Internal Security Standard
REQ-006	Perform annual penetration testing	Customer Contract
REQ-007	Maintain recoverable backups	Business Continuity Requirement
REQ-008	Log privileged administrative activity	Security Monitoring Standard

Your SoA should reflect both risk and requirements.

Part 2 — Build the Annex A Control Register

Step 3 — Create the Register

Create:

01-Annex-A-Control-Register.md

Use the following columns:

Field
Annex A Reference
Control Name
Theme
Applicability
Applicability Driver
Justification
Implementation Status
Internal Control ID
Control Owner
Evidence
Gap
Treatment Reference

Step 4 — Use the Four Themes

Organize the control set into:

A.5 — Organizational Controls

A.6 — People Controls

A.7 — Physical Controls

A.8 — Technological Controls

Remember the ISO/IEC 27001:2022 distribution:

A.5 Organizational — 37

A.6 People — 8

A.7 Physical — 14

A.8 Technological — 34

Total — 93

For this lab, you will review the full structure but perform detailed mapping for a focused subset of high-value controls.

Part 3 — Define Applicability Categories

Step 5 — Create Standard Applicability Values

Use only:

Applicable

Not Applicable

Implementation status is separate.

For applicable controls, use:

Implemented

Partially Implemented

Planned

Not Implemented

Inherited

Shared

Do not mix applicability with implementation.

Step 6 — Define Applicability Drivers

Use one or more:

Risk

Legal / Regulatory

Contractual

Business Requirement

Internal Policy

Shared Responsibility

This improves traceability.

Part 4 — Perform Applicability Analysis

Step 7 — Control Example: Information Security Policies

Assess the policy-related control.

Decision:

Applicable:
Yes

Reason:

CloudNova requires formal information-security governance to support its ISMS and customer assurance obligations.

Driver:

Business Requirement
+
ISO Governance

Status:

Implemented

Evidence:

Information Security Policy

Policy Register

Approval Record

Step 8 — Control Example: Information Security Roles

Decision:

Applicable:
Yes

Reason:

Information-security responsibilities must be formally allocated across GRC, IAM, Security Operations, Engineering, IT, HR, and Procurement.

Mapped risks:

RISK-001
RISK-004
RISK-007

Evidence:

ISMS RACI

Job Responsibilities

Control Ownership Matrix

Part 5 — Map Identity Risks

Step 9 — Risk RISK-001

Risk:

Threat actors may compromise privileged credentials and obtain unauthorized access to production systems.

Identify relevant control areas:

Access Control

Identity Management

Authentication Information

Access Rights

Privileged Access Rights

Secure Authentication

Logging

Monitoring

Create the mapping:

RISK-001
      │
      ├── IAM-001 Identity Lifecycle
      ├── IAM-002 Privileged MFA
      ├── IAM-003 Privileged Access Review
      ├── IAM-004 PAM
      ├── LOG-001 Administrative Logging
      └── MON-001 Security Monitoring

Part 6 — Build Enterprise Control Statements

Step 10 — Create Enterprise Control Library

Create:

05-Enterprise-Control-Library.md

Use:

Field
Internal Control ID
Control Name
Control Statement
Annex A Mapping
Control Objective
Owner
Operator
Frequency
Evidence
Risk Mapping

Step 11 — Build IAM-001

Control ID:
IAM-001

Control Name:
Identity Lifecycle Management

Control statement:

The IAM team creates, modifies, and removes workforce identities based on authorized HR or business events, ensuring access remains aligned with current employment and role requirements.

Owner:

IAM Manager

Frequency:

Event Driven

Evidence:

Provisioning Requests

HR Feed

Deprovisioning Logs

IAM Reports

Step 12 — Build IAM-002

Control ID:
IAM-002

Control Name:
Privileged Multi-Factor Authentication

Control statement:

All privileged workforce identities must use approved multi-factor authentication before obtaining administrative access to production systems.

Owner:

IAM Manager

Frequency:

Continuous

Evidence:

MFA Coverage Report

Identity Configuration

Exception Register

Mapped risk:

RISK-001

Mapped requirement:

REQ-002

Step 13 — Build IAM-003

Control ID:
IAM-003

Control Name:
Quarterly Privileged Access Review

Control statement:

The IAM team coordinates a quarterly review of privileged production access, and access no longer supported by an approved business requirement is removed within five business days.

Frequency:

Quarterly

Evidence:

Access Review Report

Reviewer Approval

Removal Tickets

Part 7 — Map Cloud Security Risk

Step 14 — Risk RISK-002

Risk:

Cloud resources may be incorrectly configured, resulting in unauthorized exposure of customer data.

Possible enterprise controls:

CLD-001 Secure Cloud Configuration Baseline

CLD-002 Infrastructure-as-Code Review

CLD-003 Policy-as-Code Enforcement

CLD-004 Cloud Security Posture Monitoring

IAM-002 Privileged MFA

LOG-001 Cloud Administrative Logging

Step 15 — Build CLD-001

Control statement:

Production cloud resources must conform to approved security configuration baselines before and after deployment.

Owner:

Cloud Security Manager

Frequency:

Continuous

Evidence:

Baseline Configuration

CSPM Reports

Exception Records

Step 16 — Build CLD-003

Control statement:

Production cloud deployment pipelines must automatically prevent deployment of configurations that violate defined critical cloud-security policies.

Owner:

Cloud Engineering

Frequency:

Continuous

Evidence:

Policy-as-Code Rules

Pipeline Results

Blocked Deployment Logs

Part 8 — Map Ransomware Risk

Step 17 — Risk RISK-003

Risk:

Ransomware may compromise enterprise systems and disrupt critical customer services.

Map controls such as:

END-001 Endpoint Protection

VUL-001 Vulnerability Management

IAM-002 MFA

NET-001 Network Segmentation

BCK-001 Backup

BCK-002 Recovery Testing

IR-001 Incident Response

Step 18 — Build BCK-001

Control statement:

Critical production information and system configurations must be backed up according to approved recovery requirements, with backups protected against unauthorized modification or deletion.

Owner:

IT Operations Manager

Frequency:

Daily / Defined Schedule

Evidence:

Backup Reports

Backup Configuration

Failure Alerts

Step 19 — Build BCK-002

Control statement:

Recovery procedures for critical services must be tested at planned intervals to confirm that recovery-time and recovery-point objectives can be achieved.

Frequency:

Quarterly

Evidence:

Recovery Test Report

Restoration Evidence

Lessons Learned

Mapped requirement:

REQ-007

Part 9 — Map Supplier Risk

Step 20 — Risk RISK-004

Risk:

A critical SaaS provider may experience a compromise that exposes CloudNova or customer information.

Map:

TPR-001 Vendor Risk Assessment

TPR-002 Contract Security Requirements

TPR-003 Vendor Reassessment

TPR-004 Vendor Monitoring

TPR-005 Vendor Offboarding

Step 21 — Build TPR-001

Control statement:

Vendors that process confidential information or support critical business services must undergo a security risk assessment before approval.

Owner:

GRC Manager

Frequency:

Before Onboarding

Evidence:

Vendor Assessment Report

Risk Rating

Approval

Step 22 — Build TPR-003

Control statement:

Critical vendors must be reassessed at least annually and following material security events or significant changes to the service.

Mapped requirement:

REQ-004

Evidence:

Annual Assessment

SOC Review

Certification Review

Open Findings

Part 10 — Map Secure Development Risk

Step 23 — Risk RISK-010

Risk:

Insecure software changes may introduce vulnerabilities into the production SaaS platform.

Map:

SDLC-001 Security Requirements

SDLC-002 Secure Coding

SDLC-003 Code Review

SDLC-004 Dependency Scanning

SDLC-005 Application Security Testing

CHG-001 Change Management

DEV-001 Environment Separation

Step 24 — Build SDLC-002

Control statement:

Developers must follow approved secure coding standards when developing or modifying production application code.

Owner:

Engineering Director

Evidence:

Secure Coding Standard

Training Records

Code Review Records

Step 25 — Build SDLC-005

Control statement:

Production applications must undergo defined security testing before release, with material findings remediated or formally accepted before deployment.

Evidence:

SAST

DAST

Dependency Scan

Penetration Test

Exception Approval

Mapped requirement:

REQ-006

Part 11 — Map Monitoring Risk

Step 26 — Risk RISK-007

Risk:

Inadequate logging may prevent timely detection and investigation of malicious activity.

Map:

LOG-001 Security Event Logging

LOG-002 Privileged Activity Logging

MON-001 Security Monitoring

MON-002 Alert Investigation

TIM-001 Clock Synchronization

Step 27 — Build LOG-002

Control statement:

Privileged administrative activities performed within production systems must be logged and retained in accordance with the security logging standard.

Mapped requirement:

REQ-008

Owner:

SOC Manager

Evidence:

Log Source Inventory

SIEM Events

Retention Configuration

Part 12 — Map Data Protection Risk

Step 28 — Risk RISK-006

Risk:

Confidential customer information may be disclosed through unauthorized transfer or data leakage.

Map:

DAT-001 Information Classification

DAT-002 Encryption in Transit

DAT-003 Encryption at Rest

DAT-004 Data Leakage Prevention

DAT-005 Information Transfer

DAT-006 Secure Deletion

Step 29 — Map Requirements

Relevant requirements:

REQ-001
Protect customer information

REQ-005
Encrypt customer data

This demonstrates:

Risk
+
Contract
+
Internal Standard
      ↓
Control Applicability

Part 13 — Build the Statement of Applicability

Step 30 — Create the SoA

Create:

02-Statement-of-Applicability.md

Use:

Reference	Control	Applicable	Driver	Justification	Status	Internal Control	Owner	Risk	Evidence

Step 31 — Example Entry

Field	Value
Control	Secure Authentication
Applicable	Yes
Driver	Risk + Internal Policy
Justification	Required to reduce credential-compromise risk
Status	Implemented
Internal Control	IAM-002
Owner	IAM Manager
Risk	RISK-001
Evidence	MFA Coverage Report

Part 14 — Identify an Inherited Control

Step 32 — Physical Data Center Security

CloudNova does not operate its production data centers.

AWS provides underlying data-center security.

Do not automatically mark this:

Not Applicable

Consider:

Applicable:
Yes

Implementation:
Inherited

Justification:

Physical protection of the production hosting environment is relevant to system confidentiality, integrity, and availability. The underlying facility controls are implemented by CloudNova’s approved cloud provider and governed through supplier assurance.

Evidence:

Cloud Provider Assurance Report

ISO Certificate

Supplier Assessment

Owner:

Cloud Governance

Part 15 — Identify a Shared Control

Step 33 — Business Continuity

For cloud availability:

Cloud Provider
→ Infrastructure availability

CloudNova
→ Application architecture and recovery

So:

Implementation:
Shared

Document who performs which part.

Example:

Responsibility	Party
Physical infrastructure redundancy	Provider
Multi-AZ application design	CloudNova
Application recovery	CloudNova
Provider resilience assurance	CloudNova GRC

Part 16 — Determine a Non-Applicable Control

Step 34 — Evaluate Carefully

Assume a specific facility-related control has no relevance because:

CloudNova does not operate the relevant type of facility.
No in-scope business process depends on such a facility.
No residual interface remains.

Document:

Applicable:
No

But use a specific justification.

Example:

This control is not applicable because CloudNova does not operate the specific type of physical facility addressed by the control within the ISMS scope, and no in-scope business process depends on such a facility.

Avoid:

Not needed.

Part 17 — Build Risk-to-Control Mapping

Step 35 — Create Matrix

Create:

03-Risk-to-Control-Mapping.md

Example:

Risk	Enterprise Control	Annex A Theme
RISK-001	IAM-002 Privileged MFA	Technological
RISK-001	IAM-003 Access Review	Organizational / Technological
RISK-002	CLD-001 Cloud Baseline	Technological
RISK-003	BCK-001 Backup	Technological
RISK-004	TPR-001 Vendor Assessment	Organizational
RISK-010	SDLC-005 Security Testing	Technological

Map every risk to at least one control.

Part 18 — Build Requirement-to-Control Mapping

Step 36 — Create Matrix

Create:

04-Requirement-to-Control-Mapping.md

Example:

Requirement	Control
REQ-001 Customer Data Protection	DAT-002, DAT-003, IAM-001
REQ-002 Privileged MFA	IAM-002
REQ-003 Incident Notification	IR-002
REQ-004 Annual Vendor Review	TPR-003
REQ-005 Encryption	DAT-002, DAT-003
REQ-006 Penetration Testing	SDLC-005
REQ-007 Recoverable Backups	BCK-001, BCK-002
REQ-008 Privileged Logging	LOG-002

This helps demonstrate compliance traceability.

Part 19 — Build the Control Ownership Matrix

Step 37 — Create

06-Control-Ownership-Matrix.md

Use:

Control	Owner	Operator	Evidence Provider	Reviewer

Example:

Part 20 — Build Evidence Matrix

Step 38 — Create

07-Control-Evidence-Matrix.md

Use:

Control	Evidence	Frequency	Owner	Retention

Example:

Use retention values as lab assumptions, not universal ISO requirements.

Part 21 — Assess Implementation Status

Step 39 — Review Controls

Assume the following:

IAM-002 Privileged MFA
→ 100% implemented

IAM-003 Privileged Access Review
→ Q2 review missed

TPR-003 Vendor Reassessment
→ 2 vendors overdue

CLD-003 Policy-as-Code
→ 70% deployment coverage

BCK-002 Recovery Testing
→ Implemented

Assign appropriate statuses.

Suggested:

IAM-002
Implemented

IAM-003
Partially Implemented

TPR-003
Partially Implemented

CLD-003
Partially Implemented

BCK-002
Implemented

Part 22 — Create the Control Gap Register

Step 40 — Create

08-Control-Gap-Register.md

Use:

Gap ID	Control	Gap	Risk	Treatment	Owner	Target

Step 41 — Gap 01

GAP-001

Control:
IAM-003

Gap:

Q2 privileged access review was not completed.

Risk:

RISK-001

Action:

Implement centralized control scheduling and complete missed review.

Owner:

IAM Manager

Step 42 — Gap 02

GAP-002

Control:
TPR-003

Gap:

Two critical vendor reassessments are overdue.

Action:

Complete assessments and implement automated reassessment reminders.

Step 43 — Gap 03

GAP-003

Control:
CLD-003

Gap:

Policy-as-code deployment enforcement covers only 70% of production deployment pipelines.

Action:

Extend preventive deployment controls to all production repositories.

Part 23 — Link Gaps to Risk Treatment Plan

Step 44 — Build Traceability

For GAP-003:

RISK-002
      ↓
Risk Treatment
      ↓
CLD-003
      ↓
70% Implemented
      ↓
GAP-003
      ↓
Remediation
      ↓
100% Pipeline Coverage

This demonstrates that the SoA is connected to live risk management.

Part 24 — Reconcile SoA With Risk Register

Step 45 — Ask

For every High or Critical risk:

Are controls mapped?

Are mapped controls applicable in SoA?

Does implementation status reflect reality?

Are gaps visible?

Is treatment linked?

Example:

RISK-001
High

If the SoA says:

IAM controls:
Not Applicable

there is a clear inconsistency.

Part 25 — Reconcile SoA With RTP

Step 46 — Compare

Risk Treatment Plan:

Deploy policy-as-code

SoA:

Relevant control:
Implemented

but actual status:

70%

Correct the SoA to:

Partially Implemented

The SoA should describe the real control state.

Part 26 — Reconcile SoA With Evidence

Step 47 — Test Evidence

SoA says:

IAM-002
Implemented

Check:

MFA Coverage:
100%

Result:

Consistent

SoA says:

TPR-003
Implemented

Evidence:

2 critical reviews overdue

Result:

Inconsistent

Update status.

Part 27 — Create SoA Reconciliation Checklist

Step 48 — Create

09-SoA-Reconciliation-Checklist.md

Include:

All Annex A controls considered.
Applicability decision recorded.
Inclusion justification recorded.
Exclusion justification recorded.
Implementation status validated.
Risk mappings reviewed.
Requirement mappings reviewed.
RTP mappings reviewed.
Control owners validated.
Evidence identified.
Inherited controls documented.
Shared controls documented.
Open control gaps visible.
SoA version updated.
SoA approved.

Part 28 — Perform Control Walkthroughs

Step 49 — Select Five Controls

Test:

IAM-002 Privileged MFA

IAM-003 Privileged Access Review

CLD-003 Policy-as-Code

TPR-003 Vendor Reassessment

BCK-002 Recovery Testing

For each ask:

What is the control objective?

Who owns it?

How does it operate?

How frequently?

What population is covered?

What evidence is generated?

What exceptions exist?

Is status in SoA accurate?

Part 29 — Example Control Walkthrough

IAM-003

Control statement:

Quarterly review of privileged production access.

Owner:

IAM Manager

Evidence:

Q1 Report

Q2 Missing

Q3 Report

Q4 Not Yet Due

Conclusion:

Control Design:
Effective

Operating Effectiveness:
Partially Effective

SoA Status:
Partially Implemented

This is a strong audit-ready conclusion.

Part 30 — Create an Evidence Index

Step 50 — Validate Evidence Locations

For every control, identify where evidence lives.

Example:

IAM
→ Identity Platform

Vulnerability Management
→ Security Scanner

Vendor Risk
→ GRC Repository

Backup
→ IT Operations Platform

Logging
→ SIEM

Avoid vague entries like:

Evidence:
Somewhere in SharePoint

Part 31 — Build Control Testing Readiness

Step 51 — Add Testability

Every enterprise control should answer:

Can an auditor identify a population?

Can samples be selected?

Can evidence be retrieved?

Can exceptions be identified?

Can effectiveness be concluded?

If no, rewrite the control statement.

Part 32 — Example Weak Control

Employees should use good security practices.

Not easily testable.

Part 33 — Improved Control

All workforce members must complete approved information-security awareness training upon joining and annually thereafter.

Now identify:

Population:
All workforce members

Frequency:
Annual

Evidence:
Training report

Owner:
Security Awareness Manager

This is auditable.

Part 34 — Cross-Framework Reuse

Step 52 — Identify Reusable Controls

Suppose:

IAM-002 Privileged MFA

also supports:

SOC 2

PCI DSS

NIST

Customer Contract

Do not create four separate MFA controls.

Use:

Enterprise Control
      ↓
Multiple Framework Mappings

This creates one source of truth.

Part 35 — Create a Common Control Example

Enterprise Control:
IAM-002

ISO:
Mapped

SOC 2:
Mapped

PCI DSS:
Mapped

NIST:
Mapped

Internal Policy:
Mapped

This demonstrates scalable GRC architecture.

Part 36 — SoA Executive Summary

Step 53 — Create

10-SoA-Executive-Summary.md

Include:

Applicable Controls

Implemented Controls

Partial Controls

Planned Controls

Inherited Controls

Shared Controls

Open High-Risk Gaps

Top Remediation Priorities

Part 37 — Example Executive Dashboard

Metric	Result
Annex A Controls Reviewed	93
Applicable	82
Not Applicable	11
Implemented	68
Partially Implemented	9
Planned	5
Inherited / Shared	12
High-Priority Gaps	3

These values are fictional for the lab.

The objective is learning the reporting structure.

Part 38 — Executive Narrative

Write:

CloudNova has completed the initial ISO/IEC 27001 Annex A applicability review and established a formal Statement of Applicability. Most applicable controls are operational, but several high-priority gaps remain in privileged access review execution, critical vendor reassessment, and cloud policy-as-code coverage. These gaps are linked to the Risk Treatment Plan and have assigned owners and remediation targets. Inherited and shared cloud controls have also been identified and mapped to supplier assurance evidence.

Part 39 — Auditor Simulation

Imagine the certification auditor selects:

Privileged Access

Be prepared to provide:

Risk
      ↓
RISK-001

SoA
      ↓
Applicable

Enterprise Control
      ↓
IAM-003

Policy
      ↓
Access Control Policy

Owner
      ↓
IAM Manager

Evidence
      ↓
Access Review Reports

Finding
      ↓
Q2 Review Missing

Treatment
      ↓
Centralized Review Scheduling

This is audit traceability.

Part 40 — Auditor Simulation: Supplier Security

Auditor asks:

Why is supplier security applicable?

Answer should connect to:

Critical SaaS Dependency
+
RISK-004
+
REQ-004
+
Customer Data Processing

Then provide:

Vendor Security Policy

Vendor Risk Procedure

Assessment Reports

SOC Review

Annual Reassessment

Open Findings

Part 41 — Auditor Simulation: Exclusion

Auditor asks:

Why did you exclude this physical facility control?

Your answer should explain:

Scope.
Actual business environment.
No internal facility dependency.
Any inherited provider responsibility.
Related assurance controls.

Never answer:

Because we use AWS.

That is too simplistic.

Part 42 — Common Lab Mistakes

Mistake 1 — Confusing Applicability and Implementation

A control can be:

Applicable
+
Not Yet Implemented

These are separate concepts.

Mistake 2 — Marking Difficult Controls Not Applicable

Implementation difficulty is not a valid exclusion reason.

Mistake 3 — Treating Cloud Controls as Automatically Not Applicable

Responsibilities may be inherited or shared.

Mistake 4 — Generic Justifications

Avoid:

Required by ISO.

Use actual risk or requirement drivers.

Mistake 5 — No Risk Mapping

The SoA becomes disconnected from the ISMS.

Mistake 6 — No Evidence Mapping

Controls cannot easily be audited.

Mistake 7 — Status Does Not Match Reality

A partially operating control should not be marked fully implemented.

Mistake 8 — Separate Duplicate Controls

Avoid maintaining separate controls for every framework.

Mistake 9 — No Owner

Controls without owners usually deteriorate.

Mistake 10 — SoA Treated as Static

It must evolve with risks, scope, requirements, and control changes.

Part 43 — Final Deliverables

Your completed lab should contain:

01 — Annex A Control Register

02 — Statement of Applicability

03 — Risk-to-Control Mapping

04 — Requirement-to-Control Mapping

05 — Enterprise Control Library

06 — Control Ownership Matrix

07 — Control Evidence Matrix

08 — Control Gap Register

09 — SoA Reconciliation Checklist

10 — SoA Executive Summary

Lab Validation Checklist

Before completing the lab:

Reviewed all four Annex A control themes.
Considered the full Annex A control set.
Defined applicability values.
Defined implementation statuses.
Identified applicability drivers.
Mapped risks to controls.
Mapped requirements to controls.
Created testable enterprise control statements.
Assigned control owners.
Defined operators.
Defined control frequencies.
Identified control evidence.
Documented inherited controls.
Documented shared controls.
Documented defensible exclusions.
Built the SoA.
Reconciled SoA with risk register.
Reconciled SoA with RTP.
Reconciled SoA with evidence.
Identified control gaps.
Linked gaps to treatment actions.
Performed sample control walkthroughs.
Created executive reporting.

Expected Skills After This Lab

After completing this lab, you should be comfortable performing:

Risk
      ↓
Treatment
      ↓
Annex A Review
      ↓
Applicability
      ↓
Enterprise Control
      ↓
Owner
      ↓
Evidence
      ↓
Testing
      ↓
Gap
      ↓
Remediation
      ↓
SoA

This is a core workflow used by ISO/IEC 27001 GRC and ISMS professionals.

Real-World GRC Perspective

In a mature enterprise, the SoA should not live in isolation.

A stronger model is:

Risk Register
      │
      ↓
Enterprise Control Library
      │
      ├── ISO/IEC 27001
      ├── SOC 2
      ├── PCI DSS
      ├── NIST
      └── Internal Requirements
      │
      ↓
Evidence
      ↓
Control Testing
      ↓
Findings
      ↓
Remediation

This creates a common control model.

Instead of asking teams for the same evidence repeatedly for every framework, the organization can test one well-designed enterprise control and reuse the result across multiple compliance obligations.

That is how GRC begins to scale.

Mission Complete

You have now built an enterprise-style Statement of Applicability and ISO control mapping framework.

You moved from:

Annex A Checklist

to:

Risk-Based Applicability
      ↓
Enterprise Controls
      ↓
Ownership
      ↓
Evidence
      ↓
Assurance

This is the difference between simply completing an ISO spreadsheet and operating a mature control-governance model.

What’s Next?

➡️ Next: Runbook 01 — ISO/IEC 27001 Implementation & Certification Readiness

In the next activity, you will turn the full ISO implementation process into a repeatable operational runbook.

You will build the workflow:

ISO Initiative Approved
        ↓
Define Context
        ↓
Establish Scope
        ↓
Establish Governance
        ↓
Perform Gap Assessment
        ↓
Perform Risk Assessment
        ↓
Develop RTP
        ↓
Build SoA
        ↓
Implement Controls
        ↓
Collect Evidence
        ↓
Internal Audit
        ↓
Management Review
        ↓
Corrective Actions
        ↓
Stage 1 Readiness
        ↓
Stage 2 Readiness
        ↓
Certification
        ↓
Surveillance

The runbook will give GRC analysts a repeatable step-by-step enterprise procedure for taking an organization from ISO/IEC 27001 project initiation through certification readiness.