07 Build an Enterprise Compliance Control Matrix

Welcome to the seventh project in:

Module 11 — Enterprise GRC Transformation Project

In the previous projects, you completed:

Enterprise Risk Assessment
        ↓
Build an ISMS
        ↓
ISO 27001 Gap Assessment
        ↓
SOC 2 Readiness Review
        ↓
PCI DSS Assessment
        ↓
Cloud Compliance Review

You now have multiple frameworks, requirements, controls, evidence sources, owners, and assessments.

A new enterprise problem appears:

Too Many
Frameworks

CloudNova currently manages compliance separately:

ISO 27001 Controls
        +
SOC 2 Controls
        +
PCI DSS Controls
        +
ISO 27017 Controls
        +
ISO 27018 Controls

This creates:

Duplicate Controls

Duplicate Evidence

Duplicate Testing

Duplicate Interviews

Duplicate Remediation

Compliance Fatigue

Your assignment is to transform this fragmented approach into:

One Enterprise
Compliance
Control Matrix

Project Objective

Your objective is to move CloudNova from:

Framework
     ↓
Separate Controls
     ↓
Separate Evidence
     ↓
Separate Testing

to:

Enterprise Risk
      ↓
Common Control
      ↓
Control Owner
      ↓
Implementation
      ↓
Evidence
      ↓
Testing
      ↓
Framework Mapping
      ↓
Multiple Compliance
Requirements

The central principle is:

Implement Once

Test Once

Collect Evidence Once

Map Many Times

Mission Information

Project Type: Enterprise Common Control Framework & Compliance Mapping
Difficulty: Advanced
Estimated Time: 6–8 Hours
Primary Role: GRC Analyst / Compliance Architect
Supporting Roles: Security / Internal Audit / IAM / Cloud / Privacy / IT / Risk / Legal / Control Owners
Frameworks: ISO 27001, SOC 2, PCI DSS, ISO 27017, ISO 27018, NIST CSF
Environment: Spreadsheet / GRC Platform / Documentation Platform
Deliverable: Enterprise Compliance Control Matrix & Common Control Framework

Important: Framework requirements and mappings change as standards evolve. Real-world mappings should always be validated against the organization’s licensed/current versions of the applicable standards.

Learning Objectives

By completing this project, you will learn how to:

understand enterprise control frameworks.
distinguish requirements from controls.
distinguish controls from evidence.
create common enterprise controls.
normalize controls across frameworks.
map multiple frameworks.
establish control objectives.
create control IDs.
assign control owners.
identify control operators.
define control frequency.
classify preventive, detective, and corrective controls.
distinguish manual and automated controls.
map risks to controls.
map policies to controls.
map controls to frameworks.
establish evidence requirements.
eliminate duplicate evidence collection.
create testing procedures.
identify control dependencies.
manage compensating controls.
identify control gaps.
manage framework changes.
build compliance dashboards.
support continuous compliance.
create a scalable Common Control Framework.

Scenario

CloudNova’s GRC team maintains separate spreadsheets for:

ISO 27001

SOC 2

PCI DSS

Cloud Compliance

Privacy Compliance

The IAM team receives multiple requests:

ISO Auditor:
"Show MFA Evidence."

SOC 2 Auditor:
"Show MFA Evidence."

PCI Assessor:
"Show MFA Evidence."

Cloud Compliance:
"Show MFA Evidence."

The IAM manager asks:

Why Are We
Providing the
Same Evidence
Four Times?

The CISO asks:

Why Do We Have
Four Different
MFA Controls?

Your answer should be:

We Shouldn't.

Instead, CloudNova needs:

One MFA Control
      ↓
One Owner
      ↓
One Implementation
      ↓
One Evidence Process
      ↓
Multiple Framework
Mappings

Your Mission

Build CloudNova’s:

Enterprise
Common Control
Framework

and create a master:

Compliance
Control Matrix

that connects:

Risk

Policy

Control

Owner

Implementation

Evidence

Testing

Framework

Requirement

Gap

Remediation

Required Deliverables

Create:

01 Framework Inventory

02 Requirement Inventory

03 Enterprise Control Taxonomy

04 Common Control Library

05 Risk-to-Control Matrix

06 Policy-to-Control Matrix

07 Framework-to-Control Matrix

08 Control Ownership Register

09 Evidence Mapping Matrix

10 Control Testing Matrix

11 Control Dependency Register

12 Gap & Exception Register

13 Compliance Coverage Matrix

14 Enterprise Compliance Dashboard

15 Control Framework Governance Standard

16 Continuous Compliance Plan

Part 1 — Understand the Problem

Without a Common Control Framework:

Framework A
   ↓
Control A1

Framework B
   ↓
Control B1

Framework C
   ↓
Control C1

Even though all three controls may address:

Multi-Factor
Authentication

This produces unnecessary duplication.

Part 2 — Build a Common Control Framework

