Runbook 02 — ISO/IEC 27001 Internal Audit, Nonconformity & Corrective Action Management

Runbook Information

Item	Details
Runbook	02 — ISO/IEC 27001 Internal Audit, Nonconformity & Corrective Action Management
Module	ISO/IEC 27001
Difficulty	Advanced
Estimated Time	Multi-Day / Recurring Enterprise Workflow
Primary Role	GRC Analyst / ISMS Auditor
Supporting Roles	ISMS Manager, CISO, Control Owners, Risk Owners, Internal Audit, Business Owners
Primary Output	Internal Audit & Corrective Action Package
Runbook Type	ISO Assurance & Continual Improvement

Purpose

This runbook provides a repeatable process for operating the internal audit, nonconformity, corrective action, retesting, and closure lifecycle of an ISO/IEC 27001 Information Security Management System.

The workflow covers:

Audit Program
      ↓
Audit Planning
      ↓
Scope & Criteria
      ↓
Evidence Collection
      ↓
Interviews
      ↓
Walkthroughs
      ↓
Sampling
      ↓
Control Testing
      ↓
Findings
      ↓
Nonconformity
      ↓
Correction
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Implementation
      ↓
Retesting
      ↓
Closure
      ↓
Management Review
      ↓
Continual Improvement

The objective is not simply to identify failures.

The objective is to create a repeatable assurance process that helps management answer:

Is the ISMS operating as designed, are failures being identified early, and are root causes being corrected so the same problems do not continue to recur?

Runbook Outcomes

A completed internal audit cycle should produce:

• Approved audit program.

• Defined audit scope and criteria.

• Audit plan.

• Evidence request list.

• Interview schedule.

• Audit working papers.

• Control-testing records.

• Audit findings.

• Nonconformity records.

• Root-cause analyses.

• Corrective-action plans.

• Remediation tracking.

• Retest results.

• Closure approvals.

• Management-review inputs.

• Continual-improvement actions.

Operational Workflow

Annual Assurance Plan
      ↓
Audit Selected
      ↓
Planning
      ↓
Fieldwork
      ↓
Evidence
      ↓
Testing
      ↓
Findings
      ↓
Corrective Actions
      ↓
Retesting
      ↓
Closure
      ↓
Reporting
      ↓
Management Review

Phase 1 — Establish the Internal Audit Program

Step 1 — Define the Audit Universe

Identify all ISMS areas that may require assurance.

Examples include:

Clause 4 — Context

Clause 5 — Leadership

Clause 6 — Planning

Clause 7 — Support

Clause 8 — Operation

Clause 9 — Performance Evaluation

Clause 10 — Improvement

Annex A Controls

Risk Management

Supplier Security

IAM

Incident Response

Business Continuity

Secure Development

Logging & Monitoring

The audit universe should reflect the actual ISMS.

Step 2 — Review Risk Information

Consider:

• High residual risks.

• Critical controls.

• Previous findings.

• Recent incidents.

• Major changes.

• Supplier risks.

• Control failures.

Example:

High Residual Risk:
Privileged account compromise

Audit Priority:
IAM and privileged access controls

Step 3 — Review Previous Audit Results

Identify:

Repeat Findings

Overdue Findings

Areas Never Audited

Weak Corrective Actions

These should influence the audit program.

Step 4 — Consider Significant Changes

Examples:

New Cloud Provider

Acquisition

New Product

Major IAM Migration

New Regulation

Security Incident

A significant change may justify additional audit coverage.

Step 5 — Build Annual Audit Program

Example:

Quarter	Audit
Q1	ISMS Governance & Risk
Q2	IAM & Access Control
Q3	Supplier & Cloud Security
Q4	Incident Response & Business Continuity

The organization may use a different model based on scale and risk.

Step 6 — Obtain Audit Program Approval

Record:

Audit Program Owner

Approver

Period

Version

Approval Date

Phase 2 — Establish Auditor Objectivity & Competence

