"08 Control Testing & Effectiveness"

Designing a control does not prove that the control works.

Implementing a control does not prove that it operates consistently.

A mature GRC program must independently determine whether controls are:

Appropriately designed.
Fully implemented.
Operating consistently.
Producing reliable evidence.
Addressing the intended risk.
Meeting policy and framework requirements.

This process is known as control testing.

Control testing provides assurance that safeguards are not merely documented but are actually functioning.

A simple control assurance model is:

Risk
  ↓
Control Designed
  ↓
Control Implemented
  ↓
Control Operated
  ↓
Evidence Generated
  ↓
Control Tested
  ↓
Conclusion
  ↓
Remediation if Required

For GRC professionals, control testing is a fundamental skill because it supports:

Internal audit.
External audit.
Compliance assessments.
SOC examinations.
ISO certification.
PCI DSS assessments.
Risk management.
Control self-assessments.
Regulatory reviews.
Continuous assurance.

Learning Objectives

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

Explain the purpose of control testing.
Differentiate design effectiveness from operating effectiveness.
Understand control testing scope.
Define a control population.
Select appropriate samples.
Understand inquiry, observation, inspection, and reperformance.
Evaluate control evidence.
Develop control testing procedures.
Document testing workpapers.
Identify control exceptions.
Differentiate exceptions from deficiencies.
Assess severity and business impact.
Understand compensating controls.
Develop remediation plans.
Perform retesting.
Understand control testing frequency.
Build a testing calendar.
Understand continuous control monitoring.
Recognize common testing failures.
Reach defensible control conclusions.

1. What Is Control Testing?

Control testing is the process of evaluating whether a control is appropriately designed and operates as intended.

A tester seeks evidence to answer:

Can this control reasonably reduce the intended risk, and did it actually operate during the period being assessed?

For example:

Control:

Privileged access is reviewed quarterly.

Testing may determine:

Was the review performed?
Was the correct user population included?
Was the reviewer authorized?
Were inappropriate permissions identified?
Were those permissions removed?
Was evidence retained?

Control testing goes beyond confirming that a document or screenshot exists.

2. Why Control Testing Matters

Controls can fail for many reasons.

Examples include:

Poor control design.
Human error.
Incorrect configuration.
Missing system coverage.
Control owner turnover.
Process changes.
Automation failure.
Incomplete evidence.
Unapproved exceptions.

A control may appear strong on paper but provide little actual protection.

3. Control Assurance

Control assurance provides confidence that controls are functioning.

Conceptually:

Control Requirement
       ↓
Control Design
       ↓
Implementation
       ↓
Operation
       ↓
Testing
       ↓
Assurance

Testing connects control documentation with real-world execution.

4. Design Effectiveness

Design effectiveness asks:

If the control operates exactly as documented, is it capable of sufficiently addressing the intended risk?

Consider the risk:

Privileged accounts may be compromised.

Control:

Administrators receive annual cybersecurity awareness training.

Training is useful, but it may not sufficiently reduce privileged account compromise.

A stronger control might require:

MFA.
PAM.
Conditional access.
Privileged activity monitoring.

The original control may therefore have a design deficiency.

5. Operating Effectiveness

Operating effectiveness asks:

Did the control operate as designed throughout the required period?

Example:

Control:

All privileged accounts require MFA.

Design:
Appropriate.

Observed Population:
150 privileged accounts.

MFA Enabled:
143.

MFA Missing:
7.

The control is appropriately designed but did not operate completely.

This represents an operating effectiveness issue.

6. Design vs Operating Effectiveness

Design	Operation	Result
Effective	Effective	Control effective
Effective	Ineffective	Operating deficiency
Ineffective	Effective	Design deficiency
Ineffective	Ineffective	Significant control weakness

Both dimensions matter.

7. Control Testing Lifecycle

A structured testing process may follow:

1. Define Scope
      ↓
2. Understand Control
      ↓
3. Determine Testing Objective
      ↓
4. Obtain Population
      ↓
5. Select Sample
      ↓
6. Request Evidence
      ↓
7. Perform Testing
      ↓
8. Document Results
      ↓
9. Evaluate Exceptions
      ↓
10. Reach Conclusion
      ↓
11. Track Remediation
      ↓
12. Retest

Consistency improves defensibility.

8. Step 1 — Define Testing Scope

Before testing, define:

Which control is being assessed.
Which system or business process is in scope.
Which period is being tested.
Which framework or requirement applies.
Which locations or environments are included.
Whether design, operating effectiveness, or both are being tested.