Instead:

Enterprise Control
IAM-003
      ↓
Privileged MFA
      ↓
ISO 27001
      +
SOC 2
      +
PCI DSS
      +
ISO 27017
      +
NIST CSF

One control can support multiple requirements.

Part 3 — Understand Requirements vs Controls

Requirement

describes what must be achieved.

Control

describes what the organization implements to achieve it.

For example:

Requirement
      ↓
Restrict Access
to Authorized Users

CloudNova may implement:

IAM-001
Role-Based Access

IAM-002
Access Approval

IAM-003
MFA

IAM-004
Quarterly Access Review

Part 4 — Understand Controls vs Evidence

A control is not evidence.

Example:

Control:
Privileged MFA

Evidence might include:

MFA Configuration

Identity Report

User Population

Authentication Logs

Exception Report

Think:

Control
   ↓
Operates
   ↓
Produces Evidence

Part 5 — Start With Framework Inventory

Create an inventory of applicable frameworks.

Example:

Framework	Purpose	Scope	Owner
ISO 27001	ISMS	Enterprise	GRC
SOC 2	Assurance	SaaS Platform	Compliance
PCI DSS	Payment Security	CDE	Compliance
ISO 27017	Cloud Security	Cloud Services	Cloud GRC
ISO 27018	Cloud Privacy	Public Cloud PII	Privacy
NIST CSF	Cyber Risk	Enterprise	Security

Part 6 — Add Framework Metadata

Record:

Framework

Version / Edition

Regulatory / Contractual Driver

Scope

Business Unit

System

Data

Owner

Assessment Type

Assessment Frequency

Part 7 — Maintain Version Awareness

Do not record only:

ISO 27001

Record the applicable:

Framework
+
Edition
+
Scope
+
Assessment Period

Framework changes can affect mappings.

Part 8 — Build Requirement Inventory

Create a normalized inventory containing:

Requirement ID

Framework

Requirement Reference

Requirement Summary

Domain

Applicability

Scope

Mapped Controls

Owner

Status

Part 9 — Do Not Copy Standards Unnecessarily

The purpose of your matrix is not to reproduce copyrighted standards.

Instead maintain:

Requirement Reference
        +
Internal Summary
        +
Control Mapping

while using licensed official standards as the authoritative source.

Part 10 — Create Enterprise Control Domains

Organize controls into logical domains.

For CloudNova:

GOV — Governance

RISK — Risk Management

IAM — Identity & Access

HR — Human Resources Security

AST — Asset Management

DATA — Data Protection

CRY — Cryptography

NET — Network Security

CFG — Configuration Management

VUL — Vulnerability Management

APP — Application Security

CLD — Cloud Security

LOG — Logging & Monitoring

IR — Incident Response

BCM — Business Continuity

TPRM — Third-Party Risk

PHY — Physical Security

PRV — Privacy

AUD — Audit & Assurance

CMP — Compliance Management

Part 11 — Create Control IDs

Use predictable identifiers.

Example:

IAM-001

IAM-002

IAM-003

NET-001

LOG-001

IR-001

Avoid:

Control 17

Security Control New

SOC-MFA-Control

PCI-MFA-Control

Part 12 — Create Control Naming Standard

Use:

Domain
+
Control Objective

Examples:

IAM-001 — User Access Provisioning

IAM-002 — Privileged Access Management

IAM-003 — Multi-Factor Authentication

IAM-004 — Periodic Access Review

LOG-001 — Security Event Logging

VUL-001 — Vulnerability Scanning

Part 13 — Define Control Objective

Every control should explain:

What Risk
Does This
Control Address?

Example:

Control:
IAM-003

Objective:
Reduce the risk of
unauthorized account
access through strong
authentication.

Part 14 — Define Control Description

Example:

CloudNova requires
multi-factor authentication
for applicable privileged,
remote, and sensitive
system access.

The description should explain:

Who

What

Where

When

How

Part 15 — Create Control Record

Each control should contain:

Control ID

Control Name

Domain

Control Objective

Description

Risk

Policy

Owner

Operator

Scope

Frequency

Control Type

Automation

Evidence

Testing Procedure

Framework Mapping

Status

Part 16 — Example Control Record

Control ID:
IAM-003

Control:
Multi-Factor Authentication

Domain:
Identity & Access

Owner:
IAM Manager

Operator:
Identity Operations

Type:
Preventive

Frequency:
Continuous

Automation:
Automated

Evidence:
MFA Configuration
MFA Coverage Report
Exception Register
Authentication Logs

Part 17 — Classify Control Types

Controls may be:

Preventive

Detective

Corrective

Example:

MFA
→ Preventive

Security Alert
→ Detective

Account Disablement
→ Corrective

Part 18 — Manual vs Automated

Classify controls as:

Manual

Semi-Automated

Automated

Example:

Quarterly
Access Review
→ Manual / Semi-Automated

