"07 Control Design & Implementation"

Security frameworks tell organizations what security outcomes should be achieved.

Policies establish management expectations.

Risk assessments identify what could harm the organization.

Controls are where these concepts become operational.

A security control is a safeguard or mechanism designed to prevent, detect, reduce, correct, or otherwise manage risk.

Examples include:

Multi-factor authentication.
Encryption.
Access reviews.
Vulnerability scanning.
Security monitoring.
Backups.
Security awareness training.
Vendor assessments.
Change approvals.
Incident response exercises.

For a GRC professional, understanding control design is essential.

You must be able to move from:

Risk
  ↓
Policy Requirement
  ↓
Framework Requirement
  ↓
Control Objective
  ↓
Control
  ↓
Implementation
  ↓
Evidence
  ↓
Testing
  ↓
Assurance

A control should not exist simply because a framework contains a requirement.

It should address a clearly understood risk or business requirement.

Learning Objectives

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

Explain the purpose of enterprise security controls.
Understand control objectives.
Translate risks into controls.
Translate policies and framework requirements into controls.
Differentiate preventive, detective, corrective, deterrent, and recovery controls.
Differentiate administrative, technical, and physical controls.
Understand manual, automated, and hybrid controls.
Define control owners and operators.
Establish control frequency.
Define evidence requirements.
Write effective control descriptions.
Understand control dependencies.
Design compensating controls.
Evaluate control design effectiveness.
Understand implementation effectiveness.
Build an enterprise control library.
Map controls across multiple frameworks.
Recognize common control design failures.

1. What Is a Security Control?

A security control is a safeguard designed to manage risk.

Consider this risk:

An attacker could compromise privileged accounts and gain unauthorized access to production systems.

Possible controls include:

MFA
   +
Privileged Access Management
   +
Least Privilege
   +
Access Reviews
   +
Privileged Activity Monitoring

Each control addresses part of the risk.

2. Controls Connect Governance to Technology

Controls sit between governance requirements and operational implementation.

Business Objective
       │
       ▼
Risk
       │
       ▼
Policy
       │
       ▼
Control
       │
       ▼
Technology / Process
       │
       ▼
Evidence

For example:

Risk:
Unauthorized access

Policy:
Access must follow least privilege.

Control:
Quarterly privileged access reviews.

Technology:
IAM platform.

Evidence:
Access review report.

This creates traceability.

3. What Is a Control Objective?

A control objective describes the desired outcome of one or more controls.

Example:

Ensure that access to sensitive systems is limited to authorized users according to legitimate business requirements.

Supporting controls might include:

Identity verification.
Access approval.
Role-based access.
MFA.
Access reviews.
Account termination.

The objective describes what must be achieved.

Individual controls describe how it is achieved.

4. Control Objective vs Control

Control Objective

Ensure privileged access is appropriately restricted.

Control

All privileged users must authenticate using MFA.

Another control might be:

Privileged access must be reviewed quarterly by the relevant system owner.

Several controls can therefore support one objective.

5. Why Control Objectives Matter

Without clear objectives, organizations may implement controls without understanding their purpose.

For example:

Control:
Weekly vulnerability scan

Why?

The control objective might be:

Identify security vulnerabilities within organizational systems in sufficient time to support risk-based remediation.

This provides business context.

6. Sources of Control Requirements

Controls can originate from several sources.

Business Requirements
        │
Risk Assessments
        │
Policies
        │
Frameworks
        │
Regulations
        │
Contracts
        │
Audit Findings
        │
Threat Intelligence
        ▼
Enterprise Controls

A mature control environment consolidates these requirements.

7. Risk-Driven Control Design

Start with the risk.

Example:

Risk:

Customer information could be exposed because sensitive databases are not consistently encrypted.

Control objective:

Protect sensitive information from unauthorized disclosure.

Controls:

Encryption at Rest

Encryption in Transit

Centralized Key Management

Key Rotation

Access Control

Controls should directly reduce identified risk.

8. Framework-Driven Control Design

A framework may establish a requirement.

Example:

Framework Requirement:

Organizations should appropriately manage privileged access.

The enterprise translates this into internal controls:

IAM-001
Privileged access requires approval.

IAM-002
Privileged accounts require MFA.

IAM-003
Privileged access is reviewed quarterly.

IAM-004
Privileged activities are logged.

Framework language becomes operational.

9. Policy-Driven Control Design

Consider a policy:

Critical systems must be protected against known vulnerabilities.