Example:

Control:
IAM-010 Quarterly Privileged Access Review

Period:
1 January–31 December 2026

Systems:
Production applications

Objective:
Test design and operating effectiveness

9. Testing Period

The testing period should align with the assurance objective.

Example:

For an annual SOC 2 examination:

Review Period:

1 January 2026
through
31 December 2026

The tester needs sufficient evidence that the control operated throughout the period.

10. Step 2 — Understand the Control

Before testing, understand:

Control objective.
Risk addressed.
Control owner.
Operator.
Frequency.
Scope.
System used.
Evidence produced.
Exceptions.
Dependencies.

A tester should not begin sampling before understanding how the control actually works.

11. Control Walkthrough

A walkthrough helps the tester understand the process.

During a walkthrough, the control owner may explain:

Input
   ↓
Control Activity
   ↓
Approval
   ↓
System Update
   ↓
Evidence

The tester may follow one transaction from start to finish.

12. Example Walkthrough

Control:

New production access requires manager and application-owner approval.

Walkthrough:

Employee requests access
       ↓
Manager approves
       ↓
Application owner approves
       ↓
IAM provisions account
       ↓
Ticket captures evidence

The tester can verify that the documented process matches reality.

13. Step 3 — Define Testing Objective

Testing objectives should be explicit.

Example:

Determine whether privileged access reviews were completed quarterly for all in-scope applications, performed by authorized reviewers, and followed by timely removal of inappropriate access.

This tells the tester what evidence is required.

14. Testing Attributes

A control may have multiple attributes.

Example:

Control:

Production changes require approval before deployment.

Attributes might include:

1. Change ticket exists.

2. Request is properly documented.

3. Testing evidence exists.

4. Authorized approval was obtained.

5. Approval occurred before deployment.

6. Deployment was performed by authorized personnel.

Each sample may be tested against these attributes.

15. Step 4 — Define the Population

The population is the complete set of items subject to the control during the testing period.

Examples:

All production changes.
All terminated employees.
All privileged accounts.
All security incidents.
All vendors onboarded.
All access reviews.
All critical vulnerabilities.

Correct population identification is critical.

16. Population Example

Control:

All production changes require approval.

Testing period:

Q3 2026.

Population:

Total production changes:
1,248

The sample should be selected from this population.

17. Population Completeness

Before sampling, determine whether the population itself is complete.

Questions include:

Where did the data come from?
Does it include all systems?
Could records be excluded?
Can the population be reconciled?
Does the reporting logic make sense?

Testing an incomplete population may produce a false conclusion.

18. Information Produced by the Entity

Auditors often evaluate reports used during control testing.

For example:

Privileged User Report

Questions include:

Is the report complete?
Is it accurate?
Which system generated it?
Can filters be manipulated?
Are relevant fields included?

Evidence generated by the organization must itself be reliable.

19. Step 5 — Select the Sample

Testing every item may be impractical.

Therefore, testers often select a sample.

Sample size depends on:

Control frequency.
Population size.
Risk.
Testing methodology.
Expected failure rate.
Regulatory requirements.

There is no universal sample size that applies to every control.

20. Sampling Approaches

Common approaches include:

Random sampling.
Judgmental sampling.
Systematic sampling.
Stratified sampling.
Targeted sampling.

Different methods serve different purposes.

21. Random Sampling

Random sampling gives population items an opportunity to be selected without deliberate bias.

Useful when:

Population is relatively uniform.
Tester wants broad representation.

Example:

Population:
1,000 change requests

Random sample:
25 items

22. Judgmental Sampling

The tester deliberately selects items based on risk or significance.

Examples:

High-value transactions.
Privileged users.
Critical systems.
Emergency changes.
High-risk vendors.

This is useful for targeted assurance.

23. Stratified Sampling

Population is divided into meaningful groups.

Example:

Production Changes:

Standard       800
Normal         350
Emergency       98

The tester may sample from each category separately.

This helps ensure higher-risk groups are represented.

24. Testing Based on Frequency

Control frequency influences testing.

Examples:

Annual Control

One occurrence may exist.

Example:

Annual disaster recovery exercise

The tester may inspect that single occurrence.

Quarterly Control

There may be four occurrences.

The tester may inspect each quarter depending on methodology.

Daily Control

Thousands of occurrences may exist.

Sampling becomes necessary.

25. Step 6 — Request Evidence

Evidence should directly support control operation.

Examples include:

Approval records.
Tickets.
Screenshots.
Logs.
System exports.
Reports.
Meeting minutes.
Configuration settings.
Review certifications.
Training records.

Evidence requests should be specific.

26. Weak Evidence Request

Send evidence that access reviews happen.

This is vague.

27. Strong Evidence Request

Provide the Q2 2026 privileged access review for production applications, including the complete user population, reviewer certification, identified access removals, and evidence that remediation actions were completed.

This clearly defines expectations.

28. Evidence Quality

Reliable evidence should be:

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

A screenshot alone may not be sufficient if it lacks context.

29. Evidence Hierarchy

Different evidence types provide different levels of assurance.

Conceptually:

Reperformance
      ↑
Independent System Evidence
      ↑
System Reports
      ↑
Documentary Evidence
      ↑
Observation
      ↑
Inquiry

Inquiry alone normally provides weaker assurance than independently verified evidence.

30. Testing Techniques

Common testing techniques include:

Inquiry

Observation

Inspection

Reperformance

Testing often combines several techniques.

31. Inquiry

Inquiry means asking knowledgeable individuals how a control operates.

Example:

How do you identify employees who require access removal after termination?

Inquiry is useful for understanding processes.

However:

Inquiry alone generally does not prove a control operated.

It should usually be supported by other evidence.

32. Observation

Observation involves watching the control being performed.

Example:

The tester watches an IAM analyst process a termination request.

This confirms the process can operate as described.

However, observation only proves what happened while the tester was watching.

33. Inspection

Inspection involves examining documentation or system evidence.

Examples:

Tickets.
Reports.
Logs.
Approvals.
Configurations.
Access review records.

Inspection is one of the most common GRC testing methods.

34. Reperformance

Reperformance means independently executing part of the control or calculation.

Example:

Control owner states:

100% of terminated employees had access removed within 4 hours.

Tester may independently:

Obtain termination population
        ↓
Compare termination timestamps
        ↓
Compare account disablement timestamps
        ↓
Calculate compliance

This provides strong assurance.

35. Combined Testing Approach

A stronger test may combine:

Inquiry
+
Inspection
+
Reperformance

Example:

Ask the control owner to explain the process.
Inspect evidence for selected samples.
Independently verify timing or calculations.

This creates a more defensible conclusion.

36. Example — Access Review Testing

Control:

System owners review privileged access quarterly.

Test procedure:

1. Obtain list of in-scope applications.

2. Obtain four quarterly review populations.

3. Verify reviews occurred.

4. Verify reviewer authorization.

5. Verify full population was included.

6. Review identified access changes.

7. Verify unnecessary access was removed.

8. Inspect retained evidence.

9. Document exceptions.

37. Example — Termination Control Testing

Control:

Employee access must be disabled within four hours of termination.

Testing:

Population:
All terminated employees during Q2

Sample:
25 employees

For each sample:

Compare HR termination time
with
IAM account disablement time

Conclusion depends on whether required SLA was met.

38. Example — Vulnerability Management Testing

Control:

Critical vulnerabilities must be remediated within 15 days.

Tester may:

Obtain vulnerability population
        ↓
Select critical findings
        ↓
Review detection date
        ↓
Review remediation date
        ↓
Calculate elapsed days
        ↓
Compare with SLA

Exceptions require evaluation.

39. Example — Backup Testing

Control:

Critical applications must undergo quarterly restoration testing.

Tester may inspect:

Application population.
Test schedule.
Restoration report.
Recovery result.
RTO achieved.
Failures.
Remediation.

Simply proving backups exist is insufficient.

40. Testing a Preventive Automated Control

Example control:

MFA automatically prevents privileged login without a second factor.

Testing may include:

Inspect MFA configuration.
Verify privileged population.
Check exclusions.
Attempt authentication where appropriate.
Review policy settings.
Confirm configuration remained active.

Automated controls may require configuration-level testing.

41. Testing a Detective Automated Control

Example:

SIEM generates alerts for disabled security logging.

Testing may include:

Inspect Detection Rule

Verify Rule Enabled

Confirm In-Scope Systems

Trigger Test Event

Confirm Alert Generated

Confirm SOC Workflow

This can include reperformance.

42. Testing Manual Controls

Manual controls require close attention to:

Reviewer competency.
Evidence.
Timing.
Consistency.
Follow-up actions.

Example:

Monthly firewall rule review

A signed document alone may not prove the review was meaningful.

43. Review Controls

Management review controls require particular attention.