MFA Enforcement
→ Automated

SIEM Alert
→ Automated

Part 19 — Frequency

Define frequencies such as:

Continuous

Event-Driven

Daily

Weekly

Monthly

Quarterly

Semi-Annual

Annual

Frequency should reflect the control’s purpose and applicable requirements.

Part 20 — Assign Control Owners

The control owner is accountable for:

Control Design

Implementation

Operation

Evidence

Remediation

Do not assign every control to:

Security Team

Part 21 — Example Ownership

IAM Controls
→ IAM Manager

Network Controls
→ Network Manager

Cloud Controls
→ Cloud Platform Manager

HR Controls
→ HR

Vendor Controls
→ Procurement / TPRM

Privacy Controls
→ Privacy

Incident Controls
→ SOC / Security

Part 22 — Owner vs Operator

These may differ.

Example:

Control Owner:
CISO

Control Operator:
SOC Team

or:

Control Owner:
IAM Manager

Control Operator:
Identity Operations

Part 23 — Map Risks to Controls

Connect the Enterprise Risk Register to the control library.

Example:

Risk	Control	Relationship
Unauthorized Access	IAM-003 MFA	Mitigates
Excessive Privilege	IAM-002 PAM	Mitigates
Data Leakage	DATA-002 DLP	Mitigates
Malware	END-001 Endpoint Protection	Mitigates

Part 24 — One Risk Can Have Multiple Controls

Example:

Risk:
Account Compromise

Controls:

MFA

Password Policy

Conditional Access

PAM

Authentication Monitoring

User Awareness

Think:

Risk
 ↓
Multiple Layers
of Controls

Part 25 — One Control Can Address Multiple Risks

Example:

MFA

can help reduce:

Credential Theft

Remote Access Abuse

Privileged Account Compromise

Cloud Account Takeover

Part 26 — Build Risk-to-Control Matrix

Use:

Risk ID	Risk	Control ID	Control	Coverage
R-001	Account Compromise	IAM-003	MFA	Primary
R-001	Account Compromise	LOG-002	Auth Monitoring	Secondary
R-002	Data Exposure	DATA-001	Classification	Supporting

Part 27 — Map Policies to Controls

Policies establish expectations.

Controls implement them.

Example:

Access Control Policy
       ↓
IAM-001
Provisioning

IAM-002
Privileged Access

IAM-003
MFA

IAM-004
Access Review

Part 28 — Build Policy-to-Control Matrix

Record:

Policy

Policy Section

Control ID

Control Owner

Implementation

Evidence

Part 29 — Begin Framework Mapping

Now connect enterprise controls to:

ISO 27001

SOC 2

PCI DSS

ISO 27017

ISO 27018

NIST CSF

Part 30 — Example Mapping

IAM-003
Multi-Factor Authentication
          ↓
ISO 27001
          ↓
SOC 2
          ↓
PCI DSS
          ↓
ISO 27017
          ↓
NIST CSF

The exact mapping must be validated against applicable framework versions.

Part 31 — Mapping Does Not Mean Equivalence

This is critical.

If:

Control A

maps to requirements in:

Framework X
+
Framework Y

it does not automatically mean those requirements are identical.

Mapping means:

Control Supports
Requirement

not necessarily:

Requirements
Are Equivalent

Part 32 — Add Mapping Strength

Use:

Primary

Supporting

Partial

Not Applicable

Example:

Control	ISO	SOC 2	PCI DSS	NIST
IAM-003	Primary	Supporting	Primary	Supporting
LOG-001	Primary	Primary	Primary	Primary

Part 33 — Identify Partial Coverage

Suppose a framework requires:

Access Approval
+
MFA
+
Access Review

Mapping only:

IAM-003 MFA

does not provide complete coverage.

Mark:

Partial

Part 34 — Many-to-Many Mapping

Real compliance mapping looks like:

Requirement 1
 ├── Control A
 ├── Control B
 └── Control C

Control A
 ├── Requirement 1
 ├── Requirement 7
 └── Requirement 14

This is:

Many-to-Many
Mapping

Part 35 — Build Framework-to-Control Matrix

Example:

Control	ISO 27001	SOC 2	PCI DSS	ISO 27017	ISO 27018	NIST CSF
IAM-001	✓	✓	✓	✓		✓
IAM-003	✓	✓	✓	✓		✓
LOG-001	✓	✓	✓	✓		✓
PRV-001	✓	✓			✓	✓

Part 36 — Identify Control Coverage

For each framework calculate:

Applicable Requirements

Mapped Requirements

Fully Covered

Partially Covered

Unmapped

Part 37 — Coverage Is Not Compliance

Do not say:

100%
Requirements Mapped

Therefore
100% Compliant

Mapping only shows:

Control
Coverage

Compliance also requires:

Implementation

Operating Effectiveness

Evidence

Scope

Applicability

Part 38 — Build Common Control Library