Step 7 — Assign Auditor

Identify:

Lead Auditor

Supporting Auditors

Technical Specialists

Step 8 — Check Independence

Ask:

Does the auditor own the process?

Did the auditor design the control?

Does the auditor operate the control?

Could objectivity be impaired?

Avoid inappropriate self-audit.

Step 9 — Confirm Competence

Auditors should have appropriate knowledge of:

• ISO/IEC 27001.

• Audit methods.

• Risk management.

• Evidence assessment.

• Relevant technology.

Step 10 — Use Specialists Where Required

Example:

Audit:
Cloud Security

Auditor:
GRC

Technical Specialist:
Cloud Security Architect

The specialist supports technical understanding while audit judgment remains appropriately independent.

Phase 3 — Define Audit Objective, Scope & Criteria

Step 11 — Define Audit Objective

Example:

Determine whether privileged access management processes are appropriately designed, implemented, and operating in accordance with the ISMS, the Access Control Policy, and applicable ISO/IEC 27001 controls.

Step 12 — Define Audit Scope

Document:

Business Units

Systems

Processes

Controls

Locations

Audit Period

Example:

Scope:
Production AWS privileged access

Period:
01 January – 30 June 2026

Step 13 — Define Audit Criteria

Possible criteria:

ISO/IEC 27001 Requirements

Statement of Applicability

Policies

Standards

Procedures

Contracts

Legal Requirements

Step 14 — Confirm Out-of-Scope Areas

Document exclusions to avoid confusion during fieldwork.

Phase 4 — Prepare the Audit Plan

Step 15 — Create Audit Plan

Include:

Audit Objective

Scope

Criteria

Audit Team

Stakeholders

Timeline

Interviews

Processes

Controls

Evidence

Sampling

Step 16 — Identify Process Owners

Example:

Area	Owner
IAM	IAM Director
Vulnerability Management	Security Engineering
Supplier Security	GRC
Backup	IT Operations

Step 17 — Build Audit Schedule

Example:

Day 1
Opening + Governance

Day 2
Walkthroughs

Day 3
Testing

Day 4
Follow-Up Evidence

Day 5
Findings Validation

Step 18 — Send Audit Notification

Include:

• Audit objective.

• Scope.

• Schedule.

• Required participants.

• Evidence expectations.

Avoid surprises.

Phase 5 — Build Evidence Request List

Step 19 — Identify Required Evidence

Examples:

Policies

Procedures

Risk Register

RTP

SoA

Access Reviews

System Reports

Tickets

Vendor Assessments

Training Reports

Incident Records

Step 20 — Create Evidence Request Tracker

Use:

Request ID	Evidence	Owner	Due	Status

Step 21 — Validate Evidence Period

Ensure the requested evidence covers the audit period.

Example:

Audit Period:
Jan–Jun

Evidence:
Only current July configuration

This may not prove historical operation.

Step 22 — Minimize Sensitive Data

Request only what is needed.

Do not unnecessarily collect:

• Passwords.

• Private keys.

• Full customer datasets.

• Unredacted sensitive information.

Phase 6 — Conduct Opening Meeting

Step 23 — Confirm Audit Scope

Restate:

What is being audited?

What is not being audited?

Step 24 — Confirm Timeline

Review:

• Interviews.

• Evidence deadlines.

• Findings validation.

• Closing meeting.

Step 25 — Confirm Communication Channel

Define who coordinates questions.

Example:

Central Coordinator:
GRC Analyst

Step 26 — Confirm Escalation Process

Material issues discovered during fieldwork may need rapid escalation.

Phase 7 — Perform Process Walkthroughs

Step 27 — Select Process

Example:

Privileged Access Management

Step 28 — Ask Process Owner to Demonstrate Workflow

Follow:

Request
      ↓
Approval
      ↓
Provisioning
      ↓
Use
      ↓
Monitoring
      ↓
Review
      ↓
Removal