Example:

Security management reviews the monthly vulnerability dashboard.

The tester should determine:

What information was reviewed?
What criteria were used?
Were unusual items investigated?
Was the reviewer sufficiently knowledgeable?
Were follow-up actions documented?

A signature alone may not demonstrate an effective review.

44. Precision of Review

Consider:

Manager reviews monthly cybersecurity report.

This is vague.

Does the review detect:

One critical risk?
Ten overdue vulnerabilities?
An unusual vendor?
A major access anomaly?

Control design should define sufficient precision.

45. Control Testing Workpaper

Testing should be documented in a workpaper.

A typical workpaper may contain:

Control ID

Control Description

Control Objective

Risk

Control Owner

Testing Period

Testing Objective

Population

Sample

Testing Procedure

Evidence Reviewed

Exceptions

Conclusion

Tester

Reviewer

This creates traceability.

46. Example Testing Workpaper

Control ID:
IAM-010

Control:
Quarterly Privileged Access Review

Period:
2026

Population:
48 application reviews

Sample:
12 reviews

Procedure:
Inspect review completion, reviewer authorization, user population completeness, remediation, and evidence.

Exceptions:
2

Conclusion:
Partially Effective

47. Testing Documentation

Testing should allow another qualified reviewer to understand:

What was tested.
Why it was tested.
What evidence was reviewed.
How the sample was selected.
What exceptions occurred.
How the conclusion was reached.

A reviewer should not need to guess.

48. Step 7 — Identify Exceptions

An exception is an instance where the expected control requirement was not met.

Example:

Control:

All terminated employees must have access disabled within four hours.

Sample result:

Employee 1:
2 hours

Employee 2:
3 hours

Employee 3:
19 hours

Employee 3 represents an exception.

49. Exception Does Not Automatically Mean Failure

An exception must be evaluated.

Questions include:

Was it isolated?
What caused it?
Did compensating controls exist?
Was sensitive access involved?
How long did the exposure last?
Is the problem systemic?
Are similar exceptions likely?

Context matters.

50. Exception vs Deficiency

An exception is a specific deviation.

A deficiency is a broader weakness in control design or operation.

Example:

Exception:
One quarterly review was late.

Potential Deficiency:
Access reviews are frequently missed because no automated workflow or accountability exists.

Multiple exceptions may indicate a deficiency.

51. Design Deficiency

A design deficiency exists when the control itself is insufficient.

Example:

Risk:

Sensitive customer information may be publicly exposed.

Control:

Employees receive annual privacy training.

The control does not directly prevent or detect public cloud exposure.

The design is insufficient.

52. Operating Deficiency

An operating deficiency occurs when a properly designed control does not consistently operate.

Example:

Control:
Quarterly access review

Expected:
4 reviews

Completed:
2 reviews

The control design may be appropriate.

Execution is ineffective.

53. Evidence Deficiency

Sometimes the control owner states the control operated but cannot prove it.

Example:

Control:
Monthly security review

Claim:
Completed every month

Evidence:
None

The tester may be unable to conclude the control operated effectively.

Documentation and evidence matter.

54. Severity Assessment

Not all deficiencies have equal significance.

Factors may include:

Risk magnitude.
Control importance.
Number of failures.
Duration.
Affected systems.
Sensitive data.
Compensating controls.
Likelihood of recurrence.
Regulatory significance.

Severity methodology should be documented.

55. Example Severity Categories

An organization may classify findings as:

Low

Moderate

High

Critical

Audit environments may use terminology such as:

Deficiency.
Significant deficiency.
Material weakness.

Terminology varies by assurance context.

56. Root Cause Analysis

Do not stop at the visible failure.

Example:

Issue:
Access review late.

Possible root causes:

Manual reminders

Control owner changed roles

No backup reviewer

Poor population generation

Unclear escalation process

Effective remediation should address the root cause.

57. Five Whys Example

Problem:

Quarterly vendor assessments are frequently late.

Ask:

Why?
Reviewers miss deadlines.

Why?
Reminders are manual.

Why?
No centralized workflow exists.

Why?
Vendor risk process was created using spreadsheets.

Why?
No automation was funded.

Root cause may be process design rather than employee negligence.

58. Step 8 — Reach a Conclusion

Testing should produce a clear conclusion.

Possible outcomes may include:

Effective

Partially Effective

Ineffective

Unable to Determine

Organizations should define consistent criteria.

59. Effective Conclusion

Example:

The control was appropriately designed and operated effectively during the assessment period. No exceptions were identified.

60. Partially Effective Conclusion

Example:

The control design is appropriate; however, two of twelve samples did not contain evidence of timely remediation. The control is therefore assessed as partially effective.

61. Ineffective Conclusion

Example:

The required quarterly control was not performed during three of four quarters. Operating effectiveness was not demonstrated, and the control is assessed as ineffective.

Conclusions should be evidence based.

62. Unable to Determine

Sometimes insufficient evidence prevents testing.

Example:

The control owner could not provide evidence for the review period and the system does not retain historical records. Operating effectiveness could not be determined.

This is preferable to assuming success.

63. Compensating Controls

When a primary control fails, determine whether another control reduces the risk.

Example:

Primary control:

Prevent unauthorized access using MFA.

Failure:

Legacy system does not support MFA.

Compensating controls:

PAM gateway.
Network restrictions.
Session logging.
Daily review.
Dedicated admin endpoints.

Tester should evaluate whether these controls meaningfully reduce the risk.

64. Control Failure and Residual Risk

A control failure may increase residual risk.

Conceptually:

Expected Controls
       ↓
One Control Fails
       ↓
Reduced Protection
       ↓
Residual Risk Increases

GRC should consider whether risk reassessment is necessary.

65. Remediation Planning

A deficiency should normally have a remediation plan.

Required fields may include:

Finding

Root Cause

Risk

Remediation Action

Owner

Target Date

Status

Evidence of Completion

Vague remediation should be avoided.

66. Weak Remediation

Improve access reviews.

This provides little accountability.

67. Strong Remediation

Implement automated quarterly privileged access certification for all production applications, establish escalation for overdue reviews, and retain completed review evidence centrally by 31 December 2026.

This is specific and measurable.

68. Remediation Ownership

The remediation owner should have authority to complete the action.

Example:

Finding:
Incomplete privileged access reviews

Finding Owner:
IAM Director

Remediation Operator:
IAM Governance Team

GRC tracks progress but may not perform remediation itself.

69. Target Dates

Remediation dates should reflect risk.

Example:

Critical:
30 days

High:
60 days

Medium:
90 days

Low:
180 days

Actual timelines depend on organizational policy and circumstances.

70. Overdue Findings

Overdue findings should be monitored.

Example dashboard:

Severity	Open	Overdue
Critical	2	1
High	14	5
Medium	31	7
Low	20	2

Significant overdue issues may require escalation.

71. Retesting

A finding should not be closed solely because management says it has been fixed.

GRC or assurance teams should validate remediation.

Remediation Complete
       ↓
Evidence Submitted
       ↓
Retesting
       ↓
Effective?
       │
       ├── Yes → Close
       └── No → Reopen

This is essential for reliable closure.

72. Retesting Example

Original issue:

MFA missing for 18 privileged accounts.

Management remediation:

MFA enabled for all privileged users.

Retest:

Obtain current privileged account population

Verify MFA enrollment

Inspect exclusions

Test conditional access settings

Only then should closure be considered.

73. Control Testing Frequency

Controls do not all require the same testing frequency.

Testing may be:

Monthly.
Quarterly.
Semi-annual.
Annual.
Continuous.
Risk triggered.

Frequency should be risk based.

74. High-Risk Controls

High-risk or key controls may be tested more frequently.

Examples:

Privileged access.
Payment controls.
Critical backups.
Production change controls.
Regulatory controls.

A low-risk supporting control may require less frequent testing.

75. Risk-Based Testing

A testing schedule can consider:

Control Criticality
        +
Previous Failures
        +
Risk
        +
Regulatory Requirements
        +
Changes
        =
Testing Frequency

This focuses resources where assurance matters most.

76. Testing Calendar

A GRC team may maintain:

Control	Owner	Frequency	Next Test
IAM-002 MFA	IAM	Quarterly	Oct 2026
VUL-001 Scanning	Security	Semi-Annual	Dec 2026
BCP-004 DR Exercise	IT	Annual	Mar 2027
TPR-002 Vendor Review	Procurement	Annual	Jan 2027

This creates predictable assurance planning.

77. Control Testing Plan

An annual plan may define:

Controls in Scope:
125

Key Controls:
35

Quarter 1:
IAM + Governance

Quarter 2:
Vulnerability + Logging

Quarter 3:
Third Party + Application Security

Quarter 4:
Business Continuity + Physical Security

Planning prevents audit-season overload.

78. Internal Control Testing vs Internal Audit