Create one authoritative:

Enterprise
Control Library

Do not maintain separate master controls for every framework.

Part 39 — Example IAM Control Family

IAM-001
Identity Lifecycle

IAM-002
Access Approval

IAM-003
Multi-Factor Authentication

IAM-004
Privileged Access Management

IAM-005
Access Review

IAM-006
Service Account Management

IAM-007
Emergency Access

IAM-008
Authentication Monitoring

Part 40 — Network Control Family

NET-001
Network Segmentation

NET-002
Firewall Management

NET-003
Internet Exposure Management

NET-004
Remote Access Security

NET-005
Network Monitoring

NET-006
Network Configuration Review

Part 41 — Data Protection Control Family

DATA-001
Data Classification

DATA-002
Data Handling

DATA-003
Data Retention

DATA-004
Secure Deletion

DATA-005
Data Loss Prevention

DATA-006
Sensitive Data Access

Part 42 — Logging Control Family

LOG-001
Security Event Logging

LOG-002
Central Log Collection

LOG-003
Log Protection

LOG-004
Security Monitoring

LOG-005
Alert Investigation

LOG-006
Log Retention

Part 43 — Vulnerability Control Family

VUL-001
Vulnerability Scanning

VUL-002
Patch Management

VUL-003
Vulnerability Remediation

VUL-004
Penetration Testing

VUL-005
Dependency Scanning

VUL-006
Container Scanning

Part 44 — Cloud Control Family

CLD-001
Cloud Service Onboarding

CLD-002
Cloud Security Baseline

CLD-003
Cloud IAM

CLD-004
Cloud Logging

CLD-005
Cloud Configuration Monitoring

CLD-006
Cloud Data Protection

CLD-007
Cloud Backup

CLD-008
Cloud Exit Management

Part 45 — Privacy Control Family

PRV-001
PII Inventory

PRV-002
Processing Purpose

PRV-003
Data Minimization

PRV-004
PII Access

PRV-005
PII Retention

PRV-006
PII Deletion

PRV-007
Privacy Incident Response

PRV-008
Subprocessor Management

Part 46 — Evidence Mapping

Now ask:

What Evidence
Proves Each
Control?

Part 47 — Evidence Catalog

Create evidence IDs:

E-IAM-001

E-IAM-002

E-NET-001

E-LOG-001

Part 48 — Example Evidence Mapping

IAM-003
Multi-Factor Authentication
        ↓
E-IAM-003A
MFA Configuration

E-IAM-003B
MFA Coverage Report

E-IAM-003C
Exception Register

E-IAM-003D
Authentication Logs

Part 49 — Reuse Evidence

The same evidence may support:

ISO 27001

SOC 2

PCI DSS

Cloud Compliance

Avoid collecting identical evidence separately.

Part 50 — Evidence Metadata

Record:

Evidence ID

Control ID

Artifact

System

Owner

Frequency

Period

Location

Retention

Automation

Frameworks Supported

Part 51 — Build Evidence Matrix

Example:

Evidence	Control	ISO	SOC 2	PCI	Cloud
MFA Report	IAM-003	✓	✓	✓	✓
Firewall Review	NET-002	✓	✓	✓	✓
Incident Test	IR-004	✓	✓	✓	✓

Part 52 — Evidence Once, Use Many

The future state should be:

Control Operates
      ↓
Evidence Generated
      ↓
Evidence Repository
      ↓
Mapped Automatically
      ↓
ISO
SOC 2
PCI
Cloud

Part 53 — Establish Evidence Repository

Evidence should not live only in:

Auditor Email

Desktop Folder

Random SharePoint Folder

Individual Laptop

Create an authoritative repository.

Part 54 — Evidence Naming Standard

Example:

2026-Q3_IAM-003_MFA-Coverage

2026-Q3_NET-002_Firewall-Review

2026-08_LOG-001_Log-Configuration

Part 55 — Evidence Quality

Assess:

Completeness

Accuracy

Period

Population

Traceability

Integrity

Approver

Source

Part 56 — Build Control Testing Procedures

Each control should have a reusable:

Test Procedure

Example:

Control:
IAM-003

Test:

1. Obtain user population.
2. Identify applicable accounts.
3. Obtain MFA configuration.
4. Compare population to enrollment.
5. Identify exceptions.
6. Validate approved exceptions.
7. Sample authentication events.
8. Document conclusion.

Part 57 — Test Once, Map Many

Instead of:

ISO MFA Test

SOC MFA Test

PCI MFA Test

perform:

Enterprise
IAM-003 Test

Then map the result to relevant requirements.

Part 58 — Control Test Record

Maintain:

Test ID

Control ID

Tester

Period

Population

Sample

Procedure

Evidence

Exceptions

Conclusion

Framework Impact

Part 59 — Design Effectiveness

Ask:

If the Control
Operates as Designed,

Will It Achieve
Its Objective?

