10 Internal Audits

An organization may have:

An approved ISMS.
Security policies.
A risk register.
A Risk Treatment Plan.
A Statement of Applicability.
Annex A controls.
Control owners.
Security evidence.

But an important question remains:

Is the ISMS actually operating as intended?

This is where internal audit becomes essential.

An ISO/IEC 27001 internal audit provides independent and objective assurance about whether the Information Security Management System:

Meets organizational requirements.
Meets applicable ISO/IEC 27001 requirements.
Has been effectively implemented.
Is being maintained.
Produces sufficient evidence.
Identifies and addresses weaknesses.

The internal-audit lifecycle can be visualized as:

Audit Program
      ↓
Audit Scope
      ↓
Audit Criteria
      ↓
Audit Planning
      ↓
Evidence Collection
      ↓
Interviews
      ↓
Sampling
      ↓
Control Testing
      ↓
Findings
      ↓
Audit Report
      ↓
Corrective Actions
      ↓
Retesting
      ↓
Closure

For GRC professionals, internal audit is especially important because it connects governance, controls, evidence, assurance, corrective action, and certification readiness.

Learning Objectives

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

Explain the purpose of an ISO/IEC 27001 internal audit.
Understand the internal-audit requirement.
Develop an audit program.
Define audit scope and criteria.
Maintain auditor objectivity and impartiality.
Build an audit plan.
Prepare an evidence request list.
Conduct audit interviews.
Select appropriate samples.
Test control design.
Test operating effectiveness.
Document audit evidence.
Identify audit findings.
Understand nonconformities.
Perform root-cause analysis.
Develop corrective actions.
Track remediation.
Retest corrective actions.
Prepare an internal audit report.
Use audit results for management review.
Support certification readiness.

1. What Is an Internal Audit?

An internal audit is a structured evaluation of the ISMS.

It asks:

Are requirements defined?
        ↓
Are processes implemented?
        ↓
Are controls operating?
        ↓
Is evidence available?
        ↓
Are weaknesses identified?
        ↓
Are weaknesses corrected?

The objective is not simply to find problems.

The objective is to determine whether the ISMS is conforming and effectively implemented and maintained.

2. Internal Audit in ISO/IEC 27001

ISO/IEC 27001 requires organizations to conduct internal audits at planned intervals.

The organization should determine whether the ISMS:

Conforms to
     ↓
Organizational ISMS Requirements
+
ISO/IEC 27001 Requirements

and

Is Effectively Implemented
+
Maintained

This makes internal audit part of the ISMS performance-evaluation process.

3. Internal Audit Is Not Certification Audit

These activities are different.

Internal Audit

Performed on behalf of the organization to evaluate its own ISMS.

Certification Audit

Performed by an independent certification body to determine whether the organization meets certification requirements.

A strong internal audit helps prepare the organization for external certification.

4. Internal Audit Is Not Control Operation

Suppose the IAM team performs:

Quarterly Privileged Access Review

That is a control.

When an auditor independently examines whether those reviews occurred correctly, that is:

Control Testing / Internal Audit

These responsibilities should remain appropriately separated.

5. Why Internal Audit Matters

Without internal audit, management may assume:

Policy Exists
      =
Control Works

But this may not be true.

Internal audit tests reality.

Example:

Policy:
Access reviewed quarterly

Evidence:
Q1 — Completed
Q2 — Missing
Q3 — Completed
Q4 — Incomplete

The audit reveals that the process does not operate consistently.

6. Assurance

Internal audit provides assurance.

Assurance asks:

Can management reasonably rely on the ISMS and its controls?

This requires evidence rather than assumption.

7. The Audit Program

Organizations should establish an audit program.

The program defines:

What will be audited?

When?

How often?

By whom?

Using what criteria?

It should consider the importance of relevant processes and previous audit results.

8. Risk-Based Audit Planning

Not every area necessarily requires identical attention.

Higher-risk areas may receive greater audit focus.

Example:

Privileged Access
→ High Risk
→ More Frequent / Deeper Testing

Low-Risk Administrative Process
→ Lower Risk
→ Less Intensive Testing

This supports risk-based assurance.

9. Factors Affecting Audit Priority

Consider:

Risk level.
Previous findings.
Significant changes.
Incidents.
New technology.
Regulatory requirements.
Control failures.
Management concerns.
Certification schedule.

These factors can influence the audit program.

10. Example Annual Audit Program

Quarter	Audit Area
Q1	ISMS Governance & Risk
Q2	IAM & Access Controls
Q3	Supplier & Cloud Security
Q4	Incident Response & Resilience

Another organization may conduct one comprehensive annual audit.

The model should fit organizational needs.

11. Audit Scope

Audit scope defines the boundaries of the audit.

Example:

Audit Scope:

Production AWS Environment

IAM Processes

Security Logging

Incident Response

Supporting Policies

Clear scope prevents ambiguity.

12. Scope Questions

Ask:

Which business units?

Which locations?

Which systems?

Which processes?

Which controls?

Which period?

Example:

Audit Period:
01 January – 30 June 2026

13. Audit Criteria

Audit criteria define what the auditor evaluates against.

Possible criteria include:

ISO/IEC 27001 Requirements

Statement of Applicability

Internal Policies

Security Standards

Procedures

Legal Requirements

Contractual Requirements

The auditor needs a defined benchmark.

14. Example Audit Criteria

For access management:

ISO Requirements
+
Access Control Policy
+
IAM Standard
+
Joiner-Mover-Leaver Procedure
+
SoA Controls

These collectively form the audit criteria.

15. Auditor Objectivity and Impartiality

Internal audits should be conducted objectively and impartially.

A basic principle is:

Avoid auditing your own work where this would compromise objectivity.

Example:

IAM Administrator
      ↓
Operates IAM Control

Should not independently conclude
      ↓
Own control is effective

16. Internal Auditor Options

Auditors may come from:

Internal audit.
GRC.
Another independent department.
Qualified external consultants.

The important consideration is appropriate competence and objectivity.

17. Auditor Competence

Auditors should understand:

ISO/IEC 27001

Audit Techniques

Risk Management

Control Testing

Evidence Evaluation

Relevant Technology

Not every auditor needs to be a deep technical engineer, but sufficient competence is necessary.

18. Audit Planning

Before fieldwork begins, prepare an audit plan.

A practical plan contains:

Audit Objective

Scope

Criteria

Audit Period

Auditor

Stakeholders

Processes

Controls

Schedule

Evidence Requirements

19. Audit Objective

Example:

Evaluate whether identity and access management controls are appropriately designed, implemented, and operating consistently with ISMS requirements.

The objective should be clear.

20. Audit Timeline

Example:

Week 1
Planning

Week 2
Evidence Collection

Week 3
Interviews & Testing

Week 4
Findings Validation

Week 5
Audit Report

Timelines help coordinate stakeholders.

21. Opening Meeting

An internal audit commonly begins with an opening meeting.

Discuss:

Objective.
Scope.
Criteria.
Timeline.
Evidence requests.
Interviews.
Communication.
Escalation.

This establishes expectations.

22. Evidence Request List

Before testing, request relevant documentation.

Example:

Information Security Policy

Risk Register

Risk Treatment Plan

Statement of Applicability

Access Review Reports

Security Training Records

Incident Records

Vendor Assessments

Vulnerability Reports

Backup Test Results

23. Evidence Types

Audit evidence may include:

Documents

Reports

System Configurations

Tickets

Logs

Screenshots

Interview Responses

Observations

System Demonstrations

Strong conclusions usually rely on sufficient and appropriate evidence.

24. Evidence Quality

Good evidence should be:

Relevant.
Reliable.
Traceable.
Appropriate to the period.
Sufficient for the conclusion.

Example:

A screenshot from today may not prove that a quarterly control operated throughout the previous year.

25. Evidence Hierarchy

Evidence strength varies.

For example:

Verbal Statement
      ↓
Procedure
      ↓
System Report
      ↓
System-Generated Evidence
      ↓
Corroborated Evidence

Auditors should evaluate reliability rather than accept everything at face value.

26. Inquiry Alone Is Usually Insufficient

Control owner says:

“We review access every quarter.”

This is useful information.

But the auditor should request evidence.

For example:

Q1 Access Review

Q2 Access Review

Q3 Access Review

Q4 Access Review

27. Audit Interviews

