Module 5 · Internal Audit Programme

Last updated: April 29, 2026

Internal audits are the discipline of independently verifying that controls operate as designed. Required by ISO 27001 (clause 9.2), referenced in SOC 2 Common Criteria, and a generally good idea — they catch issues before external auditors find them, before regulators find them, and before incidents reveal them. This module covers running internal audits that produce real value, not just paperwork.

Internal vs external — different jobs

• External audit — independent third party (CB, CPA firm) assesses against a standard. Outcome: certification or attestation. Annual or biennial
• Internal audit — performed by your own org’s audit function (or competent staff outside the audited area). Continuous improvement. As-needed and on schedule

Internal audits should make external audits boring. If your external auditor finds issues your internal audit didn’t, your internal audit isn’t working.

Independence — the harder-than-it-sounds rule

Auditor must be independent of the audited area. Practically:

• Engineering team members don’t audit engineering controls
• The CISO doesn’t audit security controls they own
• External consultants can supplement when in-house independence is hard
• For very small orgs: cross-functional audit (HR audits IT controls, etc.) with care

If independence is faked, audits produce false comfort. Worse than no audit.

The audit programme

Annual planning document covers:

• Scope of audits planned for the year
• Frequency (some controls quarterly, some annually)
• Auditor assignments
• Resource allocation (hours / cost)
• Reporting cadence to leadership

Cover all in-scope controls over a defined cycle (usually annual or biennial). Risk-weight: critical controls audited more frequently.

The audit lifecycle

Planning

• Define scope (specific controls, period covered)
• Identify auditees (control owners)
• Notify auditees with timeline (typically 2-4 weeks notice)
• Develop audit checklist tied to control objectives
• Define sampling approach — for evidence-based controls, how many samples?

Execution

• Document review — policies, procedures, prior audit results
• Walk-throughs with control owners
• Evidence sampling — pull records, screenshots, logs, system configurations
• Testing — does the control actually do what’s documented?
• Interview — does the operator understand the control? Can they execute without prompting?

Reporting

• Findings categorized: Major nonconformity, Minor nonconformity, Observation, Opportunity for improvement
• For each finding: description, evidence, root cause, recommended action, control owner, due date
• Management response — agreement, disagreement (with rationale), corrective action plan
• Distribution: control owner, area manager, security leadership, board for material findings

Follow-up

• Track corrective actions to completion
• Re-audit affected controls after corrective action
• Report status to management review

Sampling — practical guidance

You can’t audit everything. Sampling rules of thumb:

• Frequency-based: if a control runs daily, sample 25-30 days; weekly, sample 8-10; monthly, sample 3-4
• Risk-weighted: sample more where risk is higher (production access reviews vs dev)
• Random: within the population, use a random sample
• Targeted: in addition to random, target specific items (departed employees, terminated vendors) — most issues hide there

Common audit areas — the recurring checklist

Access management

• New hire access provisioning — who approved, what was provisioned, was role appropriate?
• Departure access removal — same-day deactivation across all systems?
• Access reviews — quarterly, evidenced, with manager sign-off?
• Privileged access — logged, time-bounded, MFA enforced?
• Service accounts — owned, reviewed, rotated?

Change management

• Sample of production changes — review/approval before deploy?
• Emergency changes — documented post-hoc within timeframe?
• Backout plans documented?
• Testing evidence per change?

Incident management

• Incidents in the period — handled per procedure?
• Severity classifications consistent?
• Notification timelines met?
• Lessons learned captured and acted on?

Vulnerability management

• Scans run on schedule?
• Findings remediated within SLA?
• Exceptions documented with risk acceptance and target date?
• Patching status across the fleet?

Vendor management

• New vendors assessed before onboarding?
• Annual reassessments completed?
• SOC 2 / ISO certs current for critical vendors?
• Departure offboarding evidence?

Backup and DR

• Backups running on schedule?
• Recovery tested? Documented results?
• RPO/RTO objectives met in tests?
• Backups encrypted? Stored off-site?

Logging and monitoring

• Required logs collected from in-scope systems?
• Retention meets policy?
• Log integrity protections in place?
• Detection rules reviewed periodically?
• Alerts triaged within SLA?

Documenting findings well

Bad: “Access reviews not performed.”

Good: “Q2 2026 quarterly access review for production AWS accounts was not completed. Last documented review was 2026-01-12. Per policy SEC-AC-001 v3, reviews are due within 30 days of quarter end. Sample of 10 active production users showed 2 with access exceeding their current role. Recommend: complete Q2 review with documented evidence within 30 days; investigate role-creep root cause; consider automation.”

Specifics: dates, samples, policy references, root cause hypothesis, recommendation. Generic findings get generic responses.

Severity calibration

• Major nonconformity: systemic failure of a control that’s required by standard or material to risk posture. Threatens certification. Requires immediate corrective action
• Minor nonconformity: isolated failure or partial gap. Corrective action within 90 days typically
• Observation: no failure but a weakness or risk worth noting. No required action; encouraged improvement
• Opportunity for improvement: things working as designed; suggestion for stronger practice

Calibration matters. Inflating findings to look thorough creates audit fatigue. Suppressing findings creates audit hollowness. Balance.

Getting follow-through on corrective actions

• Each finding has a named owner and date
• Tracked in a system (audit management tool, Jira, even structured spreadsheet)
• Status reviewed at monthly security ops meetings
• Open past due → escalated to leadership
• Closed actions verified by re-audit (sample); not just self-attestation

Internal audit metrics

• Audits planned vs completed (programme execution)
• Findings opened / closed / overdue
• Average time to close findings
• Repeat findings rate (same finding in successive audits = weak corrective action)
• External audit findings vs internal audit findings (external should find few)

Common pitfalls

• Auditor is the same person as the auditee. Independence broken; findings biased
• Findings as opinions, not evidence. “I think the process needs improvement” without sampled evidence
• No corrective action follow-through. Findings recur year after year
• All controls audited annually but trivially. Audit becomes ceremony
• Audit avoids inconvenient areas. Engineering avoids auditing release process; HR avoids auditing termination process
• Findings reports not read. No leadership engagement; the audit function is detached

Closing the GRC track

This completes the GRC track. You can articulate the relationship between governance, risk, and compliance; implement and maintain ISO 27001 and SOC 2; run a vendor risk programme; and execute internal audits that produce real findings and follow-through. The next track shifts to the technical foundations of cryptography and PKI — the substrate underneath most security controls.