Supporting controls may include:

VUL-001
Authenticated vulnerability scanning is performed weekly.

VUL-002
Critical vulnerabilities are remediated according to defined SLAs.

VUL-003
Exceptions require formal risk acceptance.

VUL-004
Vulnerability metrics are reported monthly.

The controls make the policy enforceable.

10. Control Categories

Controls can be categorized in several ways.

One common classification is:

Preventive

Detective

Corrective

Deterrent

Recovery

Understanding the purpose of each type helps build defense in depth.

11. Preventive Controls

Preventive controls attempt to stop an unwanted event before it occurs.

Examples include:

MFA.
Firewalls.
Encryption.
Least privilege.
Network segmentation.
Secure configurations.
Application allowlisting.

Example:

Attacker
   ↓
Authentication
   ↓
MFA
   ↓
Access Prevented

12. Detective Controls

Detective controls identify events that have occurred or are occurring.

Examples include:

SIEM alerts.
IDS.
Security logging.
File integrity monitoring.
Access reviews.
Vulnerability scans.

Example:

Suspicious Activity
        ↓
Security Logs
        ↓
SIEM
        ↓
Alert
        ↓
SOC Investigation

13. Corrective Controls

Corrective controls reduce the impact of an identified problem or restore an environment to an acceptable state.

Examples:

Malware removal.
Account disabling.
Security patching.
Configuration remediation.
Password reset.

Security Issue
      ↓
Detected
      ↓
Corrective Action
      ↓
Risk Reduced

14. Recovery Controls

Recovery controls help restore operations following disruption.

Examples:

Backups.
Disaster recovery.
System restoration.
Alternate processing environments.
Business continuity arrangements.

Service Failure
      ↓
Recovery Plan
      ↓
Backup Restoration
      ↓
Service Restored

15. Deterrent Controls

Deterrent controls discourage undesirable behavior.

Examples:

Warning banners.
CCTV.
Security policies.
Disciplinary policies.
Monitoring notifications.

They may not physically prevent activity but can reduce its likelihood.

16. Defense in Depth

Strong control environments rarely rely on one control.

Example:

Internet
   ↓
Firewall
   ↓
WAF
   ↓
MFA
   ↓
Application Authorization
   ↓
Database Access Control
   ↓
Encryption
   ↓
Logging

If one control fails, another may still reduce risk.

This is defense in depth.

17. Administrative Controls

Administrative controls are governance and process-based safeguards.

Examples include:

Policies.
Procedures.
Security training.
Access reviews.
Risk assessments.
Vendor assessments.
Change management.

They influence how people and processes operate.

18. Technical Controls

Technical controls are implemented through technology.

Examples:

MFA.
Firewalls.
EDR.
Encryption.
IAM.
DLP.
SIEM.
Network segmentation.

These controls are often automated or system enforced.

19. Physical Controls

Physical controls protect facilities and physical assets.

Examples include:

Security guards.
CCTV.
Badge readers.
Locks.
Fences.
Environmental monitoring.

Cybersecurity programs may depend on physical controls.

20. Manual Controls

Manual controls require human action.

Example:

A manager reviews privileged access every quarter.

Advantages:

Flexible.
Context-aware.
Useful for judgment-based decisions.

Disadvantages:

Human error.
Inconsistent execution.
Difficult to scale.
Evidence may be incomplete.

21. Automated Controls

Automated controls operate through technology.

Example:

The identity platform automatically blocks authentication attempts when MFA validation fails.

Advantages include:

Consistency.
Scalability.
Continuous operation.
Better evidence generation.

However, automated controls still require monitoring and maintenance.

22. Hybrid Controls

Many enterprise controls combine automation and human review.

Example:

IAM System
   ↓
Automatically Generates Access Report
   ↓
Manager Reviews Access
   ↓
IAM Team Removes Unnecessary Access

This is a hybrid control.

23. Preventive vs Detective Balance

Suppose an organization implements MFA.

That is preventive.

But what happens if an attacker still obtains access?

Detective controls may include:

Authentication monitoring.
Impossible-travel alerts.
Privileged activity logging.
SIEM correlation.

Strong programs combine both.

24. Control Design Principles

Effective controls should generally be:

Risk based.
Clearly defined.
Appropriately scoped.
Assigned to an owner.
Repeatable.
Measurable.
Evidenced.
Testable.
Sustainable.
Proportionate to risk.

Controls that cannot be tested are difficult to assure.