Part 60 — Operating Effectiveness

Ask:

Did the Control
Actually Operate
as Designed
During the Period?

Part 61 — Example

Control:

Quarterly
Access Review

Design:

Quarterly Review
Defined

Operation:

Q1 ✓
Q2 ✓
Q3 Missing
Q4 ✓

Conclusion:

Design Effective

Operating
Effectiveness
Exception

Part 62 — Build Control Dependency Register

Controls frequently depend on other controls.

Example:

LOG-004
Security Monitoring
      ↓
Depends On
      ↓
LOG-001
Event Logging

If logging fails:

Monitoring
May Also Fail

Part 63 — Another Dependency

IAM-005
Access Review
      ↓
Depends On
      ↓
Accurate Identity
Inventory

Bad inventory produces:

Bad Review

Part 64 — Identify Key Controls

Not every control has equal importance.

Identify:

Key Controls

Supporting Controls

Compensating Controls

Part 65 — Key Control

A key control is one whose failure could materially affect:

Risk

Compliance

Security

Assurance

Part 66 — Compensating Controls

When a required or expected control cannot be implemented as designed, an alternative may sometimes mitigate the risk.

But:

Alternative
Control

must not automatically be assumed to satisfy:

Framework
Requirement

Validate applicable framework rules.

Part 67 — Exception Management

Create:

Exception ID

Control

Reason

Risk

Compensating Control

Owner

Approval

Expiry

Review Date

Status

Part 68 — Exceptions Need Expiry Dates

Avoid:

Temporary
Exception

Created:
2022

Status:
Still Open

Require:

Expiry

Review

Renewal

Closure

Part 69 — Build Compliance Gap Register

A gap may occur because:

Requirement
Not Mapped

Control Missing

Control Poorly Designed

Control Not Implemented

Control Failed

Evidence Missing

Scope Incorrect

Part 70 — Classify Gap Types

Use:

Mapping Gap

Design Gap

Implementation Gap

Operating Gap

Evidence Gap

Ownership Gap

Scope Gap

Part 71 — Example Gap

Gap:
CMP-014

Requirement:
Periodic access review

Mapped Control:
IAM-005

Condition:
Control exists but
Q2 review was not
performed.

Gap Type:
Operating Gap

Part 72 — Avoid Duplicate Findings

If one failed control affects:

ISO

SOC 2

PCI DSS

do not automatically create three separate remediation projects.

Create:

One
Control Deficiency

with:

Multiple
Compliance Impacts

Part 73 — Example

Deficiency:
IAM-003
MFA Coverage
Incomplete
       ↓
Impacts
       ↓
ISO 27001

SOC 2

PCI DSS

Cloud Compliance

Part 74 — Prioritize by Enterprise Risk

Do not prioritize only because:

Auditor
Asked First

Use:

Risk Severity

Control Criticality

Framework Impact

Business Impact

Exploitability

Regulatory Exposure

Part 75 — Build Remediation Record

Record:

Gap ID

Control

Risk

Affected Frameworks

Action

Owner

Target Date

Evidence

Retest

Status

Part 76 — Framework Coverage Analysis

Calculate:

Total Applicable
Requirements

Fully Covered

Partially Covered

Unmapped

Control Effective

Control Deficient

Part 77 — Example Coverage Dashboard

ISO 27001

Applicable Requirements       100%

Mapped                         96%

Fully Covered                  91%

Partially Covered               5%

Unmapped                        4%

Effective Controls             87%

Values are illustrative.

Part 78 — Enterprise Dashboard

Example:

COMMON CONTROL FRAMEWORK

Enterprise Controls            142

Key Controls                    47

Frameworks                       6

Requirements Mapped            94%

Controls Effective             88%

Control Deficiencies            14

Critical Deficiencies            2

Evidence Ready                 91%

Open Exceptions                 11

Overdue Remediation              4

Part 79 — Dashboard by Domain

Domain	Controls	Effective	Gaps
IAM	12	92%	2
Network	10	90%	2
Cloud	15	80%	5
Logging	8	88%	2
Privacy	10	70%	6

Part 80 — Dashboard by Framework

ISO 27001
Coverage: 96%

SOC 2
Coverage: 94%

PCI DSS
Coverage: 91%

ISO 27017
Coverage: 89%

ISO 27018
Coverage: 84%

NIST CSF
Coverage: 95%

These percentages should represent clearly defined metrics rather than generic “compliance scores.”

Part 81 — Identify Concentration Risk

Suppose:

IAM-003

supports:

5 Frameworks

Failure of this control has:

High
Compliance
Impact

This is:

Control
Concentration
Risk

Part 82 — Identify High-Impact Controls

Rank controls by:

Risk Criticality

Framework Coverage

System Coverage

Business Criticality

Dependency Count

Part 83 — Common Controls Become Strategic

A strong control such as:

Centralized IAM

may support dozens of requirements.