Step 29 — Validate Actual Practice

Compare:

Documented Procedure
vs
Actual Operation

Differences may indicate control weakness.

Step 30 — Record Walkthrough Notes

Include:

• Owner.

• Process.

• Systems.

• Inputs.

• Outputs.

• Evidence.

• Exceptions.

Phase 8 — Evaluate Control Design

Step 31 — Identify Control Objective

Example:

Objective:
Prevent inappropriate privileged access.

Step 32 — Review Control Statement

Example:

Privileged production access is reviewed quarterly and access without a valid business requirement is removed.

Step 33 — Evaluate Design

Ask:

Does the control address the risk?

Is the scope sufficient?

Is the frequency appropriate?

Is responsibility defined?

Does it produce evidence?

Can exceptions be identified?

Step 34 — Record Design Conclusion

Use:

Effective Design

Partially Effective Design

Ineffective Design

Document rationale.

Phase 9 — Identify Population

Step 35 — Determine Full Population

Example:

Control:
New User Access Approval

Population:
725 requests

Step 36 — Validate Completeness

Ask:

• Where did the population come from?

• Is every system included?

• Are cancelled transactions included?

• Are privileged accounts included?

An incomplete population undermines sampling.

Step 37 — Document Population Source

Example:

Source:
Identity platform export

Generated:
05 July 2026

Phase 10 — Select Audit Samples

Step 38 — Determine Sampling Method

Possible methods:

Random

Systematic

Judgmental

Risk Based

Step 39 — Consider Control Frequency

Example:

Quarterly Control
Population = 4

Approach:
Test all 4

Step 40 — Consider Risk

High-risk controls may justify deeper testing.

Step 41 — Document Sample Selection

Record:

Population

Sample Size

Sampling Method

Sample IDs

Rationale

Phase 11 — Test Operating Effectiveness

Step 42 — Define Test Procedure

Example:

For each selected access review:

Verify review population.

Verify reviewer.

Verify completion date.

Inspect access decisions.

Verify removals.

Step 43 — Inspect Evidence

Record each sample result.

Example:

Sample	Approval	Timely	Removal	Result
Q1	Yes	Yes	Yes	Pass
Q2	Missing	No	N/A	Fail
Q3	Yes	Yes	Yes	Pass

Step 44 — Document Exceptions

Do not immediately label every exception a nonconformity.

First determine:

• Cause.

• Frequency.

• Scope.

• Risk.

• Requirement.

Step 45 — Conclude Operating Effectiveness

Example:

Design:
Effective

Operating:
Partially Effective

Phase 12 — Test Automated Controls

Step 46 — Inspect Configuration

Example:

Control:
Cloud policy blocks public storage.

Review:

• Rule configuration.

• Scope.

• Enforcement status.

Step 47 — Review Access to Modify Control

Ask:

Who can change the rule?

If unrestricted, control reliability may be weak.

Step 48 — Review Change History

Check whether configuration changed during the audit period.

Step 49 — Review Exceptions

Identify:

Bypasses

Disabled Rules

Excluded Accounts

Emergency Changes

Phase 13 — Test Manual Controls

Step 50 — Review Control Performer

Confirm the correct person performed the activity.

Step 51 — Review Frequency

Example:

Required:
Monthly

Actual:
3 times in 6 months

This indicates inconsistency.

Step 52 — Review Evidence Quality

Manual evidence should demonstrate actual performance, not just a blank template.

Phase 14 — Test Hybrid Controls

Step 53 — Test Automation

Example:

Vulnerability scanner runs weekly.

Verify configuration and coverage.

Step 54 — Test Manual Review

Confirm security personnel actually review results.

Step 55 — Test Remediation Workflow

Trace:

Finding
      ↓
Ticket
      ↓
Owner
      ↓
Remediation
      ↓
Rescan

Phase 15 — Audit ISMS Clauses

Step 56 — Clause 4

Review:

Context

Interested Parties