25. Writing a Good Control

Weak control:

Access should be reviewed.

Better:

System owners must periodically review user access.

Strong:

System owners review privileged user access quarterly and confirm that access remains appropriate based on current job responsibilities. Unauthorized or unnecessary access is removed and review evidence is retained.

The strong version defines:

Who.
What.
Frequency.
Expected result.
Evidence.

26. Control Description Structure

A useful structure is:

WHO
performs

WHAT
activity

WHEN
or how frequently

WHY
or objective

HOW
or method

EVIDENCE
produced

Example:

The IAM team generates a quarterly privileged access report. System owners review assigned privileges and certify whether access remains appropriate. Unauthorized access is removed, and completed certifications are retained as evidence.

27. Control ID

Controls should have unique identifiers.

Example:

IAM-001
IAM-002
LOG-001
VUL-001
BCP-001

The prefix may represent the control domain.

This simplifies mapping and reporting.

28. Control Domains

An enterprise control library might use domains such as:

GOV — Governance

IAM — Identity & Access

DAT — Data Protection

LOG — Logging & Monitoring

VUL — Vulnerability Management

NET — Network Security

APP — Application Security

TPR — Third-Party Risk

IR — Incident Response

BCP — Business Continuity

PHY — Physical Security

The exact structure should fit the organization.

29. Control Ownership

Every control should have an owner.

The control owner is accountable for ensuring the control is appropriately designed and operated.

Example:

Control:

Quarterly privileged access review

Control Owner:

Director of Identity & Access Management

Ownership prevents ambiguity.

30. Control Owner vs Control Operator

The owner and operator may be different.

Example:

Control Owner:

IAM Director

Control Operator:

IAM Analyst

The analyst performs the activity.

The director remains accountable.

31. Business Control Owners

Not every control belongs to cybersecurity.

Examples:

Security Awareness
→ HR + Security

Vendor Due Diligence
→ Procurement

Employee Termination
→ HR

Financial Access Review
→ Finance

Physical Security
→ Facilities

GRC programs therefore span the enterprise.

32. Control Frequency

Controls should specify how often they operate.

Common frequencies include:

Continuous.
Daily.
Weekly.
Monthly.
Quarterly.
Semi-annually.
Annually.
Event driven.

Example:

Control:

Privileged access review

Frequency:

Quarterly

33. Continuous Controls

Some controls operate continuously.

Examples:

MFA.
Firewall rules.
Endpoint protection.
Encryption.
Security logging.

Even continuous controls require periodic validation.

For example:

MFA operates continuously.

GRC validates MFA coverage quarterly.

34. Event-Driven Controls

Some controls operate when specific events occur.

Examples:

New Employee
→ Access provisioning control

Employee Termination
→ Access revocation control

New Vendor
→ Vendor risk assessment

Major System Change
→ Security review

Security Incident
→ Incident response process

These controls should clearly define their trigger.

35. Control Scope

A control should identify what it applies to.

Example:

Control:

MFA

Scope:

All workforce users accessing corporate cloud services.

Enhanced Scope:

All privileged accounts across production environments.

Poorly defined scope creates control gaps.

36. Control Population

For testing purposes, identify the population.

Example:

Control:

Quarterly access reviews

Population:

All 47 production applications requiring quarterly certification.

Auditors may select samples from this population.

37. Control Evidence

Controls should produce evidence.

Examples include:

System reports.
Screenshots.
Tickets.
Logs.
Manager approvals.
Meeting records.
Scan reports.
Configuration exports.
Training reports.

Evidence demonstrates that the control operated.

38. Evidence Quality

Strong evidence should be:

Relevant.
Complete.
Accurate.
Timely.
Authentic.
Traceable.

A screenshot without date, system name, or context may provide weak evidence.

39. Example Evidence

Control:

Quarterly privileged access reviews.

Evidence:

Access Review Report

Review Period:
Q3 2026

Population:
327 privileged accounts

Reviewer:
Application Owner

Completion Date:
15 October 2026

Exceptions:
7

Remediation Tickets:
Linked

This provides much stronger assurance.

40. Evidence Retention

Organizations should define how long control evidence is retained.

Retention may depend on:

Regulation.
Audit cycle.
Contracts.
Internal policy.
Litigation requirements.

Example:

Control Evidence Retention:

3 years

Evidence should be securely stored.

41. Control Implementation

Control implementation translates design into actual operation.

For example:

Control Requirement:

MFA required for privileged users.