GRC control testing and Internal Audit may perform different roles.

GRC may:

Monitor controls.
Coordinate testing.
Perform second-line assurance.

Internal Audit typically provides more independent third-line assurance.

First Line:
Operate Controls

Second Line:
Monitor & Challenge

Third Line:
Independent Assurance

79. First-Line Testing

Control owners may perform self-assessments.

Example:

IAM Manager confirms:

Control operating?
Yes

Exceptions?
2

Evidence available?
Yes

This provides management visibility but does not always replace independent testing.

80. Second-Line Testing

GRC or risk teams may independently validate control operation.

They may:

Inspect evidence.
Challenge owners.
Perform sampling.
Track findings.

This provides greater assurance.

81. Third-Line Testing

Internal Audit may independently assess both:

Control environment.
GRC oversight.

This provides assurance to senior management and the Board.

82. External Audit

External auditors may test controls for:

SOC reports.
Financial audits.
Regulatory reviews.
Certifications.

Internal GRC testing can improve audit readiness.

83. Audit Reliance

External auditors may sometimes rely on internal testing if it meets sufficient quality standards.

Factors may include:

Tester competence.
Independence.
Documentation quality.
Methodology.
Evidence quality.

Strong internal assurance can reduce duplicate work.

84. Control Testing and SOC 2

In a SOC 2 environment, testing may evaluate whether controls operated over a defined period.

Examples:

Access approvals.
Access revocation.
Vulnerability management.
Incident response.
Change management.
Monitoring.

Evidence must demonstrate operation during the reporting period.

85. Control Testing and ISO 27001

ISO environments may assess:

ISMS processes.
Selected controls.
Policies.
Risk treatment.
Internal audit.
Management review.
Continual improvement.

Testing supports internal audit and certification readiness.

86. Control Testing and PCI DSS

PCI DSS testing may include:

Technical configurations.
Access controls.
Authentication.
Network protections.
Logging.
Vulnerability scans.
Penetration testing.

Evidence requirements can be detailed.

87. Evidence Reuse

If one control supports several frameworks:

IAM-002 MFA
      │
      ├── ISO
      ├── SOC 2
      ├── PCI DSS
      └── NIST

one well-managed evidence set may support several assessments.

This reduces duplicated effort.

88. Common Evidence Repository

Organizations may centrally maintain:

Control ID

Evidence Name

Evidence Owner

Period

Source

Framework Mapping

Retention Period

This improves audit readiness.

89. Evidence Matrix

Example:

Control	Evidence	Owner	Frequency
IAM-002	MFA report	IAM	Quarterly
IAM-010	Access certifications	App Owners	Quarterly
VUL-001	Scan reports	Security	Weekly
BCP-004	Recovery test	IT	Quarterly

Evidence matrices make control expectations explicit.

90. Automated Evidence Collection

Modern platforms can automatically collect evidence.

Example:

Cloud Platform
      ↓
API Integration
      ↓
Configuration Data
      ↓
GRC Platform
      ↓
Control Evidence

This reduces manual work.

91. Continuous Control Monitoring

Traditional testing might occur once each year.

Continuous monitoring tests control conditions much more frequently.

Example:

Control:
No public cloud storage

Monitoring:
Continuous configuration scan

If exposure occurs:

Misconfiguration
      ↓
Detected
      ↓
Alert
      ↓
Ticket
      ↓
Remediation

This provides near-real-time assurance.

92. Continuous Testing vs Periodic Testing

Periodic Testing

Advantages:

Human judgment.
Broader contextual analysis.
Suitable for manual controls.

Limitations:

Point-in-time.
Failures may exist for months before detection.

Continuous Testing

Advantages:

Faster detection.
Automated coverage.
Large-scale monitoring.

Limitations:

Depends on reliable automation.
Not every control can be automated.

The strongest programs combine both.

93. Continuous Control Indicators

Examples include:

MFA Coverage

Encryption Coverage

Public Storage Exposure

Security Logging Coverage

Critical Vulnerability Aging

Endpoint Protection Coverage

These can continuously indicate control health.

94. Control Health Dashboard

Example:

Control	Target	Actual	Status
MFA Coverage	100%	99.7%	Review
Encryption	100%	100%	Effective
Logging	100%	96%	Action
EDR	99%	98.8%	Review

Dashboards help prioritize assurance activity.

95. Testing Automated Controls

Automated controls require attention to underlying systems.

Questions include:

Is the configuration correct?
Who can change it?
Are changes approved?
Is the system reliable?
Are integrations complete?
Are exceptions possible?

A technically automated control can still fail due to poor governance.

96. IT General Controls

Automated application controls often depend on broader IT General Controls, or ITGCs.

Examples include:

Logical access.
Change management.
Computer operations.
Backup.
System development controls.

If ITGCs are weak, reliance on automated controls may be reduced.

97. Example Dependency

Automated control:

System prevents unapproved payments.

But if developers can modify production code without approval:

Weak Change Management
        ↓
Automated Control Could Be Altered

The reliability of the automated control depends partly on change-management controls.

98. Control Testing Exceptions Register

Testing findings may be centrally tracked.

ID	Control	Finding	Severity	Owner	Due
F-001	IAM-010	Missing reviews	High	IAM	Oct 2026
F-002	LOG-004	Missing log source	High	SOC	Sep 2026
F-003	BCP-004	Late recovery test	Medium	IT	Nov 2026

This supports remediation governance.

99. Finding Aging

GRC should monitor how long findings remain unresolved.

Example:

High Finding

Target:
60 days

Current Age:
143 days

This may require escalation.

100. Repeat Findings

A repeat finding occurs when the same problem returns.

Example:

2024 Audit:
Access reviews late

2025 Audit:
Access reviews late

2026 Audit:
Access reviews late

This may indicate remediation did not address root cause.

Repeat findings deserve increased attention.

101. Systemic Deficiencies

Several control failures may share one root cause.

Example:

Access Review Failure
        │
Provisioning Failure
        │
Termination Failure
        │
        ▼
Common Root Cause:

Poor Identity Governance

GRC should recognize systemic problems rather than treating every failure independently.

102. Testing Exceptions Against Risk Appetite

Control deficiencies should be evaluated against business risk.

A small issue in a low-risk process may be acceptable.

The same issue in a payment environment may be significant.

Control Failure
      +
Business Criticality
      +
Threat Exposure
      +
Compensating Controls
      =
Risk Significance

103. Control Testing Quality Review

Before finalizing testing, verify:

Correct control tested.
Testing period correct.
Population complete.
Sample selection documented.
Procedures appropriate.
Evidence sufficient.
Exceptions documented.
Conclusion supported.
Finding severity justified.
Workpaper reviewed.

Quality review improves consistency.

104. Reviewer Responsibilities

A reviewer should challenge:

Was the right population used?
Was the sample sufficient?
Does evidence support the result?
Are exceptions properly evaluated?
Is the conclusion too strong or too weak?
Is remediation reasonable?

Independent review improves assurance quality.

105. Common Control Testing Mistakes

Common mistakes include:

Testing policy existence instead of control operation.
Relying only on inquiry.
Using incomplete populations.
Accepting screenshots without context.
Selecting biased samples unintentionally.
Ignoring control dependencies.
Failing to document test steps.
Closing findings without retesting.
Accepting management statements without evidence.
Testing controls without understanding the risk.
Treating every exception as identical.
Focusing on compliance while ignoring effectiveness.

106. Screenshot-Only Testing

A screenshot may show:

MFA = Enabled

But it may not answer:

For which users?
Since when?
Are exclusions configured?
Was MFA enabled throughout the period?
Can administrators bypass it?

Evidence should be evaluated critically.

107. Inquiry-Only Testing

Control owner:

Yes, we perform quarterly reviews.

Tester:

Okay.

This is not adequate assurance.

Better:

Inquiry
+
Review Documentation
+
Inspect Evidence
+
Validate Population
+
Check Remediation

108. Testing the Wrong Control

Suppose the risk is unauthorized access.

Tester reviews:

Security Awareness Training

but ignores:

MFA
Access Approval
Access Reviews
Termination

The testing may not address the key controls that mitigate the risk.

Testing should be risk aligned.

109. Practical Scenario — Access Control

Control:

All privileged access is reviewed quarterly.

Population:

Applications:
40

Quarterly Reviews:
160

Tester selects:

20 reviews

Results:

18:
Complete and timely

1:
Completed 25 days late

1:
No evidence

The tester must evaluate significance.

110. Analyze the Exceptions

Questions:

Were critical systems affected?
Was excessive access discovered?
Was the missing review isolated?
Is the process mostly automated?
Has this happened before?
What compensating monitoring exists?

Testing conclusions require judgment.

111. Example Conclusion

