An ISO 27001 internal audit that improves the system

An internal audit gives the organization a chance to discover where its information security management system (ISMS) differs from its intentions. The useful result is a supported assessment and a clear improvement path for each material finding—not simply a folder of screenshots prepared for certification.

For a technical leader, the central question is whether the system works across real services, people, and handoffs. A policy can be approved while its implementation fails. An audit should expose that difference without turning every operational imperfection into an unsupported compliance finding.

Establish what the audit must demonstrate

ISO/IEC 27001, clause 9.2, requires internal audits at planned intervals to assess conformity with the organization's ISMS requirements and the standard, and whether the ISMS is effectively implemented and maintained. The audit programme must consider the importance of processes and previous audit results, with auditors selected to ensure objectivity and impartiality.

An internal audit can be performed by employees or an external specialist engaged for that purpose. It does not issue a certificate: certification is a separate assessment by an independent certification body. Internal audits remain part of operating the ISMS after certification, not just preparation for the initial assessment.

ISO 27001 does not prescribe a universal annual internal-audit frequency. As a practical recommendation, use a documented schedule that reflects risk, changes, and previous findings, with more frequent attention to unstable or critical processes.

Agree criteria, boundaries, and responsibilities

An individual audit need not examine everything simultaneously. The programme should provide coverage of the scoped ISMS over its planned cycle, rather than repeatedly inspecting only familiar controls.

Document these decisions before requesting evidence:

Annex A is not a requirement to implement every control identically. Check whether applicability decisions and exclusions are justified, then test the commitments the organization has actually made.

Choose competent auditors who understand both management-system requirements and the controls examined. Avoid having people audit their own work. In a small engineering team, an external auditor or cross-functional reviewer may resolve conflicts, provided they have sufficient competence and access to evidence.

Build evidence around operational questions

Start with the scope, risk assessment, treatment plan, Statement of Applicability, policies, previous findings, and relevant operational records. These explain what should happen and where failures would matter most.

Then formulate testable questions. For privileged access, ask whether approvals precede access, reviews cover the relevant account population, and revoked permissions actually disappear. A signed access policy establishes intent; account exports, approval records, and removal logs establish operation.

Create a sampling plan that includes recent changes, critical services, previous weaknesses, and exceptions. Record the population, selection method, period, and rationale. Practical sampling need not use a single fixed sample size, but it must be explainable. A handful of convenient screenshots rarely represents a whole period of operation.

Triangulate records with interviews and observation. If owners describe a manual handoff, inspect completed handoffs. If evidence contradicts an interview, investigate rather than choosing the more reassuring account. Record limitations when a system cannot provide historical evidence; do not silently infer past performance from its current configuration.

Follow one control through a worked example

Illustrative assumptions: a SaaS company audits employee departures over three months. Its procedure requires access removal by the employee's departure time. HR records show 12 departures; the auditor examines all three privileged users and four additional departures across different teams.

The auditor compares HR departure timestamps with identity-provider events, application account status, and offboarding tickets. One former engineer's identity-provider account was disabled on time, but a separately managed repository account remained active for two days.

Before rating the finding, establish whether the account could authenticate, what permissions remained, and whether an approved exception existed. Interview HR and the application owner to understand the handoff. Expand testing to other departures involving separately managed applications if the omission appears systemic.

A defensible finding identifies the procedure breached, the observed condition, supporting records, affected scope, and potential consequence. It should not claim unauthorized access occurred unless evidence supports that conclusion.

Separate findings from assumptions

A nonconformity requires evidence that a requirement was not fulfilled. An improvement opportunity identifies a useful enhancement without demonstrating a breach. An unresolved question remains open until sufficient evidence supports a conclusion.

Use consistent classifications and prioritize findings by exposure, recurrence, and breadth. Do not let a severity label replace the reasoning. Give process owners an opportunity to correct factual errors, while retaining auditor responsibility for the conclusion.

The report should state scope, criteria, methods, limitations, findings, and the overall assessment supported by the work performed.

Make corrective action more than closure

An action plan should identify an owner, due date, immediate correction, root cause, and the change intended to prevent recurrence. Removing the repository account corrects that instance. Fixing the incomplete application inventory and HR-to-IT handoff addresses the process.

Avoid accepting “human error” as the complete root cause when the workflow depends on memory or lacks ownership. Define effectiveness criteria before closing the action: for example, subsequent departures must include reconciled checks against the relevant application inventory.

A completed ticket proves execution, not necessarily effectiveness. After implementation, inspect another sample and retain the verification result. Reopen the action if the same failure recurs.

Feed results into management and everyday work

Report recurring weaknesses, overdue actions, resource needs, and significant risk decisions to relevant management. Internal-audit results are an input to management review under ISO 27001; the review is a distinct activity with other required inputs, not merely a meeting to approve the audit report.

Secani connects requirements, evidence, owners, tasks, and review decisions so assessment and follow-up remain in context. Keep supporting records attached to the relevant controls and preserve human approval of evidence conclusions. Use our audit-readiness guide to organize those records before fieldwork.

A practical next step is to choose one critical process, appoint an impartial auditor, and write its criteria and sampling plan. Schedule the effectiveness check when assigning corrective actions—not after everyone considers them finished.