Implementation may involve:

Identity Provider

MFA Enrollment

Conditional Access

Privileged Role Configuration

Monitoring

A documented control is not automatically an implemented control.

42. Implementation Documentation

Useful implementation details may include:

Technology used.
Configuration.
Scope.
Responsible team.
Dependencies.
Monitoring.
Exceptions.
Evidence location.

This helps future assessment and audit.

43. Design Effectiveness

Design effectiveness asks:

If this control operates as designed, will it adequately address the intended risk?

Example:

Risk:

Administrator credentials may be compromised.

Control:

Administrators receive annual security awareness training.

Training helps, but it may not sufficiently address privileged credential compromise.

A stronger control would include MFA.

The original control may therefore be insufficiently designed for the risk.

44. Operating Effectiveness

Operating effectiveness asks:

Is the control actually operating as designed?

Example:

Control:

MFA is required for all privileged accounts.

Observed:

Privileged Accounts:
100

MFA Enabled:
82

MFA Missing:
18

The design may be appropriate.

Operation is ineffective or only partially effective.

45. Design vs Operation

Good Design
+
Good Operation
=
Effective Control

Possible outcomes:

Design	Operation	Result
Effective	Effective	Strong Control
Effective	Ineffective	Operating Failure
Ineffective	Effective	Design Failure
Ineffective	Ineffective	Major Control Weakness

This distinction is fundamental to control assurance.

46. Control Failure

A control failure occurs when a control does not operate as expected.

Examples:

Access review missed.
Backup job failed.
Vulnerability scan did not run.
MFA excluded users unexpectedly.
Firewall rule was incorrectly changed.

Failures should be tracked and assessed.

47. Control Deficiency

A deficiency may relate to:

Design

Implementation

Operation

Evidence

Scope

Example:

Control:
Quarterly access reviews

Problem:
Review completed but 20 applications excluded.

Deficiency:
Scope / operating effectiveness

48. Control Dependencies

Controls frequently depend on other controls.

Example:

Access Review
     │
     ▼
Depends On
     │
     ├── Accurate User Inventory
     ├── Accurate Role Mapping
     └── Reliable HR Data

If underlying data is incorrect, the review may be ineffective.

49. Upstream and Downstream Controls

Example:

HR Employee Record
       ↓
Identity Provisioning
       ↓
Access Assignment
       ↓
Access Review
       ↓
Termination

Failure upstream can affect several downstream controls.

Understanding dependencies helps identify systemic risk.

50. Key Controls

Not every control has equal importance.

A key control is particularly important for reducing significant risk or meeting critical requirements.

Examples might include:

MFA for privileged users.
Financial transaction approval.
Production change approval.
Backup recovery testing.

Key controls often receive greater testing attention.

51. Supporting Controls

Supporting controls strengthen key controls.

Example:

Key Control:
MFA

Supporting Controls:

Identity lifecycle management
Security monitoring
Access reviews
Authentication logging

Together they create stronger assurance.

52. Compensating Controls

Sometimes the required control cannot be implemented.

Example:

Required Control:

MFA

Problem:

Legacy application does not support MFA.

A compensating control may reduce the risk.

Possible controls:

Restricted network access.
PAM gateway.
Strong monitoring.
Enhanced logging.
Dedicated administrative workstation.
More frequent access reviews.

53. Designing Compensating Controls

A compensating control should:

Address the same risk.
Provide comparable protection where possible.
Be documented.
Be monitored.
Have an owner.
Be periodically reviewed.

It should not simply be an easier alternative.

54. Example Compensating Control

Risk:

Unauthorized privileged access to legacy financial application.

Required:

MFA

Unavailable.

Compensating controls:

PAM Gateway
+
Network Restriction
+
Dedicated Admin Workstation
+
Session Recording
+
Daily Log Review

Residual risk must still be evaluated.

55. Control Exceptions

If a control cannot be implemented, an exception may be required.

Control Requirement
       ↓
Cannot Comply
       ↓
Exception Request
       ↓
Risk Assessment
       ↓
Compensating Control
       ↓
Risk Acceptance
       ↓
Expiration Date

Exceptions should not silently become permanent control gaps.

56. Control Automation

Organizations increasingly automate controls.

Example:

Manual:

Administrator reviews every cloud storage bucket.

Automated:

Cloud configuration platform continuously detects public storage.

Automation improves scalability.

57. Automated Preventive Control

Modern environments can prevent non-compliant configurations before deployment.

