"09 Audit & Assurance Fundamentals"

Organizations create policies, identify risks, implement controls, and test those controls.

But leadership, customers, regulators, investors, and other stakeholders often need something more:

Independent confidence that those controls actually work.

This is where audit and assurance become important.

Audit and assurance activities provide structured evaluation of an organization’s:

Governance.
Risk management.
Security controls.
Compliance obligations.
Business processes.
Technology environments.
Internal control environment.

For a GRC professional, audits are not occasional events.

Supporting audits, managing evidence, coordinating stakeholders, responding to findings, and maintaining continuous audit readiness are core GRC responsibilities.

A simplified assurance lifecycle looks like:

Business & Regulatory Requirements
            ↓
         Risks
            ↓
        Controls
            ↓
    Control Operation
            ↓
     Control Testing
            ↓
      Audit / Assurance
            ↓
         Findings
            ↓
       Remediation
            ↓
     Continuous Improvement

The objective is not simply to “pass an audit.”

The objective is to provide credible assurance that risks are appropriately governed and controlled.

Learning Objectives

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

Explain the purpose of audit and assurance.
Differentiate audit, assessment, certification, and attestation.
Understand internal and external audits.
Understand the Three Lines Model.
Explain audit independence and objectivity.
Understand audit planning and scoping.
Identify audit criteria.
Understand materiality and risk-based auditing.
Participate in audit walkthroughs.
Manage evidence and auditor requests.
Understand sampling and audit testing.
Differentiate observations, exceptions, and findings.
Understand finding severity.
Develop management responses.
Track corrective actions.
Understand audit closure and follow-up.
Support external audits and certification assessments.
Understand audit readiness.
Build an audit evidence repository.
Recognize common audit-management mistakes.

1. What Is an Audit?

An audit is a structured examination of an organization’s activities, controls, processes, or systems against defined criteria.

The auditor typically asks:

What should happen?
        ↓
What actually happens?
        ↓
What evidence proves it?
        ↓
Does it meet the criteria?

For example:

Requirement:

Privileged access must be periodically reviewed.

The auditor may evaluate:

Whether the requirement is documented.
Whether a control exists.
Whether reviews occurred.
Whether the population was complete.
Whether appropriate reviewers performed them.
Whether identified access was removed.
Whether evidence was retained.

2. What Is Assurance?

Assurance is the confidence provided to stakeholders regarding the reliability or effectiveness of something.

For cybersecurity and GRC, assurance may relate to:

Security controls.
Risk management.
Compliance.
Financial reporting.
Privacy.
Business continuity.
Technology operations.

Conceptually:

Management Claims
       ↓
Controls & Evidence
       ↓
Independent Evaluation
       ↓
Assurance
       ↓
Stakeholder Confidence

3. Audit vs Assurance

Audit is one mechanism for providing assurance.

Assurance is broader.

Examples of assurance activities include:

Internal audit.
External audit.
Control testing.
Compliance assessments.
Certification assessments.
Penetration testing.
Risk assessments.
Independent security reviews.

The level and nature of assurance varies.

4. Why Organizations Are Audited

Organizations may undergo audits because of:

Regulatory requirements.
Certification objectives.
Customer requirements.
Contractual obligations.
Financial reporting requirements.
Internal governance.
Board requirements.
Risk-management programs.
Acquisition due diligence.

Examples may include:

SOC 2

ISO/IEC 27001

PCI DSS

Internal Security Audit

Regulatory Examination

Financial IT Audit

5. Audit Criteria

Every audit needs criteria.

Audit criteria define what the organization is being evaluated against.

Examples include:

Internal policies.
Procedures.
Laws.
Regulations.
Contracts.
Security frameworks.
Standards.
Control requirements.

Conceptually:

Audit Subject
     +
Audit Criteria
     =
Assessment Basis

Without defined criteria, conclusions become subjective.

6. Audit Scope

The audit scope defines the boundaries of the audit.

Scope may specify:

Business units.
Systems.
Locations.
Processes.
Applications.
Data.
Controls.
Time period.

Example:

Audit:

Identity & Access Management

Scope:

Production cloud environment

Systems:

AWS
Azure
Corporate Identity Platform

Period:

1 January – 31 December

Scope determines what auditors can reasonably conclude.

7. Why Scope Matters

Consider:

The organization passed a security audit.

This statement means very little without knowing the scope.

