10 Compliance Management

Organizations operate within a complex environment of laws, regulations, industry standards, contractual commitments, customer expectations, and internal policies.

Examples may include:

Data protection laws.
Financial regulations.
Cybersecurity regulations.
Industry standards.
Customer security requirements.
Cloud security requirements.
Internal corporate policies.

Managing these requirements consistently is known as compliance management.

Compliance is not simply about passing an audit.

A mature compliance program continuously answers several important questions:

What requirements apply to us?
        ↓
Why do they apply?
        ↓
Which systems and processes are affected?
        ↓
Which controls satisfy the requirements?
        ↓
Who owns those controls?
        ↓
What evidence demonstrates compliance?
        ↓
Are the controls operating?
        ↓
Are there gaps?
        ↓
How are gaps being remediated?

For GRC professionals, compliance management connects external obligations with internal governance and security controls.

Learning Objectives

By the end of this lesson, you will be able to:

Explain enterprise compliance management.
Identify different sources of compliance obligations.
Understand regulatory applicability.
Build a compliance obligations register.
Translate requirements into internal controls.
Map requirements to policies and controls.
Understand compliance ownership.
Differentiate compliance from security.
Understand compliance assessments.
Manage compliance evidence.
Identify and document compliance gaps.
Manage compliance exceptions.
Track regulatory changes.
Understand compliance attestations.
Build compliance dashboards.
Understand continuous compliance monitoring.
Reduce duplicated compliance effort through common controls.
Understand the compliance management lifecycle.

1. What Is Compliance?

Compliance means meeting applicable requirements.

Those requirements may originate from:

Laws

Regulations

Industry Standards

Contracts

Customer Agreements

Corporate Policies

Security Frameworks

Certification Requirements

For example, an organization processing payment-card information may have specific security obligations.

An organization processing personal information may have privacy obligations.

A cloud service provider may also have contractual security obligations toward customers.

2. What Is Compliance Management?

Compliance management is the structured process of:

Identify Requirements
        ↓
Determine Applicability
        ↓
Interpret Obligations
        ↓
Assign Ownership
        ↓
Implement Controls
        ↓
Collect Evidence
        ↓
Assess Compliance
        ↓
Identify Gaps
        ↓
Remediate
        ↓
Monitor Changes

It is an ongoing governance process.

3. Compliance Is Not a One-Time Project

A common mistake is treating compliance as:

Prepare for Audit
      ↓
Pass Audit
      ↓
Forget Until Next Year

A mature model is:

Requirements
      ↓
Controls
      ↓
Continuous Operation
      ↓
Monitoring
      ↓
Assessment
      ↓
Improvement

Compliance should become part of normal business operations.

4. Sources of Compliance Requirements

Organizations may face requirements from many sources.

Laws

Requirements established through legislation.

Examples may include privacy, financial, employment, and cybersecurity laws.

Regulations

Detailed requirements issued by regulatory authorities.

Standards

Examples include:

ISO/IEC 27001.
PCI DSS.
Industry-specific security standards.

Contracts

Customer and supplier contracts may require:

Encryption.
Incident notification.
Audit rights.
Security assessments.
Data retention.
Business continuity.

Internal Requirements

Organizations may establish stricter internal requirements through:

Policies.
Standards.
Procedures.
Risk decisions.

5. Mandatory vs Voluntary Requirements

Not every framework is legally mandatory.

Requirements may be:

Mandatory
   │
   ├── Law
   ├── Regulation
   └── Contract

or:

Voluntary
   │
   ├── Certification
   ├── Industry Framework
   └── Best Practice

However, a voluntary framework can become effectively mandatory through a contract or customer requirement.

6. Applicability

One of the first compliance questions is:

Does this requirement apply to our organization?

Applicability may depend on:

Geography.
Industry.
Type of data.
Customer type.
Organization size.
Business activity.
Technology.
Contractual commitments.

GRC professionals should never assume that every regulation applies everywhere.

7. Applicability Example

Suppose a company:

Operates in multiple countries

Processes customer personal data

Accepts payment cards

Provides cloud services

Its compliance environment may include obligations related to:

Privacy

Payment Security

Cybersecurity

Customer Contracts

Cloud Security

Data Retention

Each obligation should be evaluated separately.

8. Compliance Obligations Register

Organizations should maintain a centralized record of applicable obligations.

Example:

ID	Requirement	Source	Owner	Applicability
OBL-001	Protect personal data	Privacy Law	Privacy	Applicable
OBL-002	Secure cardholder data	PCI DSS	Security	Applicable
OBL-003	Annual vendor review	Contract	Procurement	Applicable
OBL-004	Security training	Policy	HR/Security	Applicable

This becomes the compliance obligations register.

9. Why an Obligations Register Matters

Without a centralized register, organizations may struggle to answer:

Which requirements apply?

Who owns them?

Which controls satisfy them?

When were they last assessed?

What evidence exists?

Are there open gaps?

The obligations register creates visibility.

10. Obligation Ownership

Every important obligation should have an accountable owner.

Examples:

Privacy Requirement
→ Privacy / Legal

Payment Security
→ Security / Payments

Financial Control
→ Finance

Employee Requirement
→ HR

Vendor Requirement
→ Procurement

Cloud Security
→ Cloud Security

GRC often coordinates these owners.

11. Requirement Interpretation

External requirements may use broad language.

Example:

Organizations must implement appropriate security measures.

This must be translated into operational expectations.

Possible controls include:

Access Control

Encryption

Logging

Vulnerability Management

Incident Response

Security Monitoring

Compliance therefore requires interpretation.

12. Requirement Decomposition

Complex requirements may need to be broken into smaller obligations.

Example:

Requirement:

Protect sensitive information.

Decompose into:

Identify Sensitive Data

Classify Data

Restrict Access

Encrypt Data

Monitor Access

Retain Data Appropriately

Securely Destroy Data

Each can then map to specific controls.

13. Requirements to Controls

The basic relationship is:

External Requirement
        ↓
Internal Policy
        ↓
Control Objective
        ↓
Enterprise Control
        ↓
Implementation
        ↓
Evidence

This creates compliance traceability.

14. Compliance Mapping

Suppose several frameworks require access controls.

Instead of creating separate controls:

ISO Access Control

SOC 2 Access Control

PCI Access Control

NIST Access Control

the organization may create:

IAM-001
Access Authorization

and map multiple requirements to it.

15. Common Control Framework

This approach creates a common control framework.

Requirement A ─┐
Requirement B ─┤
Requirement C ─┼── Enterprise Control
Requirement D ─┤
Requirement E ─┘

One well-designed control may satisfy multiple obligations.

16. Example — MFA Mapping

Enterprise control:

IAM-002

Privileged accounts require MFA.

Potential mappings:

ISO/IEC 27001
        │
SOC 2
        │
PCI DSS
        │
NIST
        │
CIS Controls
        ↓
IAM-002

This significantly reduces duplicated compliance effort.

17. Compliance Matrix

Organizations may maintain a mapping matrix.

Requirement	Policy	Control	Evidence	Owner
Access restriction	Access Policy	IAM-001	Approval records	IAM
MFA	Access Standard	IAM-002	MFA report	IAM
Logging	Logging Policy	LOG-001	SIEM logs	SOC
Vulnerability scanning	VM Policy	VUL-001	Scan report	Security

This provides end-to-end traceability.

18. Compliance vs Security

Compliance and security overlap, but they are not identical.

Compliance asks:

Are we meeting applicable requirements?

Security asks:

Are we appropriately protecting the organization from threats and risk?

An organization can technically satisfy a compliance requirement while still having significant security risk.

19. Checkbox Compliance

A weak approach focuses only on proving requirements were met.

Example:

Requirement:
Security awareness training annually

Organization:
Training completed

Result:
Compliant

But employees may still be highly susceptible to phishing.

Compliance alone does not guarantee security effectiveness.

20. Risk-Based Compliance

A mature approach considers both:

Compliance Requirement
        +
Business Risk
        =
Appropriate Control

The organization may implement controls stronger than minimum compliance requirements.

21. Compliance Management Lifecycle

A mature lifecycle can be represented as:

Identify
   ↓
Interpret
   ↓
Map
   ↓
Implement
   ↓
Assess
   ↓
Monitor
   ↓
Remediate
   ↓
Report
   ↓
Improve

This cycle continuously repeats.

22. Step 1 — Identify Requirements

Sources may include:

Legal teams.
Regulators.
Industry bodies.
Customer contracts.
Procurement.
Security frameworks.
Certification programs.

Organizations should maintain an authoritative inventory.

23. Step 2 — Determine Applicability

For each requirement, document:

Applicable?