Example:

Infrastructure Code
       ↓
Policy Check
       ↓
Public Storage?
       │
       ├── No → Deploy
       │
       └── Yes → Block

This is stronger than discovering the issue months later.

58. Policy-as-Code

Policy-as-code translates governance requirements into machine-enforceable rules.

Example policy:

Public cloud storage is prohibited unless formally approved.

Technical implementation:

Deployment Pipeline
       ↓
Policy Engine
       ↓
Check Storage Configuration
       ↓
Allow / Block

This connects GRC with DevSecOps.

59. Continuous Control Monitoring

Traditional model:

Control
   ↓
Annual Test
   ↓
Failure Discovered

Modern model:

Control
   ↓
Continuous Monitoring
   ↓
Failure Detected
   ↓
Alert
   ↓
Remediation

Continuous monitoring can significantly improve assurance.

60. Control Metrics

Controls should have meaningful metrics where appropriate.

Examples:

MFA Coverage

Patch SLA Compliance

Access Review Completion

Backup Success Rate

Security Training Completion

Vendor Assessment Completion

Metrics help evaluate performance.

61. KPI Example

Control:

Critical vulnerabilities must be remediated within 15 days.

KPI:

Percentage of critical vulnerabilities remediated within SLA

Example:

Target:
95%

Actual:
89%

This indicates control performance needs improvement.

62. KRI Example

A related KRI could be:

Number of critical vulnerabilities older than 30 days

Increasing numbers may indicate rising exposure.

KPIs and KRIs provide different perspectives.

63. Control Thresholds

Controls may have performance thresholds.

Example:

MFA Coverage

Green:
≥ 99%

Amber:
95–98.9%

Red:
< 95%

Thresholds help leadership interpret results.

64. Enterprise Control Library

Organizations should maintain controls centrally.

A control library might include:

Field	Example
Control ID	IAM-002
Control Name	Privileged MFA
Objective	Protect privileged access
Owner	IAM
Frequency	Continuous
Type	Preventive
Evidence	MFA report
Status	Implemented

This becomes a GRC source of truth.

65. Detailed Control Record

A complete control record may contain:

Control ID

Control Name

Control Objective

Control Description

Risk

Policy

Framework Mapping

Control Type

Control Owner

Control Operator

Frequency

Scope

Population

Implementation

Evidence

Testing Procedure

Dependencies

Exceptions

Status

This enables effective lifecycle management.

66. Control Mapping

A single enterprise control may satisfy several requirements.

Example:

IAM-002
Privileged MFA
      │
      ├── NIST
      ├── ISO 27001
      ├── SOC 2
      ├── PCI DSS
      └── CIS Controls

This prevents duplicated controls.

67. Common Controls

Suppose five frameworks require logging.

Instead of:

NIST Logging Control

ISO Logging Control

PCI Logging Control

SOC 2 Logging Control

CIS Logging Control

create:

LOG-001
Enterprise Security Logging

Then map applicable framework requirements to it.

68. Control Mapping Matrix

Enterprise Control	NIST	ISO	PCI DSS	SOC 2
IAM-001 Access Approval	✓	✓	✓	✓
IAM-002 MFA	✓	✓	✓	✓
LOG-001 Logging	✓	✓	✓	✓
VUL-001 Scanning	✓	✓	✓	✓
BCP-001 Recovery Testing	✓	✓	—	✓

One control can provide evidence for multiple assurance requirements.

69. Requirement Mapping Requires Judgment

Mapping is not simply keyword matching.

Two requirements may both mention:

Access Review

but one may require:

Annual review

while another requires:

Every six months

The enterprise control must satisfy the strictest applicable requirement or maintain appropriate scope-specific variations.

70. Control Rationalization

Control rationalization removes:

Duplicate controls.
Obsolete controls.
Overlapping controls.
Controls with no clear objective.
Controls that cannot be tested.

This improves control-library quality.

71. Example Duplicate Controls

Suppose the library contains:

IAM-014
Administrators use MFA.

IAM-028
Privileged users use MFA.

SEC-043
MFA required for administrators.

These may represent the same control.

They could potentially be consolidated into:

IAM-002
Privileged accounts must use approved MFA.

72. Control Lifecycle

Controls should follow a lifecycle.

Identify Requirement
       ↓
Design Control
       ↓
Approve
       ↓
Implement
       ↓
Operate
       ↓
Monitor
       ↓
Test
       ↓
Remediate
       ↓