Interviews help understand:

Process design.
Roles.
Control execution.
Exceptions.
Evidence.
Challenges.

Interviews should complement evidence testing.

28. Example Interview Questions

For access management:

How are users provisioned?

Who approves access?

How are privileged accounts managed?

How often is access reviewed?

What happens when someone leaves?

How are exceptions handled?

29. Walkthrough

A walkthrough follows a process from beginning to end.

Example:

New Employee
      ↓
Manager Request
      ↓
Approval
      ↓
Account Creation
      ↓
Access Provisioning
      ↓
Evidence

Walkthroughs help auditors understand control design.

30. Design Effectiveness

The first question is:

Is the control appropriately designed to address its intended objective or risk?

Example:

Risk:

Unauthorized privileged access

Control:

Privileged access reviewed once every five years.

Even if performed perfectly, the design may be insufficient.

31. Design Test Questions

Ask:

Is the control clearly defined?

Does it address the risk?

Is ownership defined?

Is frequency appropriate?

Is scope appropriate?

Is evidence produced?

32. Operating Effectiveness

Next ask:

Did the control operate as designed during the audit period?

Example:

Control:

Quarterly access review

Audit period:

12 months

Expected:

4 reviews

Actual:

3 reviews

This indicates an operating exception.

33. Control Population

Before sampling, identify the complete population.

Example:

Control:
New user access approval

Population:
850 user access requests during audit period

The population should be complete enough to support sample selection.

34. Sampling

Auditors often cannot test every transaction.

Instead:

Population
      ↓
Sample
      ↓
Evidence Testing
      ↓
Conclusion

Sample size depends on audit methodology and circumstances.

35. Sampling Considerations

Consider:

Population size.
Control frequency.
Risk.
Automation.
Previous findings.
Expected exceptions.

There is no universal sample size appropriate for every audit.

36. Sample Selection

Samples should avoid inappropriate bias.

Possible approaches include:

Random

Systematic

Judgmental

Risk-Based

Document the approach.

37. Example — User Provisioning

Population:

500 New Accounts

Sample:

25 Accounts

For each sample, test:

Request.
Approval.
Access.
Timing.
Evidence.

38. Example — Quarterly Control

Control:

Quarterly privileged access review

Population:

4 Reviews

The auditor may test all four because the population is small.

39. Automated Controls

For an automated control, test:

Configuration

Logic

Access to Modify

Change Management

Exceptions

Evidence

Example:

Cloud policy automatically blocks public storage.

Do not merely test one blocked event.

Verify the policy itself.

40. Manual Controls

For a manual control, evaluate:

Who performs it?

How often?

What information is reviewed?

How are decisions recorded?

How are exceptions remediated?

Manual controls often require transaction sampling.

41. Hybrid Controls

Example:

Automated Vulnerability Scanner
      ↓
Human Reviews Results
      ↓
Engineering Remediates

The auditor may need to test both automated and manual components.

42. Testing ISMS Requirements

Internal audit should not focus only on Annex A.

The audit program should also cover applicable ISMS requirements.

Examples:

Scope

Leadership

Risk Assessment

Objectives

Competence

Document Control

Internal Audit

Management Review

Corrective Action

This is critical for certification readiness.

43. Testing Risk Management

Auditor may inspect:

Risk Methodology

Risk Register

Risk Owners

Treatment Decisions

Risk Acceptance

Review Records

Questions include:

Is the methodology followed?
Are risks current?
Are owners assigned?
Are treatments tracked?

44. Testing the SoA

Auditor may select SoA entries and verify:

Applicability
      ↓
Implementation
      ↓
Ownership
      ↓
Evidence

Example:

SoA:
MFA Implemented

Evidence:
MFA Coverage = 82%

The status may require correction.

45. Testing Policies

Auditor should determine:

Policy Exists?

Approved?

Current?

Communicated?

Implemented?

Followed?

Having a policy document alone does not prove conformity.

46. Testing Security Awareness

Evidence may include:

Training Content

Completion Records

New Hire Training

Phishing Exercises

Exceptions

The auditor may compare training population against employee population.

47. Testing Supplier Security

Sample vendor records.

Check:

Security Assessment

Risk Rating

Approval