Requirements

Scope

Check for significant changes.

Step 57 — Clause 5

Review:

Leadership

Policy

Roles

Authorities

Interview leadership where appropriate.

Step 58 — Clause 6

Review:

Risk Methodology

Risk Register

RTP

Objectives

Step 59 — Clause 7

Review:

Resources

Competence

Awareness

Communication

Document Control

Step 60 — Clause 8

Review whether planned processes actually operate.

Step 61 — Clause 9

Review:

Metrics

Internal Audit

Management Review

Step 62 — Clause 10

Review:

Nonconformities

Corrective Actions

Continual Improvement

Phase 16 — Audit Annex A / SoA Controls

Step 63 — Select SoA Controls

Use risk-based sampling.

Step 64 — Verify Applicability

Ask:

Why is this control applicable?

Step 65 — Verify Implementation Status

If SoA says:

Implemented

evidence should support that conclusion.

Step 66 — Verify Ownership

Interview control owner.

Step 67 — Verify Evidence

Follow the control through actual operation.

Phase 17 — Identify Audit Findings

Step 68 — Determine Requirement

Every nonconformity needs a requirement.

Example:

Requirement:
Access reviews occur quarterly.

Step 69 — Determine Condition

Observed:

Q2 review was not performed.

Step 70 — Identify Evidence

Example:

No Q2 review record.

IAM owner confirmed review was missed.

Step 71 — Describe Risk

Example:

Inappropriate privileged access may remain undetected for an extended period.

Step 72 — Draft Finding

Recommended structure:

The Access Control Standard requires quarterly privileged access reviews. The audit found that the Q2 2026 review was not performed for 18 production systems. As a result, inappropriate privileged access may not have been identified and removed in a timely manner.

Phase 18 — Classify Findings

Step 73 — Determine Nonconformity

A nonconformity exists when a requirement is not fulfilled.

Step 74 — Determine Severity Using Approved Methodology

Possible categories may include:

Major

Minor

Observation

Opportunity for Improvement

Classification should follow the audit program and relevant certification approach.

Step 75 — Consider Systemic Nature

Ask:

Is this isolated?

Repeated?

Systemic?

Does it affect a core ISMS process?

Does it create significant risk?

Phase 19 — Validate Findings

Step 76 — Review With Process Owner

Confirm facts.

Step 77 — Review Evidence

Resolve factual errors.

Step 78 — Avoid Negotiating Facts Away

If the requirement was not met, changing wording should not hide the issue.

Step 79 — Finalize Finding

Record:

Finding ID

Requirement

Condition

Evidence

Risk

Classification

Phase 20 — Conduct Closing Meeting

Step 80 — Present Overall Conclusion

Example:

ISMS generally effective,
with improvement required in
privileged access and supplier reassessment.

Step 81 — Present Significant Findings

Focus on:

• Major risks.

• Systemic issues.

• Recurring failures.

Step 82 — Explain Next Steps

Discuss:

Management Response

Root Cause

Corrective Action

Target Date

Retesting

Phase 21 — Issue Audit Report

Step 83 — Prepare Executive Summary

Include:

• Scope.

• Overall conclusion.

• Significant findings.

• Certification-readiness impact.

Step 84 — Include Detailed Findings

For each:

Criteria

Condition

Evidence

Risk

Classification

Owner

Step 85 — Issue Final Report

Distribute according to governance.

Potential recipients:

CISO

ISMS Manager

Risk Owners

Control Owners

Management

Phase 22 — Record Nonconformity

Step 86 — Create Corrective Action Record

Use:

Finding ID

Requirement

Nonconformity

Owner

Correction

Root Cause

Corrective Action

Target

Evidence

Retest

Step 87 — Assign Owner

Choose someone with authority to resolve the underlying issue.

Phase 23 — Perform Immediate Correction

Step 88 — Correct Immediate Failure

Example:

Finding:

Five terminated users retain accounts.