Why?

Which Legal Entity?

Which Geography?

Which Business Unit?

Which System?

Which Data?

Which Product?

This avoids unnecessary compliance work.

24. Applicability Statement

Example:

Requirement:
PCI DSS

Applicability:
Applicable to systems that store, process, or transmit cardholder data and systems that can impact the security of the cardholder data environment.

Business Owner:
Payments

Compliance Owner:
Security Compliance

Clear applicability prevents scope confusion.

25. Step 3 — Interpret Requirements

Compliance teams should understand what each requirement actually expects.

This may require collaboration with:

Legal.
Security.
Privacy.
Engineering.
Finance.
Internal Audit.

GRC should avoid independently making legal interpretations where legal expertise is required.

26. Step 4 — Map Requirements

Each requirement should map to one or more controls.

Example:

Requirement:
Restrict access to sensitive systems.

Mapped Controls:

IAM-001 Access Approval
IAM-002 MFA
IAM-004 Privileged Access
IAM-010 Access Review
IAM-012 Authentication Monitoring

Multiple controls may support one requirement.

27. One Control, Multiple Requirements

Conversely:

IAM-002
Privileged MFA

may satisfy parts of multiple frameworks.

This creates a many-to-many relationship:

Requirements
     ↕
Controls

GRC platforms often manage these mappings.

28. Step 5 — Implement Controls

Controls must then operate within the business.

Example:

Requirement
   ↓
MFA Required
   ↓
Identity Platform
   ↓
Conditional Access
   ↓
MFA Enforcement

Documentation alone does not establish compliance.

29. Step 6 — Define Evidence

Each control should have expected evidence.

Example:

Control:
Privileged MFA

Evidence:

Privileged account population

MFA configuration

MFA coverage report

Approved exceptions

Evidence expectations should be defined before audit season.

30. Compliance Evidence Matrix

Example:

Control	Evidence	Frequency	Owner
IAM-002	MFA report	Quarterly	IAM
IAM-010	Access reviews	Quarterly	Application Owners
VUL-001	Scan reports	Monthly	Security
BCP-004	Recovery test	Annual	IT

This enables predictable evidence collection.

31. Step 7 — Assess Compliance

Compliance assessments determine whether requirements are being met.

Assessment methods may include:

Document Review

Control Testing

Interviews

Observation

Configuration Review

Sampling

Reperformance

The assessment approach should match the requirement.

32. Compliance Assessment Example

Requirement:

Privileged access must be periodically reviewed.

Assessment:

Obtain Privileged Population
        ↓
Obtain Review Evidence
        ↓
Validate Review Frequency
        ↓
Validate Reviewer
        ↓
Check Remediation
        ↓
Determine Compliance

33. Compliance Status

Organizations may classify requirements as:

Compliant

Partially Compliant

Non-Compliant

Not Applicable

Not Assessed

Definitions should be standardized.

34. Compliant

A requirement may be classified as compliant when:

Applicable controls are implemented.
Controls operate as expected.
Required evidence exists.
No significant unresolved gaps remain.

35. Partially Compliant

Example:

Requirement:
MFA for all administrators

Admin Accounts:
200

Protected:
190

Missing:
10

The requirement may be partially satisfied but not fully compliant.

36. Non-Compliant

A requirement may be non-compliant where:

Required control does not exist.
Control is ineffective.
Required process is not performed.
Evidence demonstrates failure.
Significant requirements remain unmet.

Non-compliance should trigger risk evaluation.

37. Not Applicable

A requirement may legitimately not apply.

However:

Not Applicable should be justified.

Example:

Requirement:
Physical data-center access control

Organization:
Uses only managed cloud infrastructure and operates no in-scope physical data center.

Status:
Not Applicable

Rationale:
Documented

38. Not Assessed

Not assessed is different from compliant.

Not Assessed
≠
Compliant

It means sufficient evaluation has not yet occurred.

This distinction is important in dashboards.

39. Compliance Gap

A compliance gap exists when an applicable requirement is not fully satisfied.

Example:

Requirement:
Quarterly privileged access reviews

Current State:
Annual reviews

Result:
Compliance Gap

The gap should be documented and assessed.

40. Gap Analysis

A compliance gap analysis compares:

Required State
      ↓
Current State
      ↓
Difference
      ↓
Remediation

This is commonly performed before:

Certifications.
Regulatory assessments.
New framework adoption.
Customer audits.