Therefore:

Improving
One Control

can improve:

Multiple
Compliance Programs

Part 84 — Map Controls to Assets

Extend the matrix:

Control
      ↓
System
      ↓
Asset
      ↓
Business Service

Example:

IAM-003
      ↓
AWS

Azure

Microsoft 365

GitHub

ServiceNow

Part 85 — Scope Matters

A control can be effective for:

AWS

but ineffective for:

GitHub

Therefore do not record only:

IAM-003
Effective

Consider:

Control
+
Scope

Part 86 — Control Implementation Instances

One enterprise control may have multiple implementations.

Example:

IAM-003
MFA
   │
   ├── Microsoft Entra ID
   ├── AWS IAM Identity Center
   ├── GitHub
   └── ServiceNow

Part 87 — Implementation Register

Record:

Control

System

Implementation

Owner

Configuration

Evidence

Status

Part 88 — Common Control vs Local Control

Some controls are:

Enterprise
Common Controls

Others may be:

System-Specific
Controls

Example:

Enterprise:
Security Awareness

System-Specific:
PCI Payment Application
Input Validation

Part 89 — Inherited Controls

Systems may inherit controls from shared services.

Example:

Application
      ↓
Uses Enterprise
Identity Provider
      ↓
Inherits
Authentication
Controls

Part 90 — Build Inheritance Model

Record:

System

Inherited Control

Provider

Implementation

Evidence

Responsibility

Part 91 — Internal Shared Services

Common control providers may include:

Enterprise IAM

SOC

Network Security

Cloud Platform

HR

Security Awareness

Backup Platform

GRC

Part 92 — External Control Inheritance

Some controls may be provided by:

Cloud Provider

SaaS Provider

Data Center

Managed Security Provider

But responsibility must still be understood.

Part 93 — Integrate Third-Party Controls

Example:

Cloud Provider
Physical Security
      ↓
Provider Assurance
      ↓
CloudNova
Control Mapping

Part 94 — Evidence for Inherited Controls

Potential evidence:

SOC Report

ISO Certificate

Provider Documentation

Contract

Shared Responsibility Matrix

Internal Review

Part 95 — Map Controls to Policies

The mature model becomes:

Risk
      ↓
Policy
      ↓
Standard
      ↓
Control
      ↓
Procedure
      ↓
Technology
      ↓
Evidence
      ↓
Testing

Part 96 — Example

Risk:
Unauthorized Access

Policy:
Access Control Policy

Standard:
Authentication Standard

Control:
IAM-003 MFA

Technology:
Identity Platform

Evidence:
MFA Coverage Report

Testing:
Quarterly Control Test

Part 97 — Map Controls to Processes

Controls should connect to business processes such as:

Joiner

Mover

Leaver

Change Management

Incident Response

Vendor Onboarding

Cloud Onboarding

Vulnerability Management

Part 98 — Map Controls to Metrics

Every important control should have measurable indicators where useful.

Example:

IAM-003
MFA

KPI:
MFA Coverage

Target:
100%

KRI:
Privileged Accounts
Without MFA

Tolerance:
0

Part 99 — Control Health

Create:

Green
Effective

Amber
Partial / Exception

Red
Ineffective

Grey
Not Assessed

Part 100 — Avoid Manual Status Guessing

Where possible:

Control
      ↓
System Data
      ↓
Metric
      ↓
Health

Example:

MFA
      ↓
Identity API
      ↓
Coverage
      ↓
Control Status

Part 101 — Continuous Control Monitoring

Move from:

Annual
Control Test

toward:

Continuous
Control
Monitoring

where technically and operationally appropriate.

Part 102 — Example Continuous Control

Identity Platform
      ↓
Daily User Export
      ↓
MFA Coverage Check
      ↓
Exception Detected
      ↓
Ticket Created
      ↓
Remediation
      ↓
Evidence Stored

Part 103 — Evidence Automation

Potential sources:

Identity APIs

Cloud APIs

SIEM

Vulnerability Scanner

Ticketing

Configuration Platforms

Endpoint Management

CI/CD

HR Systems

Part 104 — GRC Platform Integration

Future-state architecture:

Enterprise Systems
       ↓
Automated Evidence
       ↓
GRC Platform
       ↓
Common Controls
       ↓
Framework Mapping
       ↓
Dashboards
       ↓
Assurance

Part 105 — Framework Change Management

Frameworks evolve.

Therefore mappings must be:

Versioned

When a framework changes:

New Requirement
      ↓
Impact Analysis
      ↓
Existing Control?
      ↓
Yes → Map

No → Gap
      ↓
New / Modified Control

Part 106 — Maintain Mapping History

Record:

Framework Version

Mapping Version

Change Date

Change

Reviewer

Approval

Part 107 — New Framework Onboarding

Suppose CloudNova later adopts:

HIPAA

DORA

NIS2

FedRAMP

CIS Controls