Perhaps the audit covered:

One Product
One Region
One Business Unit

while the organization operates:

50 Products
20 Countries
15 Business Units

Always understand the scope before interpreting assurance.

8. Types of Audit

GRC professionals commonly encounter:

Internal Audit

External Audit

Compliance Audit

Certification Audit

Financial / IT Audit

Regulatory Examination

Supplier Audit

Each has different objectives.

9. Internal Audit

Internal Audit provides independent assurance within the organization.

Internal auditors may evaluate:

Governance.
Risk management.
Internal controls.
Cybersecurity.
IT operations.
Financial controls.
Compliance.
Business processes.

Internal Audit usually reports to senior governance structures such as an Audit Committee or Board.

10. Internal Audit Objectives

Internal Audit may ask:

Are risks understood?

Are controls appropriately designed?

Are controls operating?

Is governance effective?

Are policies followed?

Are significant weaknesses being addressed?

Internal Audit should remain sufficiently independent from the processes it evaluates.

11. External Audit

External audits are performed by independent organizations outside the company.

Examples include:

SOC examinations.
ISO certification audits.
Financial audits.
Certain compliance assessments.

External assurance may be required by:

Customers.
Regulators.
Investors.
Business partners.
Contracts.

12. Internal vs External Audit

Internal Audit	External Audit
Part of organizational assurance	Independent external organization
Focus can be broad	Usually defined engagement
Supports management and Board	Supports specified external/internal stakeholders
May assess emerging risks	Usually evaluates defined criteria
Ongoing audit program	Often periodic

Both can provide important assurance.

13. Compliance Assessment

A compliance assessment determines whether requirements are being met.

Examples:

PCI DSS Assessment

Privacy Compliance Review

Regulatory Compliance Assessment

The focus is generally:

Are applicable requirements satisfied?

14. Certification Audit

A certification audit evaluates whether an organization conforms to the requirements of a certifiable standard.

Example:

ISO/IEC 27001

The organization may undergo:

Initial Certification
      ↓
Surveillance Audits
      ↓
Recertification

Certification does not mean the organization has zero cybersecurity risk.

It demonstrates conformity within the defined certification scope.

15. Attestation

An attestation engagement provides a formal conclusion about assertions or subject matter.

SOC reporting is a common example.

The organization describes controls.

An independent practitioner evaluates those controls according to applicable criteria.

16. SOC 1 and SOC 2

SOC engagements are common in enterprise GRC.

SOC 1

Focuses on controls relevant to user entities’ internal control over financial reporting.

SOC 2

Focuses on controls related to the Trust Services Criteria.

These include:

Security.
Availability.
Processing Integrity.
Confidentiality.
Privacy.

We will cover SOC reporting in greater depth later in the learning path.

17. Type I vs Type II

A simplified distinction:

Type I

Evaluates control design at a specific point in time.

Control Design
      ↓
Specific Date

Type II

Evaluates design and operating effectiveness over a defined period.

Control Design
      +
Control Operation
      ↓
Defined Period

Type II therefore provides evidence about control operation across time.

18. Regulatory Examination

Regulators may examine organizations to determine compliance with legal or supervisory requirements.

Regulatory examinations can involve:

Documentation review.
Interviews.
Control testing.
Data requests.
Governance review.
Finding remediation.

Failure to address significant regulatory findings may have serious consequences.

19. Supplier Audits

Customers may audit suppliers where contracts permit it.

Areas may include:

Information security.
Privacy.
Business continuity.
Cloud security.
Data handling.
Subcontractor management.

Organizations may also rely on independent assurance reports rather than conducting direct audits.

20. The Three Lines Model

A useful governance concept is the Three Lines Model.

First Line
Business & Operations
        ↓
Own and Operate Controls

Second Line
Risk / Compliance / GRC
        ↓
Monitor, Guide & Challenge

Third Line
Internal Audit
        ↓
Independent Assurance

Each line has a different role.

21. First Line

The first line includes teams that own risks and operate controls.

Examples:

IT.
Cloud Engineering.
IAM.
Security Operations.
HR.
Finance.
Procurement.

Responsibilities include:

Own Risk

Operate Controls

Maintain Evidence

Remediate Problems

22. Second Line

The second line may include:

GRC.
Enterprise Risk.
Compliance.
Privacy.
Security Governance.

Responsibilities may include:

Define Frameworks