41. Gap Register

Example:

Gap	Requirement	Risk	Owner	Due
GAP-001	MFA	High	IAM	Sep 2026
GAP-002	Logging	High	SOC	Oct 2026
GAP-003	Vendor Review	Medium	Procurement	Nov 2026

This allows structured remediation tracking.

42. Compliance Remediation

A remediation plan should define:

Gap

Root Cause

Required Action

Owner

Target Date

Milestones

Evidence

Validation

GRC should monitor progress.

43. Compliance Exception

Sometimes an organization cannot immediately meet a requirement.

A formal exception process may be required.

Requirement
      ↓
Cannot Meet
      ↓
Exception Request
      ↓
Risk Assessment
      ↓
Compensating Controls
      ↓
Approval
      ↓
Expiration

Exceptions should not become permanent loopholes.

44. Exception Documentation

An exception record may include:

Requirement.
Reason.
Business justification.
Risk.
Systems affected.
Compensating controls.
Approver.
Start date.
Expiration date.
Remediation plan.

This creates accountability.

45. Exception Expiration

Every temporary exception should generally have a review or expiration point.

Example:

Exception:
Legacy system cannot support MFA.

Expiration:
31 December 2026

Remediation:
Replace authentication platform.

Without expiration, temporary exceptions can become permanent control gaps.

46. Compensating Controls

A compensating control provides alternative risk reduction.

Example:

Required:

MFA

Unavailable for legacy system.

Possible compensating controls:

PAM Gateway

Network Restriction

Session Monitoring

Dedicated Workstation

Daily Log Review

Whether this satisfies a compliance requirement depends on the applicable requirement and assessment criteria.

47. Compliance Monitoring

Compliance should be monitored between formal assessments.

Examples:

Control health.
Evidence completion.
Exceptions.
Regulatory changes.
Findings.
Remediation status.
Certification expiration.

This creates continuous visibility.

48. Compliance Calendar

A compliance calendar may track:

Activity	Frequency
Access Review	Quarterly
Vulnerability Assessment	Monthly
Policy Review	Annual
Vendor Assessment	Annual
DR Exercise	Annual
Compliance Certification	Annual

This prevents missed obligations.

49. Compliance Deadlines

Some requirements have specific deadlines.

Examples:

Incident Notification

Regulatory Reporting

Certification Renewal

Policy Review

Risk Assessment

Control Testing

Missed deadlines can create compliance risk.

50. Regulatory Change Management

Regulations and standards evolve.

Organizations need a process to identify and respond to changes.

Regulatory Change
       ↓
Identify
       ↓
Analyze
       ↓
Determine Applicability
       ↓
Assess Impact
       ↓
Update Controls
       ↓
Implement
       ↓
Validate

This is regulatory change management.

51. Sources of Regulatory Change

Organizations may monitor:

Regulators.
Government publications.
Standards organizations.
Legal counsel.
Industry associations.
Compliance intelligence services.

Relevant changes should be centrally tracked.

52. Regulatory Change Register

Example:

Change	Impact	Owner	Due	Status
New privacy requirement	High	Privacy	Dec	In Progress
Updated security standard	Medium	Security	Mar	Planning
New reporting requirement	High	Compliance	Jan	Open

This provides governance.

53. Impact Assessment

When requirements change, determine:

Which Policies Change?

Which Controls Change?

Which Systems Change?

Which Contracts Change?

Which Teams Are Impacted?

What Is the Deadline?

What Evidence Will Be Required?

Regulatory change can create enterprise-wide work.

54. Framework Version Management

Standards also change.

Example:

Framework Version A
       ↓
New Version Published
       ↓
Requirement Comparison
       ↓
Gap Analysis
       ↓
Control Updates
       ↓
Transition

GRC should know which version the organization currently uses.

55. Compliance Evidence Repository

Evidence should be centrally organized.

Example:

Control IAM-002
│
├── 2026-Q1
├── 2026-Q2
├── 2026-Q3
└── 2026-Q4

Each evidence item can map to multiple frameworks.

56. Evidence Reuse

A mature compliance program avoids repeatedly asking technical teams for identical evidence.

Instead:

Control
   ↓
Evidence
   ↓
Requirement Mapping
   ↓
ISO
SOC 2
PCI DSS
Customer Audit

This significantly reduces compliance fatigue.

57. Compliance Fatigue

Poorly coordinated compliance programs may create:

ISO Team
→ Requests MFA evidence

SOC Team
→ Requests MFA evidence

PCI Team
→ Requests MFA evidence

Customer Assurance
→ Requests MFA evidence

Engineering teams receive the same request repeatedly.

A unified GRC model solves this.

58. Unified Compliance Model

A scalable model is:

Multiple Requirements
        ↓
Unified Control Framework
        ↓
Control Owners
        ↓
Central Evidence
        ↓
Continuous Testing
        ↓
Multiple Assessments

This creates a single source of truth.

59. Compliance Ownership Model

Compliance requires shared responsibility.

Board / Leadership
       ↓
Governance

Legal
       ↓
Legal Interpretation

GRC / Compliance
       ↓
Coordination & Monitoring

Control Owners
       ↓
Control Operation

Internal Audit
       ↓
Independent Assurance

No single department can own every aspect of compliance.

60. Role of Legal

Legal teams may help determine:

Regulatory applicability.
Legal interpretation.
Contractual requirements.
Regulatory notification obligations.
Legal risk.

GRC should collaborate with Legal rather than replacing legal expertise.

61. Role of Security

Security teams may:

Implement technical controls.
Monitor security.
Manage vulnerabilities.
Respond to incidents.
Operate security platforms.

Compliance requirements often depend on these activities.

62. Role of GRC

GRC typically connects everything.

Requirements
      ↓
GRC
      ↓
Policies
Controls
Owners
Evidence
Testing
Findings
Reporting

GRC provides coordination and governance.

63. Compliance Attestation

Organizations may sometimes provide formal statements confirming compliance.

Examples may include:

Management attestations.
Customer compliance statements.
Regulatory certifications.
Framework-specific attestations.

Attestations should be supported by evidence.

64. False Attestation Risk

An organization should not certify:

All controls are operating effectively.

without sufficient basis.

Attestation should be supported by:

Control Evidence
      +
Testing
      +
Exception Review
      +
Management Validation

Unsupported statements create governance and legal risk.

65. Compliance Reporting

Leadership needs visibility into compliance posture.

Reports may include:

Compliance percentage.
Open gaps.
Critical non-compliance.
Expiring exceptions.
Overdue remediation.
Upcoming assessments.
Regulatory changes.

Reporting should focus on meaningful risk.

66. Example Compliance Dashboard

Metric	Result
Applicable Requirements	425
Compliant	386
Partially Compliant	21
Non-Compliant	8
Open Exceptions	14
Overdue Remediation	6

The numbers require context to be useful.

67. Compliance Percentage

Organizations sometimes calculate:

Compliance Rate =
Compliant Requirements
÷
Applicable Requirements
× 100

However, this metric has limitations.

For example:

99% Compliant

sounds excellent.

But the missing 1% might include:

MFA for production administrators.

Risk matters more than the percentage alone.

68. Risk-Weighted Compliance

A more useful model may consider requirement criticality.

Example:

Critical Requirement Failure
      >
Several Low-Risk Documentation Gaps

Leadership reporting should emphasize material exposure.

69. Compliance Heatmap

A compliance heatmap may show:

Domain	Status
IAM	High Risk
Data Protection	Moderate
Vulnerability Management	Moderate
Business Continuity	Low
Physical Security	Low

This helps prioritize action.

70. Compliance KPIs

Possible KPIs include:

Assessment completion rate.
Evidence completion rate.
Remediation completed within SLA.
Policy review completion.
Control testing completion.
Certification renewal completion.

KPIs measure performance.

71. Compliance KRIs

Possible KRIs include:

Critical non-compliance findings.
Overdue high-risk gaps.
Expired exceptions.
Repeat audit findings.
Unassessed regulatory requirements.

KRIs indicate increasing compliance risk.

72. Continuous Compliance

Traditional compliance:

Annual Assessment
       ↓
Point-in-Time Result

Continuous compliance:

Controls
   ↓
Continuous Monitoring
   ↓
Automated Evidence
   ↓
Real-Time Status
   ↓
Exception Detection

Cloud environments make this increasingly practical.

73. Continuous Compliance Example

Requirement:

Cloud storage must not be publicly accessible.

Traditional:

Annual Review
      ↓
Public Bucket Discovered

Continuous:

Cloud Configuration
       ↓
Continuous Scanner
       ↓
Public Exposure Detected
       ↓
Alert
       ↓
