Lab 01 — Framework Mapping Exercise

Mission Information

Lab Type: Governance, Risk & Compliance
Difficulty: Intermediate
Estimated Time: 90–120 minutes
Primary Role: GRC Analyst / Cyber Risk Analyst
Environment: Spreadsheet, GRC platform, or documentation workspace
Prerequisite: Module 10 — Enterprise Compliance Frameworks Overview

Mission

You have joined the GRC team of a growing cloud technology company.

The organization currently manages several cybersecurity and compliance requirements independently.

Different teams maintain separate controls for:

ISO 27001

NIST CSF

CIS Controls

SOC 2

PCI DSS

NIS2

This has created:

Duplicate Controls

Duplicate Evidence

Repeated Assessments

Conflicting Ownership

Audit Fatigue

Poor Compliance Visibility

Management wants the GRC team to begin creating a:

Common Control Framework

Your assignment is to analyze requirements from several frameworks, identify overlap, normalize the requirements, create enterprise controls, assign control owners, and determine what evidence can be reused.

By the end of the lab, you will transform:

Multiple Frameworks
        ↓
Hundreds of Requirements
        ↓
Normalized Requirements
        ↓
Common Enterprise Controls
        ↓
Shared Evidence

Lab Objectives

By completing this lab, you will learn how to:

identify framework requirements.
analyze requirement intent.
distinguish similar and unique requirements.
normalize framework terminology.
map overlapping requirements.
avoid incorrect over-mapping.
design common enterprise controls.
create standardized control IDs.
define control objectives.
write strong control statements.
identify control owners.
identify control operators.
determine control frequency.
map evidence to controls.
reuse evidence across frameworks.
identify compliance gaps.
build a framework mapping matrix.
create the foundation of a Common Control Framework.

Scenario

You work for:

CloudNova Technologies

CloudNova is a fictional SaaS organization providing cloud-based enterprise applications.

The organization operates in:

India

United States

European Union

Customers include:

Financial Services

Retail

Technology Companies

The organization:

Hosts Customer Data

Processes Personal Data

Uses Public Cloud

Operates Production SaaS

Uses Third-Party Vendors

Employs Remote Workers

Management is evaluating several compliance requirements.

The GRC team currently tracks:

ISO 27001

NIST CSF

CIS Controls

SOC 2

PCI DSS

NIS2

Not every framework necessarily applies to every system or legal entity.

Part of your responsibility is to preserve:

Applicability

while creating reusable enterprise controls.

Current Problem

Different compliance teams created controls independently.

For example:

ISO Team

"Administrative access
must use MFA."

PCI Team

"MFA must protect
administrative access."

SOC 2 Team

"Privileged users
must authenticate using
multiple factors."

The company currently treats these as:

Three Controls

even though they may represent essentially the same enterprise security activity.

This results in:

Three Control Records

Three Evidence Requests

Three Testing Activities

Three Audit Responses

Your goal is to determine whether they can map to:

One Enterprise Control

Target Architecture

You are trying to build:

ISO 27001 ───────┐

NIST CSF ────────┤

CIS Controls ────┤

SOC 2 ───────────┼──→ Enterprise Controls
                 │
PCI DSS ─────────┤

NIS2 ────────────┘

followed by:

Enterprise Control
        ↓
Control Owner
        ↓
Implementation
        ↓
Evidence
        ↓
Testing
        ↓
Multiple Frameworks

Lab Deliverables

By the end of this lab, create:

01 Framework Inventory

02 Requirement Inventory

03 Requirement Normalization Matrix

04 Framework Mapping Matrix

05 Common Control Set

06 Control Ownership Matrix

07 Evidence Mapping Matrix

08 Gap Register

09 Framework Mapping Summary

Part 1 — Build the Framework Inventory

Create a table containing:

Framework	Primary Purpose	Applicability	Mandatory?	Owner
ISO 27001	Information Security Management	TBD	TBD	GRC
NIST CSF	Cybersecurity Risk Management	TBD	Generally Voluntary	Security/GRC
CIS Controls	Security Safeguards	TBD	Generally Voluntary	Security
SOC 2	Service Organization Assurance	Customer Driven	Contractual/Market	GRC
PCI DSS	Payment Card Security	If Applicable	Industry/Contractual	Compliance
NIS2	EU Cybersecurity Requirements	If Applicable	Regulatory	Legal/GRC

Do not assume every framework applies simply because it appears in the lab.

Document:

Why could it apply?

Which business activity triggers it?

Which entity could be affected?

Which systems could be in scope?

Who should validate applicability?

Part 2 — Create the Requirement Inventory

For this exercise, use the following simplified requirements.

These are training statements designed for mapping practice rather than verbatim framework language.

Identity & Access Management

Requirement A

Framework:
ISO 27001

Requirement:
Access to information
and systems must be
appropriately controlled.

Requirement B

Framework:
NIST CSF

Requirement:
Access permissions and
authorizations should
be managed.

Requirement C

Framework:
CIS Controls

Requirement:
Access privileges should
be managed according to
enterprise requirements.

Requirement D

Framework:
PCI DSS

Requirement:
Access to systems and
cardholder data must be
restricted according to
business need.

Requirement E

Framework:
NIS2

Requirement:
Organizations should
implement appropriate
access-control measures.

Part 3 — Analyze Requirement Intent

Do not immediately map requirements because they contain similar words.

For every requirement determine:

What is being protected?

Who is affected?

What activity is required?

What is the expected outcome?

What scope applies?

How frequently must it occur?

What evidence could prove it?

Create:

Requirement	Intent	Scope	Activity	Evidence
ISO IAM	Control access	Information Systems	Access Governance	Access Policy
NIST IAM	Manage authorization	Systems	Permission Management	IAM Configuration
CIS IAM	Manage privileges	Enterprise Assets	Privilege Management	Access Report
PCI IAM	Restrict access	PCI Scope	Need-to-Know	Access Listing
NIS2 IAM	Appropriate access control	In-Scope Services	Access Control	IAM Evidence

Part 4 — Normalize the Requirements

The frameworks use different terminology.

For example:

Access Permissions

Authorization

Privileges

Need-to-Know

Access Control

may represent related security objectives.

Normalize these into a common concept:

Identity & Access
Management

Then identify specific control objectives.

Example:

IAM-001
Access Authorization

IAM-002
Least Privilege

IAM-003
Privileged Access

IAM-004
Access Review

IAM-005
Multi-Factor Authentication

Part 5 — Do Not Over-Merge

Suppose you have:

Requirement A

Restrict privileged access.

and:

Requirement B

Review privileged access
every quarter.

These are related.

But they are not necessarily the same control.

You may need:

IAM-003
Privileged Access Restriction

and:

IAM-004
Privileged Access Review

because:

Different Activity

Different Frequency

Different Evidence

exists.

Mapping Rule

Use:

Same Objective
+
Same Activity
+
Compatible Scope
+
Compatible Evidence
=
Potential Common Control

But:

Similar Words
≠
Same Control

Part 6 — Create the First Enterprise Control

Create:

Control ID:
IAM-001

Control Name

Access Authorization

Control Objective

Ensure access to enterprise systems and information is granted only to authorized users according to approved business requirements.

Control Statement

Access to enterprise
systems, applications,
data, and infrastructure
must be authorized based
on approved business need,
role responsibilities,
and least-privilege
principles.

Control Owner

Head of Identity &
Access Management

Control Operators

Possible operators:

IAM Team

Application Owners

Cloud Administrators

Service Desk

Frequency

Continuous

for access enforcement.

Supporting activities may occur:

On Request

On Role Change

Quarterly

On Termination

depending on the activity.

Part 7 — Map the Control

Create:

Enterprise Control	ISO 27001	NIST CSF	CIS Controls	SOC 2	PCI DSS	NIS2
IAM-001 Access Authorization	✓	✓	✓	✓	✓	✓

But do not stop here.

Document the actual:

Requirement Reference

for every framework when building a production mapping library.

Your production matrix should therefore contain:

Control	Framework	Requirement Reference	Mapping Type
IAM-001	ISO 27001	Reference	Full/Partial
IAM-001	NIST CSF	Reference	Full/Partial
IAM-001	CIS	Reference	Full/Partial
IAM-001	PCI DSS	Reference	Full/Partial
IAM-001	NIS2	Reference	Full/Partial

Part 8 — Introduce Mapping Strength

Not every mapping is equal.

Use:

Full

Partial

Supporting

Not Applicable

Full

The enterprise control substantially satisfies the mapped requirement.

Partial

The control satisfies only part of the requirement.

Supporting

The control contributes to the requirement but does not independently satisfy it.

Not Applicable

The mapping does not apply within the relevant scope.

This prevents:

False Compliance

from overly aggressive mappings.