Monitor Risk

Challenge Control Owners

Perform Compliance Reviews

Track Findings

Report Risk

The second line supports oversight.

23. Third Line

Internal Audit provides independent assurance.

Internal Audit evaluates:

First-Line Controls
        +
Second-Line Oversight
        ↓
Independent Assurance

This provides leadership with an independent perspective.

24. Independence

Auditor independence is fundamental.

A person should not generally design, operate, approve, and independently audit the same control.

Example:

Person A

Designs Control
Operates Control
Tests Control
Approves Result

This creates a conflict.

A better model separates responsibilities.

25. Objectivity

Auditors should evaluate evidence objectively.

Conclusions should be based on:

Defined criteria.
Sufficient evidence.
Consistent methodology.
Professional judgment.

Auditors should not change conclusions simply because a finding is inconvenient.

26. Audit Risk

Auditors cannot inspect everything.

There is always a possibility that significant problems may not be detected.

This is one reason audits use:

Risk assessment.
Sampling.
Materiality.
Professional judgment.

Audit provides assurance, not absolute certainty.

27. Risk-Based Auditing

Modern audits often prioritize areas of greater risk.

Conceptually:

Business Criticality
       +
Threat Exposure
       +
Control Weakness
       +
Regulatory Impact
       =
Audit Priority

High-risk processes receive greater attention.

28. Audit Universe

Large organizations may maintain an audit universe.

This is an inventory of auditable areas.

Examples:

Identity Management

Cloud Security

Security Operations

Vendor Risk

Privacy

Business Continuity

Application Security

Financial Systems

HR Processes

Risk assessments help determine which areas are audited.

29. Annual Audit Plan

Internal Audit may develop an annual plan.

Example:

Quarter	Audit
Q1	Identity & Access Management
Q2	Cloud Security
Q3	Third-Party Risk
Q4	Incident Response

Plans may change when new risks emerge.

30. Audit Planning

Before fieldwork begins, auditors typically perform planning.

Planning may include:

Understand Business
      ↓
Identify Risks
      ↓
Define Objectives
      ↓
Define Scope
      ↓
Identify Criteria
      ↓
Identify Controls
      ↓
Develop Audit Program

Good planning improves audit efficiency.

31. Audit Objective

An audit objective describes what the audit intends to determine.

Example:

Determine whether identity and access management controls are appropriately designed and operating effectively to prevent unauthorized access to critical production systems.

This is much more useful than:

Audit IAM.

32. Audit Program

An audit program defines procedures auditors intend to perform.

Example:

1. Review IAM policies.

2. Understand provisioning process.

3. Test new-user approvals.

4. Test privileged access.

5. Test access reviews.

6. Test termination controls.

7. Evaluate MFA.

8. Review exceptions.

9. Assess monitoring.

The program provides structure.

33. Audit Announcement

Audits may begin with an announcement or engagement notification.

It may include:

Audit objective.
Scope.
Timing.
Auditor contacts.
Required stakeholders.
Initial documentation request.

GRC may coordinate the organization’s response.

34. Opening Meeting

An audit often begins with an opening meeting.

Participants may include:

Auditors.
GRC.
Control owners.
Security leadership.
IT.
Relevant business teams.

Topics may include:

Scope

Timeline

Responsibilities

Communication

Evidence Requests

Escalation

Clear expectations reduce confusion later.

35. Prepared-By-Client Requests

Auditors commonly issue evidence request lists.

These are often referred to as PBC requests — Prepared by Client.

Examples:

PBC-001
Information Security Policy

PBC-002
User Access Population

PBC-003
Privileged Access Review

PBC-004
Vulnerability Scan Reports

GRC often coordinates these requests.

36. Evidence Request Tracker

A tracker might contain:

ID	Request	Owner	Due	Status
PBC-001	Security Policy	GRC	Aug 10	Complete
PBC-002	User List	IAM	Aug 12	Open
PBC-003	Scan Report	Security	Aug 12	Complete
PBC-004	DR Test	IT	Aug 15	In Progress

This becomes critical during large audits.

37. Evidence Management

Audit evidence should be:

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

Evidence should answer the auditor’s request without creating unnecessary ambiguity.

38. Evidence Repository

A centralized repository may be organized:

Audit
│
├── Governance
├── IAM
├── Logging
├── Vulnerability Management
├── Incident Response
├── Business Continuity
└── Third-Party Risk