Correction:

Disable five accounts.

This addresses immediate exposure.

Step 89 — Preserve Evidence

Record correction completion.

Phase 24 — Perform Root Cause Analysis

Step 90 — Ask Why the Failure Occurred

Do not stop at:

Employee forgot.

Step 91 — Consider Common Causes

Unclear Ownership

Manual Process

Missing Automation

Poor Training

Technology Failure

Resource Constraint

Weak Governance

Process Design Failure

Step 92 — Use Five Whys

Example:

Problem:
Vendor reassessment overdue.

Why?
No reminder.

Why?
Spreadsheet manually maintained.

Why?
No workflow automation.

Why?
TPRM process was designed without lifecycle tooling.

Root Cause:
Inadequate reassessment tracking design.

Step 93 — Document Root Cause

Root cause should be specific and actionable.

Phase 25 — Develop Corrective Action

Step 94 — Define Action Addressing Root Cause

Weak:

Remind team to complete reviews.

Better:

Implement automated vendor reassessment scheduling, reminder, escalation, and overdue reporting.

Step 95 — Assign Corrective Action Owner

Example:

Owner:
TPRM Manager

Step 96 — Set Target Date

Consider finding severity and risk.

Step 97 — Define Closure Evidence

Example:

Workflow Configuration

Test Results

Completed Reassessments

Overdue Dashboard

Phase 26 — Review Corrective Action Quality

Step 98 — Confirm Action Addresses Root Cause

Ask:

Will this prevent recurrence?

Step 99 — Confirm Scope

If issue affected 18 systems, do not remediate only one.

Step 100 — Confirm Sustainability

Avoid solutions requiring constant manual heroics.

Phase 27 — Track Corrective Actions

Step 101 — Maintain Corrective Action Register

Use:

ID	Action	Owner	Target	Status

Step 102 — Use Standard Status

Open

Planned

In Progress

Blocked

Ready for Retest

Closed

Step 103 — Monitor High-Risk Findings

Review more frequently.

Step 104 — Escalate Overdue Actions

Example:

Minor
→ Owner

High-Risk Finding
→ CISO

Major / Certification Blocking
→ Executive Management

Phase 28 — Handle Blocked Remediation

Step 105 — Identify Blocker

Examples:

Budget

Vendor Dependency

Legacy System

Staffing

Technology Limitation

Step 106 — Evaluate Temporary Risk

Determine whether residual risk has increased.

Step 107 — Apply Compensating Controls

Where appropriate.

Step 108 — Escalate Risk Acceptance

If delay creates unacceptable exposure.

Phase 29 — Prepare for Retest

Step 109 — Confirm Management Says Action Is Complete

Do not close yet.

Step 110 — Collect Closure Evidence

Example:

New Process

Configuration

Training

Reports

Completed Samples

Step 111 — Define Retest Scope

Retesting should address the original issue and root cause.

Phase 30 — Perform Retesting

Step 112 — Validate Correction

Confirm immediate issue remains resolved.

Step 113 — Validate Corrective Action

Example:

Original:
Quarterly reviews missed

New Process:
Automated workflow

Test latest review cycle.

Step 114 — Test Operating Evidence

Verify:

Complete Population

Timely Review

Appropriate Approval

Remediation

Escalation

Step 115 — Determine Effectiveness

Use:

Effective

Partially Effective

Ineffective

Phase 31 — Close or Reopen Finding

Step 116 — Close Finding

Only when:

• Correction complete.

• Corrective action implemented.

• Evidence sufficient.

• Root cause addressed.

• Retest successful.

Step 117 — Record Closure

Include:

Closure Date

Retest Result

Reviewer

Evidence

Step 118 — Reopen if Failed

If retest fails:

Finding Remains Open
      ↓
Further Root Cause Review
      ↓
New Corrective Action

Phase 32 — Identify Recurring Findings

Step 119 — Review Finding History

Look for repeated themes:

Access Reviews