Contract Requirements

Monitoring

Reassessment

48. Testing Vulnerability Management

Review:

Scanning Coverage

Severity Classification

Remediation SLA

Exceptions

Overdue Vulnerabilities

Rescan Evidence

49. Testing Incident Management

Select incident samples.

Review:

Detection

Classification

Escalation

Response

Evidence

Closure

Lessons Learned

50. Testing Backup Controls

Review:

Backup Configuration

Backup Completion

Failures

Recovery Tests

Retention

Encryption

Remember:

Successful Backup
≠
Successful Recovery

51. Testing Access Reviews

For each sampled review:

Correct Population?

Correct Reviewer?

Completed on Time?

Access Decisions Documented?

Removals Completed?

Evidence Retained?

52. Audit Working Papers

Auditors should maintain documentation supporting their work.

A working paper may contain:

Control

Audit Procedure

Population

Sample

Evidence

Exceptions

Conclusion

This creates an audit trail.

53. Example Control Testing Worksheet

Field	Example
Control	Quarterly Access Review
Population	4
Sample	4
Evidence	Review Reports
Exceptions	Q2 Missing
Conclusion	Ineffective

54. Audit Trail

A reviewer should be able to understand:

What Was Tested
      ↓
How It Was Tested
      ↓
What Evidence Was Used
      ↓
What Was Found
      ↓
How Conclusion Was Reached

Good documentation supports defensibility.

55. Audit Findings

A finding identifies a condition requiring attention.

Findings may include:

Nonconformity

Control Deficiency

Observation

Opportunity for Improvement

Organizations may use different classifications.

56. What Is a Nonconformity?

A nonconformity occurs when a requirement is not fulfilled.

Example:

Requirement:

Privileged access reviews must occur quarterly.

Evidence:

No reviews performed for six months.

Result:

Nonconformity

57. Major vs Minor Nonconformity

Organizations and certification bodies may distinguish between different levels of nonconformity.

A major issue generally represents a significant or systemic failure.

A minor issue generally represents a more limited lapse that does not necessarily indicate complete system breakdown.

Classification should follow the organization’s audit methodology and applicable certification practices.

58. Example Minor Issue

Requirement:
Quarterly access review

Evidence:
Three of four reviews completed

Issue:
One review completed late

Depending on context and methodology, this could represent a limited nonconformity.

59. Example Major Issue

Requirement:
Information security risk assessment

Evidence:
No defined methodology

No current risk register

No documented risk assessment

This could indicate systemic failure of a core ISMS process.

60. Observation

An observation may identify a weakness that does not necessarily constitute a formal nonconformity.

Example:

Vendor reassessment process exists,
but reporting could be improved.

61. Opportunity for Improvement

An OFI identifies a potential improvement.

Example:

Current:
Manual evidence collection

Opportunity:
Automate evidence collection

OFIs should not be used to disguise actual nonconformities.

62. Writing Strong Findings

A good finding should explain:

Criteria

Condition

Evidence

Risk / Impact

Example:

The Access Control Standard requires quarterly privileged-access reviews. The audit found that the Q2 2026 review was not performed for 18 production applications, increasing the risk that inappropriate privileged access could remain undetected.

63. Weak Finding

Avoid:

IAM is bad.

This provides no usable information.

64. Strong Finding Structure

Use:

Requirement
      ↓
Observed Condition
      ↓
Evidence
      ↓
Impact

This makes remediation easier.

65. Findings Validation

Before issuing the final report:

Discuss Finding
      ↓
Confirm Facts
      ↓
Review Evidence
      ↓
Resolve Factual Errors
      ↓
Finalize

Auditees do not need to agree with every conclusion, but factual accuracy is important.

66. Closing Meeting

The closing meeting may cover:

Audit scope completed.
Significant findings.
Nonconformities.
Positive observations.
Next steps.
Corrective-action expectations.
Reporting timeline.

Avoid surprising management with major issues for the first time in the final report where practical.

67. Internal Audit Report

A practical report includes:

Executive Summary

Audit Objective

Scope

Criteria

Methodology

Overall Conclusion

Findings

Observations

Recommendations / Improvement Areas

Management Responses

Corrective Actions

68. Executive Summary

Management usually needs:

Overall ISMS Status

Major Issues

Material Risks

Recurring Findings

Certification Concerns

Required Decisions

Keep this concise and decision oriented.

69. Audit Opinion

Depending on methodology, the auditor may conclude:

Effective

Generally Effective with Improvements Required

Partially Effective

Ineffective

Use only categories defined by the organization’s audit framework.

70. Audit Findings Register

Create a centralized register.

Recommended fields:

Field
Finding ID
Audit
Requirement
Finding
Severity
Risk
Owner
Corrective Action
Target Date
Status
Retest Result

71. Corrective Action

A finding should lead to appropriate correction and corrective action.

The objective is not only:

Fix the Sample

but also:

Understand Why It Happened
      ↓
Address Root Cause
      ↓
Prevent Recurrence

72. Correction vs Corrective Action

Example finding:

Five terminated employees retain access.

Correction

Disable five accounts.

Corrective Action

Fix HR-to-IAM offboarding workflow
to prevent recurrence.

Both may be necessary.

73. Root Cause Analysis

Ask:

Why did the failure occur?

Possible causes:

Process Gap

Technology Failure

Poor Ownership

Training Gap

Resource Constraint

Manual Error

Governance Failure

74. Five Whys Example

Problem:

Terminated employee retained access.

Why?

IAM never received termination notice.

Why?

HR process relies on email.

Why?

No automated integration exists.

Why?

Integration was never included in IAM design.

Potential root cause:

Incomplete offboarding process design.

75. Corrective Action Plan

Example:

Finding:
Delayed account termination

Root Cause:
Manual HR notification

Corrective Action:
Integrate HRIS with identity platform

Owner:
IAM Director

Target:
31 January 2027

76. Corrective Action Ownership

Every corrective action should have:

Owner

Action

Target Date

Status

Without ownership, findings frequently remain unresolved.

77. Corrective Action Tracking

Statuses may include:

Open

Planned

In Progress

Blocked

Ready for Retest

Closed

GRC can monitor progress.

78. Overdue Findings

Example:

High Finding
      ↓
Target Date Missed
      ↓
Escalation
      ↓
Risk Review

Significant overdue findings should not remain invisible.

79. Retesting

A finding should not necessarily be closed because the owner says:

Fixed.

The auditor or appropriate assurance function should verify.

Corrective Action
      ↓
Evidence
      ↓
Retest
      ↓
Effective?

80. Retest Example

Original finding:

Quarterly access reviews missing.

Corrective action:

Automated review workflow implemented.

Retest:

Review latest quarter

Verify complete population

Verify approvals

Verify removals

If successful:

Finding Closed

81. Failed Retest

If remediation does not work:

Retest Failed
      ↓
Finding Remains Open
      ↓
Additional Corrective Action

Do not close findings simply to improve metrics.

82. Recurring Findings

Repeated findings may indicate:

Weak Root Cause Analysis

Poor Governance

Insufficient Ownership

Ineffective Corrective Action

Recurring issues deserve management attention.

83. Audit Metrics

Useful metrics include:

Audits Completed

Open Findings

High-Risk Findings

Overdue Findings

Average Closure Time

Repeat Findings

Retest Failure Rate

Metrics should support decisions.

84. Example KRI

KRI:
Number of overdue High-risk audit findings

Tolerance:
0

This can support management escalation.

85. Audit and Management Review

Internal audit results should feed management review.

Management may need visibility into:

Audit Results

Major Nonconformities

Control Failures

Corrective Action Status

Recurring Issues

Certification Readiness

This supports leadership oversight.

86. Internal Audit and Certification

Before certification, internal audit should provide confidence that:

ISMS Requirements
      ↓
Implemented

Controls
      ↓
Operating

Evidence
      ↓
Available

Findings
      ↓
Managed

Internal audit is not merely a paperwork requirement before certification.

87. Certification Readiness Review

Before external audit, verify:

ISMS scope current.
Policies approved.
Risk assessment current.
RTP current.
SoA current.
Internal audit completed.
Management review completed.
Findings managed.
Evidence available.

These provide a strong certification foundation.

88. Common Internal Audit Mistakes

Mistake 1 — Auditing Only Annex A

The ISMS clauses also need coverage.

