There is a misconception associated with many information security management systems: viewing the internal audit as a mere paperwork exercise, to be carried out once a year to ensure the organisation is prepared for the certification body’s visit. In this view, the audit aims to verify that procedures exist, that documents are signed, and that forms are completed.
All true, all necessary, but it is not enough.
Clause 9.2 of ISO/IEC 27001, in fact, calls for something more specific: to ascertain that the management system complies with the requirements and that it is effectively implemented and maintained. The right question is not ‘does the control exist?’, but ‘does the control work?’. And it is a question answered with evidence, not with statements.
A risk-based audit programme
The starting point is the audit programme, which the standard requires to be planned taking into account the significance of the processes and the results of previous audits.
In practice, this means that not all areas warrant the same level of scrutiny or the same frequency of audits. Processes handling the most critical information, those that have led to incidents or findings in the past, and those affected by recent changes — such as a migration, a reorganisation or a new supplier — must be audited more frequently and in greater depth.
Criteria and scope must then be defined for each audit. These include the requirements of the standard, of course, but also internal policies, the Statement of Applicability, and the security objectives the company has set for itself. An audit without explicit criteria produces opinions; explicit criteria produce findings and unequivocal evidence.
See for yourself: the evidence
Effectiveness isn’t demonstrated with words, but through sampling. Let’s take a classic control measure such as the revocation of access rights at the end of an employment contract. A mere existence check stops at the procedure published on the intranet. An effectiveness check, however, involves obtaining from HR the list of terminations over the last six months, selecting a sample and checking the systems: have those user accounts been deactivated? Within how many days? Who authorised the exceptions? The same approach applies across the board: for backups, a plan alone is not enough; you need execution logs and at least one documented test restore; for vulnerability management, a policy alone is not enough; you need scans and the actual remediation times for the selected sample.
The sampling must be stated in the report: how many items, how they were selected, and from which population. Not out of pedantry, but because this is what makes the result reproducible and credible — even in the eyes of the external auditor, who will return to sample from those same populations.
Tests, not just interviews
Interviews remain invaluable for understanding how a process actually works, but an effectiveness audit combines them with more robust techniques. A walkthrough follows a real transaction from start to finish — an access request, a change in production — observing every step. Re-execution involves independently repeating the check: if the rule states that logs are reviewed weekly, the auditor selects a random week and looks for evidence of the review. Technical tests, where the scope permits, directly verify configurations: active encryption, multi-factor authentication in use, and genuine network segregation rather than merely on paper. This is not a perfunctory interview, but a formal and substantive verification.
Findings and root causes: the value lies in the ‘why’
When an audit identifies a deviation, the most delicate part begins. Clause 10.2 clearly distinguishes between two actions: the correction, which resolves the specific issue, and the corrective action, which removes the cause so that the problem does not recur. If three accounts belonging to former employees are still active, deactivating them is the correction. Corrective action first requires an analysis of the causes: does communication between staff and IT take place via untraceable emails? Does the process fail to cover external collaborators? Is there no one with explicit responsibility for the final step? Analysing root causes seeks the ‘why’ within the process, not the ‘culprit’ amongst individuals, and this is the difference between a system that learns and one that accumulates identical findings, year after year.
Each finding then deserves an honest classification — major non-conformity, minor non-conformity, observation, opportunity for improvement — and a plan with a responsible person and a deadline. Closure does not mean simply making a promise: it means verifying that the action has been implemented and that it works.
Measuring effectiveness over time: the indicators
Between audits, clause 9.1 requires monitoring and measurement. This is where a few well-chosen indicators come into play: median time to revoke access, percentage of backup restores successful on the first attempt, remediation times for critical vulnerabilities, and percentage of corrective actions closed by the deadline. You don’t need a massive dashboard: you need figures that someone actually looks at, with thresholds that trigger questions. These indicators give continuity to the audit work and pave the way for the next step.
Management review: from formality to decision-making forum
All this material comes together in the management review required by clause 9.3, which is the point at which the management system demonstrates that it is a governance tool and not merely a file. The standard lists the inputs: audit results, status of corrective actions, trends in indicators, feedback from interested parties, and changes in risks. But it is the outputs that measure the quality of the review: decisions. Resources allocated or reallocated, priorities revised, objectives updated – each with a responsible person and a date. A review report that merely ‘takes note’ is the most reliable sign of a system that is running on empty; a report that sets out decisions is proof, to anyone who asks, that safety within the organisation has a functioning management cycle.
If you want to put your system to the test
If, whilst reading this, you recognised yourself more in the ‘existence’ assessment than in the ‘effectiveness’ one, now is the right time to raise the bar: the certification body’s next surveillance audit — and, increasingly, customer questionnaires — will be looking precisely at that.
Rexilience supports organisations with ISO/IEC 27001 effectiveness audits and gap assessments, conducted using sampling and testing methods: the aim is not to produce yet another document, but to show you where your system actually works and where it is merely claiming to work.
Do you want to find out whether your ISO 27001 system is truly effective?
Contact us to discuss this with our experts and assess the actual status of your management system.