Vendor Assessments

Document Control

Training

Backup Testing

Step 120 — Escalate Recurring Failure

Repeat findings may indicate:

• Poor governance.

• Inadequate root-cause analysis.

• Weak accountability.

• Insufficient resources.

Phase 33 — Update the Risk Register

Step 121 — Determine Whether Finding Changes Risk

Example:

Backup recovery control fails
      ↓
Availability Risk Increases

Step 122 — Update Risk Rating

If necessary.

Step 123 — Update Risk Treatment

Add or modify treatment actions.

This connects assurance back to risk management.

Phase 34 — Update the Statement of Applicability

Step 124 — Review Affected Control

If SoA says:

Implemented

but internal audit finds systemic failure, status may need review.

Step 125 — Update Control Status

Possible:

Implemented
→
Partially Implemented

Step 126 — Link Finding

Reference corrective action where appropriate.

Phase 35 — Update Control Library

Step 127 — Improve Control Statement

Audit may reveal a vague control.

Example:

Old:
Access reviewed regularly.

Improved:

Privileged production access is reviewed quarterly by designated application owners, and inappropriate access is removed within five business days.

Step 128 — Update Frequency or Evidence

Where necessary.

Phase 36 — Feed Audit Results Into Management Review

Step 129 — Prepare Audit Summary

Report:

Audit Completed

Overall Conclusion

Major Findings

Minor Findings

Repeat Findings

Overdue Corrective Actions

Certification Impact

Step 130 — Highlight Management Decisions Required

Examples:

Additional Resource

Control Investment

Risk Acceptance

System Replacement

Process Redesign

Step 131 — Record Management Actions

Track owners and dates.

Phase 37 — Monitor Audit Metrics

Step 132 — Track Finding Metrics

Useful metrics:

Open Findings

Overdue Findings

Major Findings

Repeat Findings

Average Closure Time

Retest Failure Rate

Step 133 — Track Audit Completion

Example:

Planned Audits:
6

Completed:
5

Completion:
83%

Step 134 — Track Corrective Action Aging

Example:

Finding	Age
F-001	15 Days
F-002	85 Days
F-003	210 Days

Older high-risk findings require attention.

Phase 38 — Establish KRIs

Potential KRIs:

High Findings Overdue

Repeat Nonconformities

Failed Retests

Controls With No Evidence

Audits Not Completed as Planned

These show assurance-program health.

Phase 39 — Prepare for Certification Audit

Step 135 — Review Internal Audit Coverage

Confirm relevant ISMS areas have been audited.

Step 136 — Review Major Nonconformities

Certification-blocking issues should be addressed.

Step 137 — Review Corrective Action Evidence

Organize:

Finding
      ↓
Root Cause
      ↓
Action
      ↓
Evidence
      ↓
Retest
      ↓
Closure

Step 138 — Prepare Auditor Walkthrough

Be ready to demonstrate internal assurance is functioning.

Phase 40 — Manage External Audit Findings

The same core corrective-action workflow can be applied to certification findings.

Step 139 — Record External Finding

Maintain source:

Internal Audit

Stage 1

Stage 2

Surveillance

Recertification

Step 140 — Prioritize According to Classification

External certification timelines may influence deadlines.

Step 141 — Submit Corrective Action Evidence

Follow certification-body requirements.

Step 142 — Retain Closure Record

Keep for future surveillance.

Internal Audit Operational Checklist

Planning

• Audit universe defined.

• Risks reviewed.

• Previous findings reviewed.

• Changes reviewed.

• Annual audit program approved.

• Auditor independence considered.

• Auditor competence confirmed.

Audit Setup

• Objective defined.

• Scope defined.

• Criteria defined.

• Audit period defined.

• Process owners identified.

• Audit plan prepared.

• Evidence request list issued.

• Opening meeting completed.

Fieldwork

• Walkthroughs performed.

• Control design assessed.

• Populations validated.

• Samples selected.