Part 9 — Map MFA Requirements

Analyze:

ISO 27001
Authentication controls
should protect access.

NIST CSF
Authentication mechanisms
should be managed according
to organizational risk.

PCI DSS
MFA is required for
specified access scenarios.

NIS2
MFA should be used
where appropriate.

Normalize:

Multi-Factor
Authentication

Create:

Control ID:
IAM-005

Control:

Multi-Factor
Authentication

Control statement:

Approved multi-factor
authentication must be
implemented for privileged,
remote, and other
risk-defined access
scenarios according to
enterprise and applicable
regulatory requirements.

Part 10 — Identify Framework-Specific Differences

Do not assume:

IAM-005

automatically satisfies every MFA requirement.

Check:

Which Users?

Which Systems?

Which Access Paths?

Which Authentication Factors?

Which Exceptions?

Which Scope?

You may need:

Enterprise Baseline
        +
PCI Overlay
        +
Regulatory Overlay

Part 11 — Build the IAM Mapping Matrix

Create:

Control	ISO	NIST	CIS	SOC 2	PCI	NIS2
IAM-001 Access Authorization	✓	✓	✓	✓	✓	✓
IAM-002 Least Privilege	✓	✓	✓	✓	✓	✓
IAM-003 Privileged Access	✓	✓	✓	✓	✓	✓
IAM-004 Access Review	✓	✓	✓	✓	✓	✓
IAM-005 MFA	✓	✓	✓	✓	✓	✓

These are conceptual mappings for the exercise.

Production mappings must be validated against the actual framework requirements.

Part 12 — Add Vulnerability Management

Analyze the following training requirements:

Framework A:
Identify vulnerabilities.

Framework B:
Prioritize vulnerabilities
according to risk.

Framework C:
Remediate critical
vulnerabilities.

Framework D:
Verify remediation.

Do not create:

One Giant
Vulnerability Control

Instead consider:

VUL-001
Vulnerability Identification

VUL-002
Vulnerability Risk Assessment

VUL-003
Vulnerability Remediation

VUL-004
Remediation Validation

Part 13 — Write the Controls

VUL-001 — Vulnerability Identification

Enterprise systems and
applications must be
periodically assessed
for known security
vulnerabilities using
approved methods and
tools.

VUL-002 — Vulnerability Risk Assessment

Identified vulnerabilities
must be prioritized using
technical severity,
exploitability, asset
criticality, exposure,
threat intelligence, and
business impact.

VUL-003 — Vulnerability Remediation

Security vulnerabilities
must be remediated within
approved risk-based
remediation timelines.

VUL-004 — Remediation Validation

Remediated vulnerabilities
must be validated to
confirm that corrective
actions were successfully
implemented.

Part 14 — Add Logging & Monitoring

Training requirements:

Security events
must be logged.

Logs must be
protected.

Security events
must be monitored.

Suspicious events
must be investigated.

Normalize into:

LOG-001
Security Logging

LOG-002
Log Protection

LOG-003
Security Monitoring

LOG-004
Security Event Investigation

Part 15 — Add Incident Response

Training requirements:

Incidents must
be detected.

Incidents must
be classified.

Incidents must
be contained.

Incidents must
be reported.

Lessons learned
must be performed.

Create:

IR-001
Incident Detection

IR-002
Incident Classification

IR-003
Incident Response

IR-004
Regulatory Notification

IR-005
Post-Incident Review

Part 16 — Be Careful With IR-004

Regulatory reporting requirements may look similar while containing very different:

Thresholds

Authorities

Timelines

Required Information

Approval Processes

Therefore use:

IR-004
Regulatory Notification

as the enterprise process.

Then add:

NIS2 Reporting Overlay

Privacy Breach Overlay

PCI Reporting Overlay

Contractual Notification Overlay

where applicable.

Part 17 — Add Business Continuity Controls

Normalize requirements into:

BCM-001
Business Impact Analysis

BCM-002
Business Continuity Planning

BCM-003
Backup Management

BCM-004
Disaster Recovery

BCM-005
Recovery Testing

Part 18 — Add Third-Party Risk Controls

Normalize:

TPRM-001
Supplier Inventory

TPRM-002
Supplier Criticality

TPRM-003
Security Due Diligence

TPRM-004
Contract Security

TPRM-005
Supplier Monitoring

TPRM-006
Supplier Reassessment

TPRM-007
Supplier Termination

Part 19 — Build Your Common Control Set