Remediation

This reduces the period of non-compliance.

74. Compliance as Code

Some requirements can be translated into machine-enforceable rules.

Example:

Policy:

Production databases must be encrypted.

Implementation:

Infrastructure Code
       ↓
Policy Engine
       ↓
Encryption Enabled?
       │
       ├── Yes → Deployment Allowed
       └── No → Deployment Blocked

This is often called policy-as-code or part of compliance-as-code.

75. Preventive Compliance

Traditional compliance often detects violations after they happen.

Modern approaches increasingly prevent violations.

Developer
    ↓
Configuration
    ↓
Compliance Check
    ↓
Pass?
   /   \
Yes     No
 ↓       ↓
Deploy  Block

Preventive controls can reduce remediation effort.

76. Cloud Compliance

Cloud environments introduce unique challenges:

Rapid infrastructure changes.
Multiple cloud providers.
Shared responsibility.
Dynamic resources.
Infrastructure as Code.
Large-scale identities.
Temporary resources.

Annual manual assessments alone may be insufficient.

77. Shared Responsibility and Compliance

Cloud providers may operate certain controls.

Example:

Cloud Provider
→ Physical Data Center Security

Customer
→ IAM Configuration

Customer
→ Data Classification

Customer
→ Application Security

Organizations must understand which compliance responsibilities remain theirs.

78. Third-Party Compliance

Organizations depend on vendors.

Third-party compliance may involve:

Security assessments.
SOC reports.
ISO certificates.
Contract reviews.
Data processing agreements.
Penetration test summaries.
Business continuity evidence.

Vendor assurance does not eliminate the organization’s responsibility to manage third-party risk.

79. Reviewing Vendor Assurance

A vendor says:

We are SOC 2 compliant.

GRC should ask:

Which Service?

Which Scope?

Which Period?

Which Criteria?

Were Exceptions Identified?

Are Subservice Organizations Included?

Is the Report Current?

The existence of a report alone is not sufficient.

80. Customer Compliance Requirements

Enterprise customers may impose additional requirements.

Examples:

MFA.
Encryption.
Data location.
Incident notification.
Audit rights.
Vulnerability remediation.
Business continuity.

These contractual requirements should enter the compliance obligations register.

81. Contractual Compliance

A security requirement can become legally significant through a contract.

Example:

Customer Contract:

Critical vulnerabilities must be remediated within 15 days.

Even if no regulation requires exactly 15 days, the organization has made a contractual commitment.

82. Compliance and Policies

External requirements should often flow into internal governance.

External Requirement
        ↓
Corporate Policy
        ↓
Standard
        ↓
Procedure
        ↓
Control

This embeds compliance into normal operations.

83. Compliance Documentation Hierarchy

Example:

Law / Regulation
       ↓
Policy
       ↓
Standard
       ↓
Procedure
       ↓
Control
       ↓
Evidence

This creates traceability from external requirement to implementation.

84. Policy Compliance

Organizations must also monitor compliance with their own policies.

Example:

Policy:

Critical systems must undergo quarterly access reviews.

If reviews do not occur:

Internal Policy Non-Compliance

Internal requirements matter even where no external regulation explicitly requires the activity.

85. Compliance Issue Management

Compliance issues should follow a lifecycle.

Issue Identified
      ↓
Risk Assessed
      ↓
Owner Assigned
      ↓
Remediation Planned
      ↓
Progress Tracked
      ↓
Retested
      ↓
Closed

This should integrate with broader GRC finding management.

86. Repeat Non-Compliance

Repeated issues deserve attention.

Example:

2024
Late Vendor Reviews

2025
Late Vendor Reviews

2026
Late Vendor Reviews

This suggests a systemic process weakness.

87. Root Cause Analysis

Instead of repeatedly telling teams:

Complete reviews on time.

determine why they are late.

Possible causes:

Manual Process

No Central Inventory

Unclear Ownership

No Automated Reminders

Insufficient Resources

Fixing root causes improves long-term compliance.

88. Compliance Risk

Compliance risk is the possibility of negative consequences from failing to meet applicable obligations.

Potential consequences include:

Regulatory action.
Financial penalties.
Contract breach.
Certification loss.
Customer loss.
Legal action.
Operational restrictions.
Reputational impact.

Compliance risk should be incorporated into enterprise risk management.

89. Compliance Risk Assessment

Organizations may evaluate:

Requirement Criticality