Each item should be clearly labeled.

39. Evidence Naming

Poor naming:

Screenshot1.png

FinalReport_NEW2.xlsx

AccessDataLatest.xlsx

Better:

IAM-010_Q2-2026_Privileged-Access-Review.pdf

Consistent naming improves traceability.

40. Evidence Freshness

Evidence should match the period under audit.

For example:

Audit period:

January–December 2026

Providing a configuration screenshot from 2024 may not prove the control operated in 2026.

Always validate evidence dates.

41. Evidence Minimization

Do not provide unnecessary sensitive information.

If an auditor needs:

User ID
Role
Approval

they may not need:

Passwords
Authentication Secrets
Unrelated Personal Information

Evidence sharing should follow security and privacy principles.

42. Evidence Chain

Strong audit evidence often creates traceability.

Example:

Access Request
      ↓
Manager Approval
      ↓
Application Approval
      ↓
Provisioning
      ↓
System Record
      ↓
Periodic Review

Auditors can follow the control lifecycle.

43. Walkthroughs

Auditors use walkthroughs to understand processes.

A walkthrough may involve:

Process owner explanation.
Screen sharing.
System demonstration.
Review of one example.
Discussion of exceptions.

The objective is to understand how the control works in practice.

44. Preparing for Walkthroughs

Control owners should know:

What is the control?

Why does it exist?

Who performs it?

How often?

Which systems are involved?

What evidence is produced?

What happens when something fails?

GRC can help prepare owners before auditor meetings.

45. Walkthrough Example

Control:

Employee access is disabled after termination.

Walkthrough:

HR enters termination
       ↓
Identity system receives event
       ↓
Account disabled
       ↓
Application access revoked
       ↓
Log retained

Auditor may request one completed example.

46. Auditor Interviews

During interviews:

Answer the question asked.
Be accurate.
Avoid speculation.
Explain actual processes.
Identify supporting evidence.
Correct misunderstandings promptly.

Do not invent answers to satisfy the auditor.

If information requires confirmation, confirm it with the appropriate owner.

47. Audit Testing

After understanding controls, auditors perform testing.

Testing may include:

Inquiry

Observation

Inspection

Reperformance

Sampling

These techniques should already be familiar from control testing.

48. Sampling

Auditors usually cannot inspect every transaction.

They may select samples from:

Access requests.
Employee terminations.
Production changes.
Vulnerabilities.
Vendors.
Security incidents.

Sampling provides evidence about the larger population.

49. Sample Request Example

Auditor requests:

Population:
850 production changes

Samples Selected:
25

The organization must provide supporting evidence for those 25 changes.

50. Audit Sampling Surprise

Organizations sometimes prepare evidence for a few known examples.

Then the auditor independently selects different samples.

This is why audit readiness requires:

Controls to operate correctly for the whole population — not only for examples prepared for auditors.

51. Audit Findings

A finding identifies a condition that does not meet expected criteria or presents a control concern.

A strong finding usually explains:

Criteria
   ↓
Condition
   ↓
Cause
   ↓
Risk / Effect
   ↓
Recommendation

This structure helps management understand the problem.

52. Criteria

Criteria describe what should happen.

Example:

Corporate policy requires privileged access reviews every quarter.

53. Condition

Condition describes what auditors observed.

Example:

Two of four quarterly privileged access reviews were not completed.

54. Cause

Cause explains why the issue occurred.

Example:

The review process relies on manual calendar reminders and no escalation mechanism exists.

55. Effect or Risk

The finding should explain why the issue matters.

Example:

Excessive privileged access may remain undetected, increasing the risk of unauthorized activity within critical systems.

56. Recommendation

Example:

Implement centralized access-certification workflows with automated reminders, escalation, and evidence retention.

Recommendations should address root causes where possible.

57. Observation vs Finding

Not every auditor comment is necessarily a formal finding.

An observation may identify:

Improvement opportunity.
Emerging risk.
Minor process weakness.

A finding usually represents a more formal control or compliance issue.

Terminology varies between organizations and audit types.

58. Finding Severity

Findings may be categorized as:

Critical

High

Medium

Low

or other organization-specific classifications.

Severity may consider:

Business impact.
Likelihood.
Data sensitivity.
Regulatory implications.
Control importance.
Duration.
Scope.
Compensating controls.

59. High-Severity Example

Finding:

Production administrator accounts do not require MFA.

Potential consequences:

Credential Theft
      ↓
Privileged Access
      ↓
Production Compromise
      ↓
Customer Impact

This could represent significant risk.

60. Lower-Severity Example

Finding:

One internal policy review was completed two weeks after its scheduled review date.

If no material control impact exists, severity may be lower.

Context matters.

61. Management Response

Management should respond to audit findings.

A response may include:

Agreement / Disagreement

Root Cause

Remediation Action

Owner

Target Date

Responses should be specific.

62. Weak Management Response

Management will improve the process.

This provides little accountability.

63. Strong Management Response

Management agrees with the finding. The IAM team will implement automated quarterly privileged-access certifications for all production applications, including escalation for overdue reviews and centralized evidence retention, by 31 December 2026.

This is measurable.

64. Disagreeing With a Finding

Management does not have to agree with every finding.

However, disagreement should be evidence based.

For example:

Auditor used incomplete population.
Control was outside agreed scope.
Compensating controls were not considered.
Requirement was incorrectly interpreted.

GRC can help coordinate factual responses.

65. Do Not Hide Findings

Attempting to conceal control weaknesses can create greater risk than the original problem.

A mature organization:

Identifies Weakness
      ↓
Assesses Risk
      ↓
Creates Remediation
      ↓
Tracks Progress
      ↓
Validates Closure

Transparency strengthens governance.

66. Corrective Action Plan

A corrective action plan may contain:

Field	Example
Finding ID	AUD-2026-014
Severity	High
Owner	IAM Director
Action	Implement automated reviews
Target	Dec 31
Status	In Progress

This enables structured tracking.

67. Finding Lifecycle

Finding Identified
       ↓
Management Response
       ↓
Remediation Plan
       ↓
Action Implemented
       ↓
Evidence Submitted
       ↓
Validation / Retest
       ↓
Closure

A finding should not disappear simply because the target date arrives.

68. Remediation Validation

Before closure, assurance teams may verify:

Remediation actually occurred.
Root cause was addressed.
New control operates.
Evidence exists.
Residual risk is acceptable.

This may require retesting.

69. Repeat Findings

A repeat finding occurs when an issue returns.

Example:

2024
Late Access Reviews

2025
Late Access Reviews

2026
Late Access Reviews

This suggests remediation was ineffective.

Repeat findings may receive increased management attention.

70. Overdue Findings

GRC should track overdue remediation.

Example:

Severity	Open	Overdue
Critical	1	1
High	12	4
Medium	28	6
Low	17	2

Significant overdue findings may require escalation.

71. Risk Acceptance

Sometimes management may choose not to remediate immediately.

Possible reasons:

System will soon be retired.
Remediation cost is disproportionate.
Compensating controls reduce exposure.
Business dependency prevents immediate change.

In such cases:

Finding
   ↓
Risk Assessment
   ↓
Risk Acceptance
   ↓
Authorized Approver
   ↓
Expiration / Review

Audit findings should not simply be ignored.

72. Audit Report

At the end of an audit, a report may contain:

Executive summary.
Scope.
Objectives.
Methodology.
Overall conclusion.
Findings.
Severity.
Management responses.
Remediation dates.

Reports should clearly communicate risk.

73. Executive Summary

Senior leaders often focus on:

Overall Control Environment

Critical Findings

High-Risk Issues

Repeat Findings

Overdue Remediation

Major Themes

GRC should be able to translate technical issues into business language.

74. Closing Meeting

Auditors may hold a closing meeting to discuss:

Preliminary findings.
Management responses.
Outstanding evidence.
Report timeline.
Remediation expectations.

This is an opportunity to correct factual inaccuracies before final reporting.

75. Audit Follow-Up

Audit activity continues after the report.

Follow-up includes:

Track Findings
      ↓
Monitor Due Dates
      ↓
Collect Remediation Evidence
      ↓
Retest
      ↓
Close

Finding management is a major GRC responsibility.

76. Audit Readiness

Audit readiness means controls and evidence remain prepared throughout the year.

Weak approach:

Audit Announced
      ↓
Panic
      ↓
Search for Evidence
      ↓
Create Missing Documentation

Mature approach:

Controls Operate
      ↓
Evidence Generated
      ↓
Evidence Retained
      ↓
Controls Monitored
      ↓
Audit Arrives
      ↓