Your initial CCF now contains:

IAM

VUL

LOG

IR

BCM

TPRM

Example:

IAM-001
Access Authorization

IAM-002
Least Privilege

IAM-003
Privileged Access

IAM-004
Access Review

IAM-005
MFA

VUL-001
Vulnerability Identification

VUL-002
Vulnerability Risk Assessment

VUL-003
Vulnerability Remediation

VUL-004
Remediation Validation

LOG-001
Security Logging

LOG-002
Log Protection

LOG-003
Security Monitoring

LOG-004
Security Event Investigation

IR-001
Incident Detection

IR-002
Incident Classification

IR-003
Incident Response

IR-004
Regulatory Notification

IR-005
Post-Incident Review

BCM-001
Business Impact Analysis

BCM-002
Business Continuity Planning

BCM-003
Backup Management

BCM-004
Disaster Recovery

BCM-005
Recovery Testing

TPRM-001
Supplier Inventory

TPRM-002
Supplier Criticality

TPRM-003
Security Due Diligence

TPRM-004
Contract Security

TPRM-005
Supplier Monitoring

TPRM-006
Supplier Reassessment

TPRM-007
Supplier Termination

Part 20 — Build the Control Library

Create the following columns:

Field	Purpose
Control ID	Unique identifier
Domain	Control family
Control Name	Short name
Objective	Why control exists
Control Statement	Required activity
Owner	Accountable party
Operator	Performing party
Frequency	How often
Scope	Systems/entities
Evidence	Proof
Test Method	Assurance method
Status	Control health

Part 21 — Assign Control Owners

Example:

Domain	Control Owner
IAM	Identity & Access Management
Vulnerability	Security Operations
Logging	Security Operations
Incident Response	SOC / CSIRT
Business Continuity	Business Continuity
Third-Party Risk	Vendor Risk Management

Avoid:

Owner:
GRC

for every control.

GRC generally provides:

Governance

Framework

Oversight

Challenge

Monitoring

while operational teams execute controls.

Part 22 — Create the RACI

Example:

Activity	GRC	IAM	Security	Business	Audit
Define Control	A/R	C	C	C	I
Operate IAM Control	I	A/R	C	I	I
Collect Evidence	C	R	R	I	I
Test Control	C	I	I	I	A/R
Remediate Finding	C	A/R	R	C	I

Adapt the RACI to the organization’s governance model.

Part 23 — Build the Evidence Matrix

For:

IAM-005
Multi-Factor Authentication

identify:

Policy

IAM Configuration

MFA Configuration Export

Administrator Listing

MFA Coverage Report

Exception Register

Then create:

Evidence	Control	ISO	NIST	PCI	SOC 2	NIS2
MFA Policy	IAM-005	✓	✓	✓	✓	✓
MFA Config	IAM-005	✓	✓	✓	✓	✓
Admin List	IAM-005	✓	✓	✓	✓	✓
Coverage Report	IAM-005	✓	✓	✓	✓	✓

Part 24 — Evidence Reuse

The target is:

Control
      ↓
Evidence
      ↓
Multiple Requirements

not:

ISO Evidence

PCI Evidence

SOC Evidence

NIS2 Evidence

when the same evidence genuinely proves the same control.

Part 25 — Validate Evidence Quality

Ask:

Is It Complete?

Is It Current?

Is It Authentic?

Does It Cover
the Correct Scope?

Does It Cover
the Correct Period?

Does It Actually
Prove the Control?

Part 26 — Evidence Freshness

Add:

Evidence Date

Valid From

Valid Until

Collection Frequency

Example:

Evidence:
Privileged MFA Report

Frequency:
Monthly

Owner:
IAM Team

Retention:
Defined by Policy

Part 27 — Test a Control

Test:

IAM-005
Multi-Factor Authentication

Population:

100 Privileged Accounts

Expected:

100 MFA Enabled

Actual:

97 MFA Enabled

Exceptions:

3 Accounts

Result:

Control Exception

Part 28 — Calculate Coverage

97 / 100 × 100
=
97%

But do not conclude:

97%
=
Good

The three accounts could be:

Domain Administrator

Cloud Root Account

Security Administrator

Risk matters.

Part 29 — Create a Finding

Finding ID:
FND-001

Control:
IAM-005

Finding:
Three privileged accounts
do not have MFA enabled.

Risk:
Unauthorized privileged
access could result in
significant compromise.

Severity:
Critical

Owner:
IAM Manager