Do not rebuild the control environment.

Instead:

New Framework
      ↓
Requirement Inventory
      ↓
Map Existing Controls
      ↓
Identify Gaps
      ↓
Add Only
Necessary Controls

Part 108 — This Is the Scaling Benefit

Without common controls:

New Framework
      ↓
New Compliance
Program

With common controls:

New Framework
      ↓
Mapping Exercise
      +
Gap Analysis

Part 109 — Common Mistake: Framework-Centric Controls

Avoid:

ISO Control

SOC Control

PCI Control

Prefer:

Enterprise
Security Control

with framework mappings.

Part 110 — Common Mistake: Mapping by Similar Words

Two requirements containing:

Access Control

are not automatically equivalent.

Understand:

Intent

Scope

Frequency

Evidence

Implementation

Specific Conditions

Part 111 — Common Mistake: Mapping Everything to Everything

Weak mapping:

IAM Policy
      ↓
20 Requirements

without validating actual coverage.

Mapping must be defensible.

Part 112 — Common Mistake: Control Exists Therefore Requirement Met

A mapped control can still be:

Not Implemented

Partially Implemented

Ineffective

Out of Scope

Missing Evidence

Part 113 — Common Mistake: Duplicate Evidence

Avoid:

ISO Evidence Folder

SOC Evidence Folder

PCI Evidence Folder

containing copies of the same artifact.

Prefer:

Authoritative
Evidence Repository
      ↓
Framework
References

Part 114 — Common Mistake: No Ownership

A control without an owner becomes:

Everyone's
Responsibility

which often means:

Nobody's
Responsibility

Part 115 — Common Mistake: No Control Testing

Documentation alone does not demonstrate effectiveness.

Move through:

Control Defined
      ↓
Implemented
      ↓
Operating
      ↓
Tested
      ↓
Effective

Part 116 — Common Mistake: Compliance Percentage Without Context

Avoid:

94%
Compliant

without explaining what the number represents.

Instead report:

Requirement Coverage

Control Effectiveness

Evidence Readiness

Open Deficiencies

Critical Risks

Remediation Status

Part 117 — Common Control Framework Maturity

Level 1 — Fragmented

Framework-Specific
Controls

Level 2 — Mapped

Cross-Framework
Mapping

Level 3 — Common Controls

Enterprise
Control Library

Level 4 — Integrated Assurance

Common Evidence

Common Testing

Unified Reporting

Level 5 — Continuous Assurance

Automated Evidence
       ↓
Continuous Testing
       ↓
Control Health
       ↓
Framework Mapping
       ↓
Real-Time
Compliance Insight

Part 118 — Future-State CloudNova

Move from:

ISO Spreadsheet

SOC Spreadsheet

PCI Spreadsheet

Cloud Spreadsheet

Privacy Spreadsheet

to:

Enterprise
Risk Register
      ↓
Common Control
Framework
      ↓
Control Owners
      ↓
Evidence Repository
      ↓
Control Testing
      ↓
Framework Mapping
      ↓
Compliance Dashboard

Practical Assignment

Build CloudNova’s Enterprise Compliance Control Matrix.

Task 1 — Create Framework Inventory

Include at least:

ISO 27001

SOC 2

PCI DSS

ISO 27017

ISO 27018

NIST CSF

Task 2 — Build Requirement Inventory

Create normalized records containing:

Framework

Requirement

Domain

Scope

Applicability

Task 3 — Create Control Taxonomy

Create at least:

15 Control
Domains

Task 4 — Build Common Control Library

Create at least:

75 Enterprise
Controls

across:

Governance

Risk

IAM

Data

Network

Cloud

Applications

Vulnerability

Logging

Incident Response

BCM

Third Parties

Privacy

Audit

Compliance

Task 5 — Define Control Metadata

For every control document:

ID

Name

Objective

Description

Owner

Operator

Scope

Frequency

Type

Automation

Evidence

Task 6 — Map Risks to Controls

Map at least:

20 Enterprise
Risks

to applicable controls.

Task 7 — Map Policies to Controls

Connect controls to:

Policies

Standards

Procedures

Task 8 — Build Framework Mapping

Map the common controls to:

ISO 27001

SOC 2

PCI DSS

ISO 27017

ISO 27018

NIST CSF

using applicable official requirements.

Task 9 — Identify Mapping Strength

Classify mappings as:

Primary

Supporting

Partial

Task 10 — Build Evidence Matrix

Identify at least:

50 Evidence
Artifacts

and map them to enterprise controls.

Task 11 — Build Testing Procedures

Create reusable testing procedures for at least:

20 Key
Controls

Task 12 — Identify Dependencies

Identify at least:

15 Control
Dependencies

Task 13 — Identify Key Controls

Determine which controls have the greatest:

Risk Impact

Framework Impact

Business Impact

Task 14 — Identify Gaps

Identify:

Unmapped Requirements