Likelihood of Violation

Business Impact

Regulatory Exposure

Control Effectiveness

Residual Risk

This helps prioritize compliance activities.

90. Compliance and Risk Acceptance

Not every internal compliance gap can be remediated immediately.

However:

Management cannot simply “accept” a legal obligation away.

Risk acceptance may address business risk associated with a gap, but it does not necessarily remove the underlying legal or contractual obligation.

Legal and compliance expertise should be involved.

91. Compliance Governance Committee

Large organizations may establish committees to review:

Major regulatory changes.
High-risk compliance gaps.
Overdue remediation.
Significant exceptions.
Upcoming certifications.
Regulatory examinations.

This provides executive oversight.

92. Compliance Reporting to Leadership

Executives typically need answers to:

Where are we materially non-compliant?

What is the business impact?

Which gaps are overdue?

What regulatory changes are coming?

Which certifications are at risk?

Who owns remediation?

They generally do not need hundreds of control-level details.

93. Board-Level Reporting

Board reporting should focus on material issues.

Example:

Critical Regulatory Exposure

Major Certification Risk

Material Customer Commitments

High-Risk Open Findings

Significant Regulatory Changes

GRC must translate compliance data into business risk.

94. Compliance Program Maturity

Compliance programs often evolve through stages.

Stage 1 — Reactive

Audit Arrives
→ Prepare

Stage 2 — Documented

Requirements
→ Policies
→ Controls

Stage 3 — Managed

Control Owners
→ Testing
→ Evidence
→ Findings

Stage 4 — Integrated

Multiple Frameworks
→ Common Controls
→ Shared Evidence

Stage 5 — Continuous

Automated Monitoring
→ Real-Time Evidence
→ Continuous Assurance

95. Common Compliance Management Mistakes

Common mistakes include:

Treating compliance as an annual audit project.
Applying frameworks without determining applicability.
Creating duplicate controls for every framework.
Failing to assign requirement owners.
Tracking requirements in disconnected spreadsheets.
Collecting evidence only during audits.
Assuming certification means zero risk.
Treating compliance as equivalent to security.
Allowing exceptions to remain indefinitely.
Failing to monitor regulatory changes.
Reporting compliance percentages without risk context.
Failing to validate remediation.
Ignoring contractual security obligations.

96. Spreadsheet Compliance Problem

Early programs may operate through:

ISO.xlsx

SOC2.xlsx

PCI.xlsx

Customer-Audit.xlsx

Privacy.xlsx

Each spreadsheet may contain similar controls.

This creates:

Duplication

Conflicting Status

Duplicate Evidence Requests

Inconsistent Ownership

Audit Fatigue

A unified control framework is more scalable.

97. Single Source of Truth

A mature compliance architecture can be:

Obligations Register
        ↓
Unified Control Library
        ↓
Control Owners
        ↓
Evidence Repository
        ↓
Control Testing
        ↓
Compliance Mapping
        ↓
Multiple Frameworks

This creates one source of truth.

98. Practical Scenario

Suppose an organization decides to pursue several assurance objectives:

ISO/IEC 27001

SOC 2

PCI DSS

A weak approach creates three independent projects.

99. Weak Approach

ISO Team
→ ISO Controls

SOC Team
→ SOC Controls

PCI Team
→ PCI Controls

This results in duplicate requirements.

Example:

ISO:
MFA

SOC 2:
MFA

PCI DSS:
MFA

Three teams request the same evidence.

100. Better Approach

Create one enterprise control:

IAM-002
Privileged MFA

Map:

IAM-002
   │
   ├── ISO Requirement
   ├── SOC 2 Criterion
   └── PCI DSS Requirement

Then maintain one authoritative evidence set.

101. Compliance Status Example

Control:

IAM-002
Privileged MFA

Evidence:

Privileged Accounts:
350

MFA Protected:
348

Approved Exceptions:
2

GRC evaluates:

Are exceptions authorized?
Are compensating controls implemented?
Do applicable requirements permit the approach?
Is residual risk acceptable?

Compliance determination should be evidence based.

102. Regulatory Change Scenario

Suppose a new requirement mandates stronger incident notification.

Existing process:

Notification Target:
72 Hours

New applicable requirement:

Notification Target:
24 Hours

GRC performs:

Requirement Change
      ↓
Impact Assessment
      ↓
Incident Policy Update
      ↓
Procedure Update
      ↓