• Automated controls tested.

• Manual controls tested.

• Hybrid controls tested.

• Clause requirements tested.

• SoA controls tested.

• Evidence retained.

Findings

• Requirement identified.

• Condition documented.

• Evidence documented.

• Risk described.

• Classification assigned.

• Finding validated.

• Closing meeting completed.

• Audit report issued.

Corrective Action

• Immediate correction completed.

• Root cause identified.

• Corrective action defined.

• Owner assigned.

• Target date assigned.

• Closure evidence defined.

• Progress monitored.

• Overdue items escalated.

Retesting

• Closure evidence obtained.

• Retest performed.

• Root cause remediation validated.

• Effectiveness determined.

• Finding closed or reopened.

Continuous Improvement

• Risk register updated where required.

• RTP updated where required.

• SoA updated where required.

• Control library updated.

• Management review input prepared.

• Repeat findings analyzed.

• Metrics reported.

Quick Reference — Finding Lifecycle

Audit Exception
      ↓
Requirement Not Met?
      │
      ├── No → Observation / No Finding
      │
      └── Yes
             ↓
Nonconformity
      ↓
Immediate Risk?
      │
      ├── Yes → Correction
      │
      └── No
             ↓
Root Cause Analysis
      ↓
Corrective Action
      ↓
Implementation
      ↓
Retest
      ↓
Effective?
      │
      ├── Yes → Close
      │
      └── No → Reopen / Further Action

Quick Reference — Audit Evidence Decision Tree

Control Claim
      ↓
Evidence Available?
      │
      ├── No → Potential Exception
      │
      └── Yes
             ↓
Correct Period?
      │
      ├── No → Insufficient Evidence
      │
      └── Yes
             ↓
Complete Population?
      │
      ├── No → Validate Population
      │
      └── Yes
             ↓
Sample / Test
      ↓
Exceptions?
      │
      ├── No → Effective
      │
      └── Yes → Evaluate Severity & Systemic Impact

Audit Working Paper Template

Use:

Audit Area:

Requirement:

Control ID:

Control Objective:

Control Owner:

Control Frequency:

Audit Period:

Population:

Sample:

Test Procedure:

Evidence Reviewed:

Exceptions:

Design Conclusion:

Operating Conclusion:

Finding Reference:

Auditor:

Review Date:

Nonconformity Record Template

Finding ID:

Source:

Requirement:

Condition:

Evidence:

Risk / Impact:

Classification:

Process Owner:

Control Owner:

Correction:

Root Cause:

Corrective Action:

Action Owner:

Target Date:

Closure Evidence:

Retest Date:

Retest Result:

Closure Date:

Corrective Action Quality Test

Before approving corrective action, ask:

Does it fix the immediate issue?

Does it address root cause?

Does it cover the full affected population?

Is it sustainable?

Is an owner assigned?

Is there a deadline?

Can effectiveness be tested?

Will evidence be available?

If several answers are “No”, the corrective action should be improved.

Common Audit Failures

Failure 1 — Auditing Documents Only

Policy Exists
→ Pass

This does not test implementation.

Failure 2 — No Population Validation

A beautiful sample from an incomplete population provides weak assurance.

Failure 3 — Inquiry Accepted as Evidence

Statements should be corroborated.

Failure 4 — Auditor Audits Own Work

Objectivity is weakened.

Failure 5 — Findings Are Vague

Example:

Security needs improvement.

Not actionable.

Failure 6 — Every Exception Called Major

Classification loses credibility.

Failure 7 — Findings Downgraded to Avoid Problems

Assurance should remain objective.

Failure 8 — Root Cause Is “Human Error”

This usually stops analysis too early.

Failure 9 — Findings Closed on Screenshot Alone

The underlying process may still fail.

Failure 10 — Audit Results Do Not Update Risk

Assurance remains disconnected from governance.

Example End-to-End Case

Original Control

Control:
Critical vendors reassessed annually.