Evidence Ready

77. Continuous Audit Readiness

Continuous readiness may include:

Central control library.
Assigned control owners.
Evidence calendar.
Automated evidence collection.
Control testing.
Finding tracking.
Compliance dashboards.
Periodic readiness assessments.

The goal is to make audit preparation routine rather than disruptive.

78. Evidence Calendar

Example:

Evidence	Frequency	Owner
Access Review	Quarterly	IAM
Vulnerability Report	Monthly	Security
Training Report	Annual	HR
Vendor Review	Annual	Procurement
DR Test	Annual	IT

GRC can track evidence before auditors request it.

79. Audit Evidence Repository

A mature repository may organize evidence by control rather than by audit.

Enterprise Control Library
          ↓
      Control ID
          ↓
Evidence by Period
          ↓
Framework Mapping

Example:

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

This allows evidence reuse.

80. Evidence Reuse

Suppose:

IAM-002
Privileged MFA

maps to:

ISO 27001

SOC 2

PCI DSS

NIST

One reliable evidence package may support several assessments.

This dramatically reduces compliance effort.

81. Audit Fatigue

Organizations may experience audit fatigue when multiple auditors repeatedly request similar evidence.

Example:

SOC 2 Auditor
→ Requests MFA evidence

ISO Auditor
→ Requests MFA evidence

Customer Auditor
→ Requests MFA evidence

Internal Audit
→ Requests MFA evidence

A unified control and evidence model reduces duplication.

82. Centralized Assurance Model

A scalable architecture looks like:

External Requirements
        ↓
Unified Control Library
        ↓
Control Owners
        ↓
Evidence Repository
        ↓
Control Testing
        ↓
Multiple Audits

This creates a single source of truth.

83. Audit Coordination

GRC often acts as the bridge between auditors and technical teams.

Auditor
   ↕
GRC
   ↕
Control Owners
   ↕
Technical Systems

GRC translates requirements and coordinates evidence without unnecessarily disrupting engineering teams.

84. Audit Communication

Good communication should be:

Accurate.
Concise.
Evidence based.
Timely.
Consistent.

Conflicting answers from different teams can create unnecessary audit concerns.

85. Audit Request Triage

Before forwarding an auditor request, GRC should understand:

What is being requested?

Which control does it relate to?

Which period?

Which system?

Who owns the evidence?

Does existing evidence already satisfy it?

This avoids duplicate work.

86. Auditor Request Example

Request:

Provide evidence demonstrating monitoring of privileged cloud activity.

Instead of immediately asking the cloud team for “anything related to monitoring,” GRC should identify:

Control:
Privileged Activity Monitoring

Evidence:
Cloud audit logs
SIEM alert configuration
Sample alert
Monitoring procedure

Specific requests save time.

87. Protecting Sensitive Evidence

Audit evidence can contain:

User data.
Network information.
Security configurations.
Vulnerability details.
Customer information.
Architecture diagrams.

Evidence repositories should therefore have appropriate access controls.

88. Auditor Access

Organizations may provide auditors:

Secure portals.
Restricted repositories.
Time-limited access.
Read-only access.

Evidence sharing should follow least privilege.

89. Audit Trail

GRC should maintain records showing:

Who Requested Evidence?

Who Provided It?

When?

Which Version?

Which Audit?

Which Control?

This improves traceability.

90. Audit Automation

Modern GRC environments may automate:

Evidence collection.
Control mapping.
Auditor requests.
Evidence reminders.
Finding tracking.
Compliance dashboards.

Example:

Cloud Platform
      ↓
API
      ↓
Evidence Collection
      ↓
GRC Platform
      ↓
Mapped Control
      ↓
Auditor

Automation can reduce manual effort.

91. Continuous Assurance

The traditional model:

Annual Audit
      ↓
Annual Evidence Collection
      ↓
Annual Findings

is evolving toward:

Continuous Monitoring
       ↓
Automated Evidence
       ↓
Continuous Control Testing
       ↓
Continuous Assurance

This is especially useful for cloud-native environments.

92. Audit vs Continuous Monitoring

Audit remains important because independent professional judgment is valuable.

Continuous monitoring provides faster detection.

A mature organization combines:

Automated Monitoring
       +
Periodic Control Testing
       +
Independent Audit
       =
Strong Assurance

93. Audit Metrics

Useful audit metrics may include:

Number of open findings.
Critical findings.
High findings.
Overdue findings.
Average remediation time.
Repeat findings.
Evidence-request completion rate.
Audit completion rate.
Control failure rate.

Metrics help leadership understand assurance performance.

94. Example Audit Dashboard

Metric	Result
Open Findings	34
Critical	1
High	7
Overdue	9
Repeat Findings	3
Average Closure	74 days

The numbers should be accompanied by context.

95. Finding Trends

Individual findings matter, but trends can reveal systemic issues.

Example:

IAM Findings
2024: 4
2025: 7
2026: 12

This may indicate increasing identity governance weakness.

Trend analysis supports risk decisions.

96. Common Audit Management Mistakes

Common mistakes include:

Preparing only when an audit is announced.
Providing evidence without reviewing it.
Sending incomplete evidence.
Sending excessive unrelated information.
Allowing multiple teams to answer independently.
Hiding known control failures.
Failing to track requests.
Missing deadlines without communication.
Accepting incorrect findings without challenge.
Arguing findings without evidence.
Closing remediation without validation.
Maintaining separate controls for every audit.

Strong GRC programs address these systematically.

97. Audit Is Not the Enemy

A weak organizational culture may treat auditors as adversaries.

A healthier model is:

Auditor Identifies Weakness
        ↓
Organization Understands Risk
        ↓
Controls Improve
        ↓
Business Becomes More Resilient

Audits should support improvement.

98. But Auditors Are Not Control Owners

Auditors may recommend improvements.

However, management owns risk and controls.

Auditor
→ Evaluates

Management
→ Decides

Control Owner
→ Implements

GRC
→ Monitors

Internal Audit
→ Verifies

Maintaining these responsibilities protects independence.

99. Practical Scenario — IAM Audit

Suppose Internal Audit performs an IAM audit.

Scope:

Production Applications
Cloud Platforms
Privileged Accounts
Employee Lifecycle

Controls selected:

IAM-001 Access Approval

IAM-002 MFA

IAM-006 Termination

IAM-010 Access Review

IAM-012 Privileged Monitoring

100. Audit Planning

Auditors identify major risks:

Unauthorized Access

Excessive Privilege

Former Employee Access

Privileged Account Compromise

Unmonitored Administrative Activity

They map controls to these risks.

101. Walkthrough

GRC schedules sessions with:

IAM.
HR.
Cloud Security.
Application owners.

Auditors observe:

Joiner
   ↓
Access Request
   ↓
Approval
   ↓
Provisioning
   ↓
Review
   ↓
Termination

102. Evidence Requests

Auditors request:

User population

Privileged account population

Access requests

Termination population

Quarterly access reviews

MFA configuration

Privileged activity logs

GRC tracks each request.

103. Testing

Auditors select samples.

Example:

25 new users

25 terminated users

20 privileged accounts

12 access reviews

Evidence is evaluated.

104. Finding Identified

Auditor discovers:

25 Terminations Tested

23:
Access removed within SLA

2:
Access remained active for more than 24 hours

Further investigation finds a manual integration failure between HR and IAM.

105. Finding Structure

Criteria

Terminated employee access must be disabled within four hours.

Condition

Two sampled accounts remained active for more than 24 hours.

Cause

HR-to-IAM integration failures were not monitored.

Risk

Former employees could retain unauthorized system access.

Recommendation

Implement monitoring and alerting for failed termination events.

106. Management Response

Management responds:

IAM will implement automated monitoring for failed HR termination events, establish SOC alerts for integration failures, and create daily reconciliation between HR and identity records.

Owner:

IAM Director

Target:

30 November 2026

107. Remediation Validation

After implementation:

GRC obtains current termination population
        ↓
Selects new samples
        ↓
Verifies automated processing
        ↓
Reviews failed-event alerts
        ↓
Confirms reconciliation

The finding can then be closed if remediation is effective.

108. Audit Readiness Checklist

Before an audit, confirm:

Scope is understood.
Control owners are identified.
Control descriptions are current.
Policies are approved.
Evidence exists for the required period.
Evidence populations are complete.
Known exceptions are documented.
Open findings are understood.
Walkthrough participants are prepared.
Auditor requests have owners.
Evidence repository access is controlled.
Remediation plans are current.

Preparation should validate reality rather than manufacture evidence.

109. Questions a GRC Professional Should Ask

For every audit, ask:

Why is this audit happening?

Who is relying on the result?

What are the audit criteria?

What is the scope?

What period is covered?

Which controls are relevant?

Who owns those controls?

What evidence already exists?

Are there known exceptions?

Are there open findings?

Who coordinates auditor communication?

How will remediation be tracked?

Can evidence be reused?

These questions establish control over the audit process.

110. Audit Coordination Mindset

The goal is not:

Give auditors everything they request as quickly as possible.

The goal is:

Understand Request
       ↓
Map to Requirement
       ↓
Map to Control
       ↓
Identify Correct Evidence
       ↓
Validate Evidence
       ↓
Securely Provide Evidence
       ↓
Track Completion

This creates disciplined audit management.

111. GRC Professional Responsibilities

As a GRC professional, you may:

Coordinate internal audits.
Coordinate external audits.
Define audit scopes.
Identify control owners.
Manage PBC requests.
Review evidence before submission.
Coordinate walkthroughs.
Maintain audit trackers.
Respond to auditor questions.
Validate findings.
Draft management responses.
Track remediation.
Escalate overdue findings.
Coordinate retesting.
Maintain evidence repositories.
Build audit dashboards.
Support certification audits.
Maintain continuous audit readiness.

Audit management is therefore a major practical component of enterprise GRC.

112. From Audit Readiness to Continuous Assurance

Organizations often evolve through several stages.

Stage 1
Reactive

Audit announced
→ Start preparing

        ↓

Stage 2
Repeatable

Defined audit process
→ Evidence repository

        ↓

Stage 3
Managed

Control owners
→ Testing schedules
→ Finding management

        ↓

Stage 4
Automated

Automated evidence
→ Continuous monitoring

        ↓

Stage 5
Continuous Assurance

Real-time control visibility
→ Risk-based independent assurance

The objective is not to eliminate audits.

It is to make assurance an integrated part of normal business operations.

Key Takeaways

Audit evaluates activities, processes, and controls against defined criteria.
Assurance provides confidence to stakeholders regarding the effectiveness or reliability of controls and governance.
Internal and external audits serve different assurance purposes.
The Three Lines Model separates control ownership, oversight, and independent assurance.
Auditor independence and objectivity are fundamental.
Audit scope defines what is and is not covered by the audit.
Risk-based auditing focuses assurance resources on higher-risk areas.
Walkthroughs help auditors understand how controls operate.
Audit evidence must be relevant, complete, accurate, timely, authentic, and traceable.
GRC often coordinates PBC requests and evidence submissions.
Findings should explain criteria, condition, cause, risk, and remediation.
Management owns remediation.
Findings should be validated before closure.
Repeat and overdue findings may indicate broader governance weaknesses.
Continuous audit readiness reduces audit disruption.
Unified control libraries and evidence repositories reduce audit fatigue.
Automation can support evidence collection and continuous control monitoring.
Audit should support risk reduction and continuous improvement rather than checkbox compliance.

Knowledge Check

Before continuing, make sure you can answer these questions:

What is an audit?
What is assurance?
What is the difference between audit and assurance?
What are audit criteria?
Why is audit scope important?
What is the difference between internal and external audit?
What is a certification audit?
What is an attestation engagement?
What is the difference between SOC Type I and Type II?
What are the Three Lines?
Why is auditor independence important?
What is risk-based auditing?
What is an audit program?
What is a PBC request?
What makes audit evidence reliable?
What is an audit walkthrough?
What are the major components of an audit finding?
What is a management response?
Why should remediation be validated?
What is continuous audit readiness?

What’s Next?

➡️ Next: 10 — Compliance Management

In the next lesson, you will move from audit and assurance into the broader discipline of enterprise compliance management.

You will learn how organizations identify applicable laws, regulations, standards, contractual obligations, and internal requirements, translate those obligations into controls, assign compliance ownership, maintain compliance registers, perform compliance assessments, manage exceptions, track regulatory changes, and report compliance status.

You will also learn how organizations build a scalable compliance management system that connects:

Obligations
    ↓
Policies
    ↓
Controls
    ↓
Evidence
    ↓
Assessments
    ↓
Issues
    ↓
Remediation
    ↓
Compliance Reporting

This will prepare you for the practical compliance-monitoring and regulatory-governance responsibilities commonly performed by GRC Analysts, Compliance Analysts, Security Governance professionals, and GRC Managers.