Improve / Retire

Control management is continuous.

73. Control Approval

Important controls may require approval from:

Control owner.
Security.
GRC.
Risk management.
Relevant business leadership.

Approval confirms ownership and expectations.

74. Control Change Management

Controls should be reviewed when:

Technology changes.
Business processes change.
Regulations change.
Framework requirements change.
Control failures occur.
New threats emerge.

Example:

Old Control:

Annual vulnerability scanning.

New Risk Environment:

Internet-facing cloud applications.

Updated Control:

Continuous external scanning + weekly authenticated scanning.

Controls should evolve with risk.

75. Control Documentation Quality

Control documentation should allow another qualified person to understand:

What happens?

Who performs it?

When?

Why?

For which systems?

What evidence exists?

What happens when it fails?

If these questions cannot be answered, the control may not be adequately documented.

76. Evidence by Design

Evidence should be considered while designing the control.

Do not wait until audit time to ask:

How can we prove this happened?

Instead:

Design Control
     │
     ▼
Determine Evidence
     │
     ▼
Implement Evidence Generation
     │
     ▼
Operate Control

This is evidence by design.

77. Example Evidence-by-Design

Control:

Managers approve production access before provisioning.

Implementation should ensure the approval is captured in a workflow.

Evidence:

Request ID

Requester

Requested Role

Approver

Approval Timestamp

Provisioning Timestamp

This produces reliable audit evidence automatically.

78. Control Testing Readiness

When designing controls, ask:

Can we identify the population?
Can we select samples?
Can we prove execution?
Can we identify exceptions?
Can we determine who performed the control?
Can we verify timing?
Can we reproduce the evidence?

Good control design simplifies testing.

79. Example Control Design

Consider:

User access must be removed when employment ends.

A strong control could be:

Control ID:
IAM-006

Control Name:
Termination Access Revocation

Objective:
Prevent former employees from accessing organizational systems.

Trigger:
Employee termination.

Owner:
IAM Manager

Operator:
IAM Operations

Implementation:
HR termination event automatically triggers identity disablement.

Frequency:
Event driven.

Evidence:
HR termination record + IAM disablement log.

Target:
Access disabled within defined termination SLA.

This is measurable and testable.

80. Example Control Testing

Test:

1. Obtain terminated employee population.

2. Select sample.

3. Verify termination date.

4. Verify identity disablement timestamp.

5. Compare against SLA.

6. Verify critical application access was removed.

7. Document exceptions.

The design makes testing straightforward.

81. Control Design for Cloud

Cloud controls may include:

Root account protection.
IAM.
Logging.
Encryption.
Public exposure management.
Secure configuration.
Network controls.
Backup.
Cloud security monitoring.

Cloud controls should reflect the shared responsibility model.

82. Cloud Control Example

Control ID:
CLD-004

Control:
Cloud administrative accounts require MFA.

Owner:
Cloud Platform Team

Type:
Preventive

Frequency:
Continuous

Evidence:
Cloud IAM configuration report

Monitoring:
Daily compliance scan

This control can be automated.

83. Control Design for Third Parties

Third-party controls may include:

Before Contract:
Security assessment

Before Data Sharing:
Privacy assessment

Contract:
Security clauses

During Relationship:
Risk monitoring

Annually:
Reassessment

Termination:
Data return / destruction

Control design should cover the vendor lifecycle.

84. Control Design for AI

AI environments may require controls such as:

Approved AI usage.
Data restrictions.
Model access controls.
Human oversight.
AI vendor assessments.
Model monitoring.
Prompt/data protection.
AI security testing.

These controls can be incorporated into existing enterprise governance.

85. Control Design and Segregation of Duties

Some risks require separating responsibilities.

Example:

Developer
→ Creates Code

Reviewer
→ Approves Code

Deployment System
→ Deploys Code

One individual should not necessarily control every stage.

This reduces fraud and error risk.

86. Four-Eyes Principle

A control may require two people for sensitive actions.

Example:

Payment Change Request
        ↓
Person A Initiates
        ↓
Person B Approves
        ↓
Change Executed

This is sometimes called the four-eyes principle.

87. Least Privilege

Control design should frequently apply least privilege.

User
  ↓
Business Requirement
  ↓
Minimum Required Access
  ↓
Time-Limited Where Possible

This reduces attack surface.

88. Control Sustainability

A theoretically strong control may fail if it is too difficult to operate.

Example:

Control:

Manually review 500,000 cloud configuration records every day.

This is not sustainable.

Better:

Automated monitoring
+
Human review of exceptions

Good control design considers operational reality.

89. Cost vs Risk

Controls should be proportionate.

Conceptually:

Risk Reduction
      │
      ▼
Control Cost
      │
      ▼
Operational Impact
      │
      ▼
Decision

A control costing millions may not be justified for a low-impact risk.

90. Control Layering

A high-risk scenario may require several layers.

Example:

Privileged Access Risk

Layer 1:
Approval

Layer 2:
MFA

Layer 3:
PAM

Layer 4:
Time-Limited Access

Layer 5:
Session Recording

Layer 6:
SIEM Monitoring

Layer 7:
Quarterly Review

This creates resilient protection.

91. Control Gaps

A control gap exists when required protection is missing or insufficient.

Example:

Risk:
Data exfiltration

Required Capability:
Outbound monitoring

Current Control:
None

Result:
Control Gap

The gap should be assessed and remediated.

92. Control Gap Register

Organizations may track gaps.

Gap ID	Control	Risk	Owner	Target
CG-001	MFA	High	IAM	Sep 2026
CG-002	Logging	Critical	SOC	Aug 2026
CG-003	Backup Test	Medium	IT	Oct 2026

This supports remediation governance.

93. Control Remediation

A remediation plan should define:

Issue

Root Cause

Required Action

Owner

Target Date

Milestones

Evidence

Validation

Closing a ticket alone does not prove the control is fixed.

94. Root Cause Analysis

Repeated control failures may indicate deeper problems.

Example:

Problem:
Access reviews repeatedly late.

Surface Cause:
Managers do not complete them.

Root Causes:
Manual process
Poor notifications
Unclear ownership
Large review population

Remediation should address root causes.

95. Control Attestation

Some organizations require control owners to periodically attest:

I confirm this control is operating as documented.

Attestation may help governance, but it should not replace independent testing where testing is necessary.

96. Control Self-Assessment

A Control Self-Assessment may ask owners:

Is the control implemented?

Is it operating?

Has scope changed?

Have failures occurred?

Are exceptions open?

Is evidence available?

Does the control remain appropriate?

GRC can validate the responses.

97. Continuous Assurance

The long-term goal is to move from periodic evidence collection toward continuous assurance.

Traditional

Annual Evidence Collection
        ↓
Audit

Modern

Continuous Control Monitoring
        ↓
Automated Evidence
        ↓
Real-Time Compliance
        ↓
Continuous Assurance

This is particularly valuable in cloud environments.

98. Common Control Design Mistakes

Common mistakes include:

No clear control objective.
No owner.
Undefined scope.
Undefined frequency.
Vague wording.
No evidence.
Controls that cannot be tested.
Duplicate controls.
Excessively manual controls.
Controls disconnected from risk.
Controls copied directly from frameworks.
Missing dependencies.
Permanent exceptions.
No remediation process.

These problems create weak assurance.

99. Weak vs Strong Control Example

Weak

Backups should be tested.

Problems:

Who?
How often?
Which systems?
What constitutes successful testing?
What evidence is retained?

Strong

The Infrastructure Operations team performs quarterly restoration tests for systems classified as Critical. Test results, restoration time, failures, and remediation actions are documented and retained.

Now the control is testable.

100. Enterprise Control Architecture

A mature organization may structure controls like this:

Enterprise Risk
      │
      ▼
Policy
      │
      ▼
Control Objective
      │
      ▼
Enterprise Control
      │
      ├── Process Implementation
      ├── Technical Implementation
      └── Physical Implementation
      │
      ▼
Evidence
      │
      ▼
Testing
      │
      ▼
Assurance

This becomes the foundation of GRC operations.

101. Practical Control Design Scenario

Suppose a risk assessment identifies:

Employees may retain access after changing roles, creating excessive privileges and increasing the likelihood of unauthorized access.

Start with the risk.

Control Objective

Ensure user access remains appropriate to current job responsibilities.

Controls

Joiner Access Approval

Mover Access Revalidation

Quarterly Access Review

Privileged Access Review

Automated Role Removal

102. Design the Main Control

Control ID:
IAM-010

Control Name:
Periodic User Access Review

Objective:
Ensure access remains appropriate.

Owner:
IAM Director

Operators:
Application Owners

Frequency:
Quarterly for critical applications.

Type:
Detective

Population:
All active users assigned access to critical applications.