Workflow Update
      ↓
Training
      ↓
Testing

This demonstrates regulatory change management.

103. Compliance Evidence Scenario

Auditor requests:

Demonstrate that terminated users lose access promptly.

Instead of creating new evidence, GRC maps the request to:

IAM-006
Termination Access Revocation

Evidence repository already contains:

HR Termination Population

IAM Disablement Logs

Termination SLA Report

Exception Records

The audit request can be fulfilled efficiently.

104. Compliance Management Checklist

For each obligation, confirm:

What is the requirement?
What is its source?
Why does it apply?
Which entity is affected?
Which systems are affected?
Which data is affected?
Who owns the obligation?
Which policies support it?
Which controls satisfy it?
What evidence demonstrates compliance?
How frequently is it assessed?
What is its current status?
Are there exceptions?
Are there open gaps?
Is remediation required?
Has the requirement changed?
When is the next assessment?

105. GRC Professional Responsibilities

As a GRC professional, you may:

Maintain compliance obligations registers.
Perform applicability assessments.
Map requirements to controls.
Coordinate compliance assessments.
Maintain evidence repositories.
Manage compliance calendars.
Track exceptions.
Track compliance gaps.
Coordinate remediation.
Monitor regulatory changes.
Support certifications.
Support customer audits.
Build compliance dashboards.
Coordinate with Legal.
Maintain common control frameworks.
Support continuous compliance monitoring.

Compliance management is therefore a core enterprise GRC function.

106. Compliance Management Mindset

A weak compliance mindset asks:

What do we need to show the auditor?

A stronger mindset asks:

What controls do we need to meet this requirement?

A mature mindset asks:

How can we integrate this requirement into our enterprise control environment?

An advanced mindset asks:

How can we continuously demonstrate compliance without repeatedly creating manual evidence?

That progression moves an organization from audit-driven compliance to continuous assurance.

Key Takeaways

Compliance means meeting applicable legal, regulatory, contractual, standards-based, and internal requirements.
Compliance management is a continuous governance process.
Organizations should determine applicability before implementing requirements.
A compliance obligations register creates centralized visibility.
External requirements should be translated into internal policies and controls.
Common controls can satisfy multiple frameworks.
Compliance and security overlap but are not identical.
Compliance assessments should rely on evidence.
Compliance gaps require structured remediation.
Exceptions should be documented, approved, monitored, and time limited.
Regulatory and standards changes require formal change management.
Compliance evidence should be reusable across multiple assessments.
Risk-weighted reporting is more useful than compliance percentages alone.
Cloud environments increasingly require continuous compliance monitoring.
Policy-as-code and automated evidence collection can improve scalability.
GRC connects requirements, controls, evidence, assessments, findings, and reporting.

Knowledge Check

Before continuing, make sure you can answer:

What is compliance?
What is compliance management?
What are the main sources of compliance requirements?
What is regulatory applicability?
What is a compliance obligations register?
Why should obligations have owners?
How are requirements translated into controls?
What is a common control framework?
What is the difference between compliance and security?
What is a compliance gap analysis?
What is the difference between partially compliant and non-compliant?
Why must Not Applicable decisions be justified?
What is a compliance exception?
What is a compensating control?
What is regulatory change management?
Why is evidence reuse important?
What is continuous compliance?
What is compliance-as-code?
Why can compliance percentages be misleading?
What role does GRC play in enterprise compliance management?

What’s Next?

➡️ Next: 11 — Third-Party Risk Management

In the next lesson, you will move from managing your organization’s own compliance obligations to managing the security and compliance risks introduced by vendors, suppliers, cloud providers, SaaS platforms, contractors, partners, and other third parties.

You will learn the complete third-party lifecycle:

Business Need
     ↓
Vendor Identification
     ↓
Risk Tiering
     ↓
Due Diligence
     ↓
Security Assessment
     ↓
Contract Requirements
     ↓
Onboarding
     ↓
Continuous Monitoring
     ↓
Periodic Reassessment
     ↓
Issue Management
     ↓
Offboarding

You will also learn how GRC teams review security questionnaires, SOC reports, ISO certifications, penetration-test summaries, privacy documentation, business continuity evidence, fourth-party dependencies, contractual security clauses, vendor exceptions, and remediation plans.

This will prepare you for one of the most common real-world responsibilities of GRC Analysts: Third-Party Risk Management (TPRM).