Part 30 — Create Remediation

Action:

Enable approved MFA
for all affected
privileged accounts.

Also determine:

Why Did the
Control Fail?

Potential causes:

Legacy System

Technical Limitation

Process Failure

Unauthorized Exception

Configuration Error

Part 31 — Gap Register

Create:

Gap ID	Control	Gap	Risk	Severity	Owner	Due Date	Status
GAP-001	IAM-005	3 admins without MFA	Account compromise	Critical	IAM	TBD	Open

Part 32 — Retest

After remediation:

Population:
100

MFA Enabled:
100

Exceptions:
0

Result:

Effective

Retain:

Original Finding

Remediation Evidence

Retest Evidence

Closure Approval

Part 33 — Build the Master Mapping Matrix

Your final structure should resemble:

Control ID	Control	ISO	NIST	CIS	SOC 2	PCI	NIS2
IAM-001	Access Authorization	✓	✓	✓	✓	✓	✓
IAM-002	Least Privilege	✓	✓	✓	✓	✓	✓
IAM-003	Privileged Access	✓	✓	✓	✓	✓	✓
IAM-004	Access Review	✓	✓	✓	✓	✓	✓
IAM-005	MFA	✓	✓	✓	✓	✓	✓
VUL-001	Vulnerability Identification	✓	✓	✓	✓	✓	✓
VUL-002	Risk Prioritization	✓	✓	✓	✓	✓	✓
VUL-003	Remediation	✓	✓	✓	✓	✓	✓
LOG-001	Security Logging	✓	✓	✓	✓	✓	✓
LOG-003	Security Monitoring	✓	✓	✓	✓	✓	✓
IR-003	Incident Response	✓	✓	✓	✓	✓	✓
BCM-003	Backup Management	✓	✓	✓	✓	✓	✓
TPRM-003	Vendor Assessment	✓	✓	✓	✓	✓	✓

The checkmarks above are intentionally simplified for the exercise.

A production mapping must contain validated framework references and mapping strength.

Part 34 — Upgrade the Matrix

Add:

Framework Version

Requirement ID

Requirement Text

Enterprise Control

Mapping Strength

Applicability

Scope

Owner

Evidence

Validation Date

Validated By

This turns a simple spreadsheet into:

GRC Traceability
Architecture

Part 35 — Trace One Requirement End-to-End

Select:

Privileged MFA

Trace:

External Requirement
        ↓
Normalized Requirement
        ↓
IAM-005
        ↓
IAM Standard
        ↓
IAM Procedure
        ↓
Identity Platform
        ↓
MFA Configuration
        ↓
Evidence
        ↓
Control Test
        ↓
Finding
        ↓
Remediation

You should be able to move in both directions.

Part 36 — Reverse Traceability

An auditor asks:

Show Me How
This NIS2 Requirement
Is Implemented.

You should trace:

NIS2 Requirement
      ↓
IAM-005
      ↓
IAM Standard
      ↓
Implementation
      ↓
Evidence
      ↓
Test Result

Part 37 — Forward Traceability

Management asks:

What Happens
If IAM-005 Fails?

You should identify:

Affected Risks

Affected Systems

Affected Frameworks

Affected Audits

Affected Customers

Affected Regulations

Part 38 — Analyze Shared Control Impact

Suppose:

IAM-005

fails.

Because it supports:

ISO

NIST

CIS

SOC 2

PCI DSS

NIS2

one control failure may create:

Multiple
Compliance Impacts

This is why Common Control Frameworks improve visibility.

Part 39 — Identify Control Dependencies

Example:

IAM-005 MFA

depends on:

IAM-001
Account Governance

IAM-003
Privileged Access

AST-001
Asset Inventory

HR-001
Joiner/Mover/Leaver

Controls do not operate independently.

Part 40 — Build the Final Architecture

Your finished model should look like:

Business Requirements
        ↓
Regulations
Standards
Contracts
Frameworks
        ↓
Requirement Library
        ↓
Normalization
        ↓
Common Control Framework
        ↓
Policies & Standards
        ↓
Control Owners
        ↓
Control Operation
        ↓
Evidence
        ↓
Testing
        ↓
Findings
        ↓
Remediation
        ↓
Continuous Monitoring

Challenge Exercise

Management introduces another framework.

You are told:

"We Now Need
Another Security
Framework."

Do not immediately create:

Another Control Set

Instead:

Import Requirements
        ↓
Analyze
        ↓