Audit Test

Population:

40 Critical Vendors

Evidence:

35 Current

5 Overdue

Finding

Five of forty critical vendors were not reassessed within the required annual period, resulting in reduced assurance that material changes in vendor security posture are identified in a timely manner.

Correction

Complete 5 assessments.

Root Cause

Manual spreadsheet tracking
without automated reminders or escalation.

Corrective Action

Implement automated reassessment
scheduling, reminders, and escalation.

Retest

Three months later:

Critical Vendors:
42

Current:
42

Overdue:
0

Result

Corrective Action:
Effective

Finding:
Closed

This is what a complete assurance lifecycle looks like.

Runbook Deliverables

A completed assurance package should contain:

01 — Annual Internal Audit Program

02 — Audit Plan

03 — Audit Evidence Request List

04 — Interview Schedule

05 — Audit Working Papers

06 — Control Testing Worksheets

07 — Audit Findings Register

08 — Internal Audit Report

09 — Nonconformity Register

10 — Root Cause Analysis Records

11 — Corrective Action Register

12 — Remediation Evidence

13 — Retest Records

14 — Finding Closure Register

15 — Audit Metrics Dashboard

16 — Management Review Audit Summary

Runbook Success Criteria

The internal audit and corrective-action program is operating effectively when:

Audits occur as planned

Auditors remain objective

Evidence is tested

Populations are validated

Controls are assessed for design and operation

Findings are clearly written

Root causes are identified

Corrective actions address recurrence

Remediation is tracked

Retesting occurs before closure

Repeat findings decrease

Risk and SoA records reflect audit results

Management receives meaningful assurance

Practical Assurance Mindset

A weak audit asks:

Do you have the document?

A better audit asks:

Is the process implemented?

A mature audit asks:

Is the process appropriately designed, operating consistently, producing reliable evidence, reducing the intended risk, and improving when failures occur?

That is the mindset of effective ISO/IEC 27001 assurance.

Runbook Complete

With this runbook, you have completed the operational assurance lifecycle:

Audit
      ↓
Evidence
      ↓
Finding
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Retest
      ↓
Management Review
      ↓
Improvement

Together with Runbook 01 — ISO/IEC 27001 Implementation & Certification Readiness, you now have both sides of the ISO operating model:

Implementation
      +
Assurance
      =
Sustainable ISMS

Module Complete — ISO/IEC 27001

You have now completed the ISO/IEC 27001 module covering:

01 — Introduction to ISO/IEC 27001

02 — ISMS Fundamentals

03 — ISO Clauses Explained

04 — Context of the Organization

05 — Leadership & Governance

06 — Risk Assessment

07 — Risk Treatment Plan

08 — Statement of Applicability

09 — Annex A Controls Overview

10 — Certification Process

and the practical activities:

Lab 01
Build an ISO/IEC 27001 ISMS

Lab 02
Build an ISO/IEC 27001 Statement of Applicability & Control Mapping

Runbook 01
ISO/IEC 27001 Implementation & Certification Readiness

Runbook 02
ISO/IEC 27001 Internal Audit, Nonconformity & Corrective Action Management

You now have the practical foundation required to move beyond general ISO/IEC 27001 implementation into more specialized security and compliance standards.

What’s Next?

➡️ Next Module — ISO Cloud Security Standards

The recommended next step is to extend the ISO/IEC 27001 foundation into cloud-specific assurance.

The next module can cover:

ISO/IEC 27017
Cloud Security Controls
      ↓
ISO/IEC 27018
Protection of PII in Public Clouds
      ↓
Cloud Shared Responsibility
      ↓
Cloud Supplier Assurance
      ↓
Cloud Control Mapping
      ↓
Cloud Compliance Evidence
      ↓
Cloud Audit & Certification Readiness

This allows learners to understand how the ISO/IEC 27001 ISMS foundation is extended into AWS, Azure, SaaS, and enterprise cloud environments.