Missing Controls

Weak Controls

Missing Evidence

Failed Controls

Task 15 — Create Dashboard

Report:

Framework Coverage

Control Effectiveness

Evidence Readiness

Control Deficiencies

Exceptions

Remediation

Final Validation Checklist

Frameworks

applicable frameworks identified.
framework versions recorded.
scopes defined.
owners assigned.
assessment requirements identified.

Requirements

requirements inventoried.
applicability determined.
internal summaries created.
mappings established.
unmapped requirements identified.

Controls

control taxonomy established.
control IDs standardized.
objectives defined.
descriptions defined.
owners assigned.
operators identified.
frequencies defined.
control types classified.
automation status recorded.

Risk Integration

risks mapped to controls.
key controls identified.
control dependencies identified.
concentration risks identified.

Framework Mapping

ISO 27001 mapped.
SOC 2 mapped.
PCI DSS mapped.
ISO 27017 mapped.
ISO 27018 mapped.
NIST CSF mapped.
mapping strengths identified.
partial coverage identified.

Evidence

evidence requirements identified.
evidence IDs assigned.
evidence owners assigned.
frequencies established.
authoritative sources identified.
duplicate evidence reduced.
evidence quality assessed.

Testing

testing procedures defined.
design effectiveness assessed.
operating effectiveness assessed.
exceptions recorded.
framework impacts identified.

Governance

framework change process defined.
control change process defined.
mapping reviews established.
exception management established.
remediation process established.

Continuous Compliance

control metrics defined.
control health model established.
automation opportunities identified.
continuous monitoring designed.
dashboard established.

Expected Project Folder

07 Build an Enterprise Compliance Control Matrix
│
├── 01 Framework Inventory
├── 02 Requirement Inventory
├── 03 Enterprise Control Taxonomy
├── 04 Common Control Library
├── 05 Risk-to-Control Matrix
├── 06 Policy-to-Control Matrix
├── 07 Framework-to-Control Matrix
├── 08 Control Ownership Register
├── 09 Evidence Mapping Matrix
├── 10 Control Testing Matrix
├── 11 Control Dependency Register
├── 12 Gap & Exception Register
├── 13 Compliance Coverage Matrix
├── 14 Enterprise Compliance Dashboard
├── 15 Control Framework Governance Standard
└── 16 Continuous Compliance Plan

Success Criteria

You successfully complete this project when you can move from:

Enterprise Risk
      ↓
Policy
      ↓
Common Control
      ↓
Implementation
      ↓
Evidence
      ↓
Testing
      ↓
Framework Mapping
      ↓
ISO 27001
SOC 2
PCI DSS
ISO 27017
ISO 27018
NIST CSF
      ↓
Gap
      ↓
Remediation
      ↓
Continuous
Assurance

and confidently answer:

Which Frameworks
Apply?

Which Requirements
Apply?

Which Enterprise
Controls Address Them?

Which Risks
Do Those Controls
Mitigate?

Who Owns
Each Control?

Where Is
the Control
Implemented?

What Evidence
Proves It?

How Is
the Control Tested?

Which Frameworks
Depend on It?

Where Are
the Coverage Gaps?

Which Controls
Are Ineffective?

What Must
Be Remediated?

Can One Evidence
Artifact Support
Multiple Frameworks?

Career Connection

This project reflects work performed by:

GRC Analysts

Compliance Analysts

GRC Architects

Compliance Architects

Internal Auditors

Security Assurance
Professionals

Risk Managers

Control Owners

GRC Consultants

A beginner often sees compliance as:

Framework
      ↓
Requirements
      ↓
Checklist

A professional sees:

Enterprise Risk
      ↓
Common Controls
      ↓
Evidence
      ↓
Testing
      ↓
Multiple Frameworks

And a mature organization moves toward:

One Risk Model

One Control Library

One Evidence Model

One Testing Model

Many Frameworks

The key principle is:

Do Not Build
Compliance
Framework by Framework.

Build Strong
Enterprise Controls

Then Map
Frameworks
to Them.

What’s Next?

➡️ Next: 08 — Build an Enterprise GRC Dashboard

You now have:

Enterprise Risks
      ↓
ISMS
      ↓
Framework Assessments
      ↓
Common Controls
      ↓
Evidence
      ↓
Testing
      ↓
Compliance Mapping

The next challenge is:

How Do We
Turn All This
GRC Data
Into Decisions?

In the next project, you will bring together:

Enterprise Risk

Compliance

Controls

Audit Findings

Exceptions

Third-Party Risk

Remediation

KRIs

KPIs

into a unified:

Enterprise
GRC Dashboard

You will learn how to transform hundreds of GRC records into:

Executive
Risk Visibility
      ↓
Control Health
      ↓
Compliance Posture
      ↓
Remediation Status
      ↓
Management Decisions

➡️ Next: 08 — Build an Enterprise GRC Dashboard