The control is appropriately designed; however, two of twenty sampled reviews did not meet the required execution criteria. One review was materially late and one lacked evidence of completion. Operating effectiveness is assessed as partially effective, and remediation is required to strengthen review tracking and escalation.

This clearly connects evidence to conclusion.

112. Practical Scenario — Automated MFA

Control:

MFA is enforced for all production administrators.

Testing identifies:

Admin Accounts:
215

MFA Protected:
210

Exceptions:
5

Further review determines:

3:
Approved emergency accounts

2:
Unapproved legacy accounts

The tester should not treat all five identically.

113. Evaluate Approved Exceptions

Approved emergency accounts may have:

Restricted access.
Vaulted passwords.
Monitoring.
Break-glass procedures.
Periodic testing.

These may represent properly governed exceptions.

The two unapproved accounts represent control failures.

114. Practical Scenario — Vulnerability Management

Control:

Critical vulnerabilities must be remediated within 15 days.

Population:

Critical vulnerabilities:
126

Sample:

Results:

22 remediated within SLA

2 remediated late

1 remains open after 47 days

The open vulnerability may represent greater residual risk.

115. Control Testing Conclusion Framework

For each control, ask:

1. Is the control appropriately designed?

2. Is the control fully implemented?

3. Did the control operate at the required frequency?

4. Did it cover the complete scope?

5. Was reliable evidence produced?

6. Were exceptions identified?

7. Were exceptions appropriately managed?

8. Does the control reduce the intended risk?

9. What residual risk remains?

10. Is remediation required?

116. GRC Professional Responsibilities

As a GRC professional, you may:

Build control testing plans.
Coordinate walkthroughs.
Define testing procedures.
Obtain control populations.
Select samples.
Request evidence.
Perform control testing.
Document workpapers.
Identify exceptions.
Evaluate control deficiencies.
Track remediation.
Perform retesting.
Build findings dashboards.
Support internal audits.
Support external audits.
Maintain evidence repositories.
Develop continuous monitoring.

Control testing transforms the control library into an active assurance program.

117. From Compliance to Assurance

A weak program asks:

Do we have the control?

A stronger program asks:

Is it implemented?

A mature program asks:

Does it actually work?

And an advanced program asks:

Can we continuously demonstrate that it works?

This is the evolution from checkbox compliance to continuous assurance.

Key Takeaways

Control testing determines whether safeguards are appropriately designed and actually operating.
Design effectiveness and operating effectiveness must be evaluated separately.
Testing should begin with clear scope, objectives, and understanding of the control.
Complete populations are critical to reliable testing.
Sampling should reflect control frequency, risk, and testing methodology.
Inquiry alone rarely provides sufficient assurance.
Observation, inspection, and reperformance provide stronger evidence.
Evidence must be complete, accurate, relevant, timely, and traceable.
Control exceptions should be evaluated in business and risk context.
An exception is not automatically equivalent to a control deficiency.
Deficiencies may relate to design, operation, evidence, scope, or implementation.
Control findings should have owners, remediation plans, and target dates.
Remediation should be retested before findings are closed.
Testing frequency should be risk based.
Continuous control monitoring can provide faster visibility into control failures.
Good testing documentation should allow an independent reviewer to understand and reproduce the conclusion.
Control testing is a core component of enterprise assurance.

Knowledge Check

Before continuing, make sure you can answer these questions:

What is control testing?
What is the difference between design and operating effectiveness?
What is a control walkthrough?
What is a control population?
Why must population completeness be validated?
What is sampling?
What factors influence sample selection?
What are inquiry, observation, inspection, and reperformance?
Why is inquiry alone normally insufficient?
What makes control evidence reliable?
What is a control exception?
What is the difference between an exception and a deficiency?
What is a design deficiency?
What is an operating deficiency?
How should deficiency severity be evaluated?
Why is root-cause analysis important?
Why should remediation be retested?
What is risk-based control testing?
What is continuous control monitoring?
How does control testing support enterprise assurance?

What’s Next?

➡️ Next: 09 — Audit & Assurance Fundamentals

In the next lesson, you will move from individual control testing into the broader world of audit and assurance.

You will learn how internal audit, external audit, compliance assessments, certification audits, attestation engagements, first-line testing, second-line assurance, and third-line independent audit work together.

You will also learn how organizations plan audits, define scope, prepare evidence, manage auditor requests, conduct walkthroughs, respond to findings, track corrective actions, and maintain year-round audit readiness.

This will prepare you for the practical audit coordination and evidence-management responsibilities commonly performed by GRC Analysts and Managers.