Evidence:
Completed access certification report.

Exceptions:
Tracked through IAM remediation workflow.

103. Implementation

The IAM platform:

Generates User Population
       ↓
Sends Review to Application Owner
       ↓
Owner Certifies Access
       ↓
Unnecessary Access Identified
       ↓
IAM Removes Access
       ↓
Evidence Retained

This operationalizes the control.

104. Testing

GRC may test:

Was the review completed?

Was the complete population included?

Was the reviewer authorized?

Were decisions documented?

Was inappropriate access removed?

Was remediation timely?

Is evidence retained?

This establishes assurance.

105. Framework Mapping

IAM-010 may then map to:

NIST
ISO 27001
SOC 2
PCI DSS
CIS Controls

One control supports multiple requirements.

106. Control Design Checklist

When designing a control, confirm:

What risk does it address?
What is the control objective?
What requirement drives it?
What is the control ID?
What is the control description?
Is it preventive, detective, corrective, or recovery?
Is it administrative, technical, or physical?
Is it manual, automated, or hybrid?
Who owns it?
Who operates it?
What is the scope?
What is the frequency?
What triggers it?
What population does it cover?
What evidence is produced?
How long is evidence retained?
What controls does it depend on?
How will it be monitored?
How will it be tested?
What happens if it fails?

107. GRC Professional Responsibilities

As a GRC professional, you may:

Define control objectives.
Draft control descriptions.
Map risks to controls.
Map policies to controls.
Map frameworks to controls.
Maintain control libraries.
Assign control owners.
Define evidence requirements.
Review control design.
Coordinate control implementation.
Track control gaps.
Manage exceptions.
Support control testing.
Monitor remediation.
Build control dashboards.
Rationalize duplicate controls.

Control management is one of the central operational responsibilities of enterprise GRC.

108. The Control Design Mindset

When reviewing any control, ask:

What risk are we reducing?

What outcome do we need?

Is this the right control?

Who owns it?

Who performs it?

What does it apply to?

How often does it operate?

Can we prove it happened?

Can we test it?

What happens if it fails?

Does another control depend on it?

Does it satisfy multiple requirements?

Can it be automated?

Is it sustainable?

Does the residual risk remain acceptable?

These questions help distinguish real controls from compliance paperwork.

Key Takeaways

Controls translate risks, policies, frameworks, and requirements into operational safeguards.
Control objectives define the desired outcome.
Controls may be preventive, detective, corrective, deterrent, or recovery focused.
Controls may also be administrative, technical, or physical.
Manual, automated, and hybrid controls have different operational characteristics.
Every control should have clear ownership, scope, frequency, and evidence.
Control descriptions should be specific, repeatable, measurable, and testable.
Design effectiveness determines whether a control can adequately address its intended risk.
Operating effectiveness determines whether the control actually performs as designed.
Compensating controls can provide alternative protection when primary controls cannot be implemented.
Control dependencies should be understood.
Evidence should be designed into controls rather than collected only during audits.
Enterprise control libraries provide a centralized source of truth.
Control mapping allows one enterprise control to support multiple frameworks.
Control automation and continuous monitoring can improve assurance.
GRC professionals help maintain the entire control lifecycle from design through remediation.

Knowledge Check

Before continuing, make sure you can answer these questions:

What is a security control?
What is a control objective?
How does a risk translate into a control?
What is the difference between preventive and detective controls?
What is a corrective control?
What is the difference between administrative, technical, and physical controls?
What is the difference between manual and automated controls?
What makes a good control description?
What is the difference between a control owner and control operator?
Why should control frequency be documented?
What makes control evidence reliable?
What is design effectiveness?
What is operating effectiveness?
What is a compensating control?
What is a control dependency?
What is an enterprise control library?
Why is control mapping important?
What is evidence by design?
What is continuous control monitoring?
What should happen when a control fails?

What’s Next?

➡️ Next: 08 — Control Testing & Effectiveness

In the next lesson, you will move from designing and implementing controls into determining whether those controls actually work.

You will learn how GRC and assurance teams evaluate control design effectiveness and operating effectiveness, define control populations, select samples, inspect evidence, perform inquiry, observation, inspection and reperformance, document test procedures, identify exceptions, classify control deficiencies, and reach defensible testing conclusions.

You will also learn how to build control testing workpapers, evidence matrices, testing schedules, remediation workflows, and continuous control monitoring practices that support internal audit, external audit, compliance assessments, and enterprise assurance.