Mistake 2 — Auditor Tests Own Work

Objectivity may be compromised.

Mistake 3 — Checklist-Only Audit

Policy exists?
Yes.

No effectiveness testing occurs.

Mistake 4 — Inquiry Without Evidence

Management statements are accepted without validation.

Mistake 5 — Poor Sampling

Samples do not support the audit conclusion.

Mistake 6 — No Population Validation

The auditor tests a sample from an incomplete population.

Mistake 7 — Vague Findings

Stakeholders cannot understand what failed.

Mistake 8 — Fixing Symptoms Only

Root cause remains.

Mistake 9 — Findings Closed Without Retesting

Remediation effectiveness is unknown.

Mistake 10 — Audit Performed Only Before Certification

Internal audit should support ongoing improvement.

89. Weak Audit Approach

Ask:
Do you have an access policy?

Answer:
Yes.

Result:
Pass.

This provides little assurance.

90. Strong Audit Approach

Review Policy
      ↓
Review Control Design
      ↓
Identify Population
      ↓
Select Samples
      ↓
Inspect Evidence
      ↓
Interview Owner
      ↓
Test Exceptions
      ↓
Conclude Effectiveness

This provides meaningful assurance.

91. Practical Activity — Build Internal Audit Plan

Create:

01 ISO Internal Audit Plan

Include:

Audit objective.
Scope.
Criteria.
Audit period.
Auditor.
Processes.
Controls.
Stakeholders.
Schedule.
Deliverables.

92. Practical Activity — Build Audit Checklist

Create:

02 ISO Internal Audit Checklist

Recommended fields:

Field
Requirement
Audit Question
Evidence Expected
Evidence Reviewed
Result
Notes

Include both ISMS requirements and relevant Annex A controls.

93. Practical Activity — Evidence Request List

Create:

03 Audit Evidence Request List

Use:

Request	Owner	Due Date	Status

Include:

Policies

Risk Register

RTP

SoA

Control Evidence

Audit Logs

Training Records

Vendor Records

Incident Records

94. Practical Activity — Control Testing Worksheet

Create:

04 Control Testing Worksheet

Fields:

Control ID

Control Objective

Control Owner

Frequency

Population

Sample

Test Procedure

Evidence

Exceptions

Design Conclusion

Operating Conclusion

95. Practical Activity — Audit Findings Register

Create:

05 Audit Findings Register

Use:

Finding	Requirement	Severity	Owner	Target	Status

Add:

Root Cause

Corrective Action

Retest Result

96. Practical Activity — Corrective Action Tracker

Create:

06 Corrective Action Tracker

Recommended fields:

Finding ID

Root Cause

Corrective Action

Owner

Target Date

Evidence

Retest Date

Retest Result

Closure Date

97. Practical Activity — Perform a Mock Audit

Select five controls:

Access Review

MFA

Security Awareness

Vendor Assessment

Backup Recovery

For each control:

Define audit criteria.
Identify population.
Select sample.
Request evidence.
Perform testing.
Document exceptions.
Determine effectiveness.
Write findings where necessary.

This simulates real GRC audit work.

98. Internal Audit Checklist

Before completing an internal audit:

Audit program established.
Scope defined.
Criteria defined.
Auditor competence considered.
Objectivity and impartiality considered.
Audit plan approved.
Evidence requested.
Interviews completed.
Walkthroughs completed.
Populations identified.
Samples selected.
ISMS requirements tested.
Applicable controls tested.
Evidence documented.
Findings validated.
Audit report issued.
Corrective actions assigned.
Target dates established.
Findings tracked.
Retesting performed.
Audit records retained.

99. GRC Analyst Responsibilities

A GRC professional may:

Coordinate the audit program.
Define audit scope.
Prepare audit plans.
Build evidence requests.
Coordinate stakeholders.
Conduct control walkthroughs.
Perform or support control testing.
Maintain working papers.
Document findings.
Facilitate root-cause analysis.
Track corrective actions.
Escalate overdue findings.
Coordinate retesting.
Maintain the findings register.
Prepare audit reporting.
Support certification readiness.

Depending on the organization, GRC may perform audits or support an independent internal-audit function.

100. Internal Audit Governance Model

A practical model may look like:

Management
      ↓
Approves Audit Program

Internal Audit / Independent Assurance
      ↓
Performs Audit

GRC
      ↓
Coordinates ISMS Evidence

Control Owners
      ↓
Provide Evidence

Risk Owners
      ↓
Address Risk

Management
      ↓
Reviews Results

Responsibilities should preserve appropriate objectivity.

101. Internal Audit Lifecycle

Annual Audit Program
        ↓
Audit Planning
        ↓
Scope & Criteria
        ↓
Evidence Request
        ↓
Interviews
        ↓
Walkthroughs
        ↓
Sampling
        ↓
Testing
        ↓
Findings
        ↓
Audit Report
        ↓
Root Cause
        ↓
Corrective Action
        ↓
Retesting
        ↓
Closure
        ↓
Management Review
        ↓
Continuous Improvement

102. Internal Audit Maturity

Level 1 — Checklist

Documents checked
Little testing

Level 2 — Evidence Based

Evidence
Sampling
Findings

Level 3 — Risk Based

Risk Prioritization
Control Testing
Root Cause

Level 4 — Integrated Assurance

Risk
Controls
Audit
Compliance
Findings

Level 5 — Continuous Assurance

Automated Evidence

Continuous Control Monitoring

Risk-Based Testing

Real-Time Exceptions

103. Internal Audit Mindset

When auditing any ISMS process or control, ask:

What is the requirement?

What should happen?

Who is responsible?

What actually happened?

What evidence proves it?

Was the complete population considered?

Was the control properly designed?

Did it operate consistently?

Were exceptions identified?

What risk results from the exception?

Why did the failure happen?

Has the root cause been corrected?

Can remediation be independently verified?

These questions transform internal audit from a checklist exercise into meaningful assurance.

Key Takeaways

ISO/IEC 27001 requires internal audits at planned intervals.
Internal audit evaluates both conformity and effective implementation and maintenance of the ISMS.
Internal audit should cover ISMS requirements as well as applicable controls.
Audit programs should consider process importance and previous audit results.
Audit scope and criteria should be clearly defined.
Auditors should maintain appropriate objectivity and impartiality.
Inquiry alone generally provides insufficient assurance.
Evidence should be relevant, reliable, sufficient, and appropriate.
Control design and operating effectiveness should be evaluated separately.
Sampling should be based on a defined population and appropriate methodology.
Findings should clearly connect criteria, condition, evidence, and impact.
Nonconformities require appropriate correction and corrective action.
Root-cause analysis helps prevent recurrence.
Corrective actions should have owners and target dates.
Findings should be independently retested before closure where appropriate.
Internal-audit results are an important input into management review and certification readiness.
GRC plays a major role in coordinating audit evidence, findings, remediation, and assurance activities.

Knowledge Check

Before continuing, make sure you can answer:

What is the purpose of an ISO/IEC 27001 internal audit?
What should the internal audit determine?
What is an audit program?
What is audit scope?
What are audit criteria?
Why is auditor objectivity important?
What is an audit walkthrough?
What is design effectiveness?
What is operating effectiveness?
What is a control population?
Why is sampling used?
Why should the auditor validate the population?
What makes good audit evidence?
Why is inquiry alone usually insufficient?
What is a nonconformity?
What is the difference between correction and corrective action?
Why is root-cause analysis important?
Why should corrective actions be retested?
How do internal-audit results support management review?
How does internal audit support certification readiness?

What’s Next?

➡️ Next: 10 — Certification Process

In the next lesson, you will move from independent ISMS assurance into leadership oversight and continual improvement.

You will learn how management reviews information such as:

Internal Audit Results
        ↓
Risk & Treatment Status
        ↓
Security Objectives
        ↓
Control Performance
        ↓
Incidents & Nonconformities
        ↓
Stakeholder Changes
        ↓
Improvement Opportunities
        ↓
Management Decisions
        ↓
Actions & Ownership

You will also build practical artifacts including a Management Review Agenda, Management Review Pack, ISMS KPI/KRI Dashboard, Management Decision Log, Improvement Register, and Management Review Minutes Template.

This completes the core operational cycle of the ISO/IEC 27001 ISMS and prepares you for the module’s practical labs and runbooks.