Normalize
        ↓
Map Existing Controls
        ↓
Identify True Gaps
        ↓
Create Only
Necessary Controls

Challenge Question

The new framework contains:

100 Requirements

After mapping:

are fully addressed by existing enterprise controls.

are partially addressed.

are not addressed.

What should the GRC team do?

The correct approach is not:

Create 100
New Controls

Instead:

Validate 82 Mappings

Assess 11 Partial Mappings

Remediate 7 True Gaps

Lab Validation Checklist

Framework Inventory

frameworks identified.
purpose documented.
applicability considered.
mandatory/voluntary status identified.
framework versions recorded.

Requirements

requirements collected.
requirement references retained.
requirements analyzed.
scope identified.
requirement intent documented.

Normalization

common concepts identified.
terminology normalized.
duplicate requirements identified.
unique requirements preserved.
over-mapping avoided.

Controls

control domains established.
control IDs created.
objectives defined.
control statements written.
owners assigned.
operators identified.
frequencies documented.

Mapping

framework requirements mapped.
mapping strength recorded.
partial mappings identified.
unique requirements retained.
mappings validated.

Evidence

evidence requirements identified.
evidence owners assigned.
evidence reused where appropriate.
evidence freshness considered.
evidence quality validated.

Assurance

controls tested.
exceptions identified.
findings documented.
remediation assigned.
controls retested.

Expected Deliverables

At completion, your lab folder should contain:

Lab 01 Framework Mapping Exercise
│
├── 01 Framework Inventory
│
├── 02 Requirement Inventory
│
├── 03 Requirement Normalization Matrix
│
├── 04 Framework Mapping Matrix
│
├── 05 Common Control Library
│
├── 06 Control Ownership Matrix
│
├── 07 Evidence Mapping Matrix
│
├── 08 Gap Register
│
└── 09 Framework Mapping Summary

Success Criteria

You have successfully completed the lab when you can demonstrate:

Framework Requirement
        ↓
Normalized Requirement
        ↓
Enterprise Control
        ↓
Control Owner
        ↓
Implementation
        ↓
Evidence
        ↓
Testing

and explain why:

One Enterprise Control

can potentially satisfy:

Multiple Framework
Requirements

without assuming that every requirement is identical.

Student Reflection

Before completing the lab, answer:

Why should organizations avoid separate control libraries for every framework?
What is requirement normalization?
What is the difference between a requirement and a control?
What makes two requirements suitable for common-control mapping?
What is over-mapping?
Why should unique requirements be preserved?
What is a Common Control Framework?
Why are standardized control IDs useful?
What is the difference between a control owner and operator?
Why should evidence map primarily to controls?
How does evidence reuse reduce audit fatigue?
What makes evidence reliable?
Why should evidence freshness be tracked?
What is mapping strength?
What is a partial mapping?
Why should framework versions be recorded?
What happens when a shared control fails?
Why should control failures be evaluated according to risk?
What is reverse traceability?
How does a Common Control Framework support continuous compliance?

Career Connection

This exercise reflects real work performed by:

GRC Analyst

Cyber Risk Analyst

Compliance Analyst

Security Governance Analyst

GRC Consultant

IT Risk Consultant

Compliance Manager

GRC Architect

In enterprise environments, you may receive:

Thousands of
Requirements

from:

Regulators

Standards

Contracts

Customers

Internal Policies

Your job is not simply to copy them into a spreadsheet.

Your job is to transform them into:

Understandable

Owned

Implementable

Testable

Traceable

Reusable

enterprise controls.

That is the difference between:

Compliance Administration

and:

Enterprise GRC
Engineering

What’s Next?

➡️ Next: Lab 02 — Build an Enterprise Common Control Framework

In this lab, you mapped requirements from multiple frameworks into common controls.

Next, you will expand those controls into a structured enterprise-wide:

Common Control Framework

You will design:

Control Domains
      ↓
Control Objectives
      ↓
Enterprise Controls
      ↓
Control Owners
      ↓
Control Operators
      ↓
Control Frequencies
      ↓
Evidence Requirements
      ↓
Testing Procedures

You will move from:

Framework Mapping

to:

Enterprise Control
Architecture

and build a reusable control library that can support:

ISO 27001

NIST

SOC 2

PCI DSS

Cloud Security

Privacy

Business Continuity

Third-Party Risk

Regulatory Compliance

➡️ Next: Lab 02 — Build an Enterprise Common Control Framework