Auditing ISO 27001 Annex A 5.35 is the objective verification of an organization’s security management through impartial and technical assessments. The Primary Implementation Requirement is a scheduled, independent review of controls, which yields the Business Benefit of transparent risk reporting and verified adherence to global security standards.
This technical verification tool is designed for lead auditors to confirm the organisational independence and technical rigour of security assessments. Use this checklist to validate compliance with ISO 27001 Annex A 5.35 (Independent review of information security).
1. Independent Review Schedule Formalisation Verified
Verification Criteria: A documented audit or review programme exists, specifying the frequency and scope of independent assessments for the ISMS and its technical controls.
Required Evidence: Approved Annual Audit Plan or Compliance Review Schedule with version history and management sign-off.
Pass/Fail Test: If the organisation lacks a planned schedule for independent reviews or relies solely on ad-hoc assessments, mark as Non-Compliant.
2. Reviewer Objectivity and Independence Confirmed
Verification Criteria: Personnel conducting the reviews are independent of the area being audited to ensure objectivity and avoid conflicts of interest.
Required Evidence: Auditor appointment records or external service contracts; verification that the internal auditor does not manage the controls they are testing.
Pass/Fail Test: If the IT Manager is found to be the sole person auditing the technical security configurations they implemented, mark as Non-Compliant.
3. Review Methodology and Criteria Standards Validated
Verification Criteria: The independent review is performed against a defined set of criteria (e.g. ISO 27001:2022 clauses) using a repeatable methodology.
Required Evidence: Internal Audit Procedure or Assessment Framework document detailing the sampling methods and evidence-gathering techniques.
Pass/Fail Test: If the review report lacks a defined set of audit criteria or fails to explain how conclusions were reached, mark as Non-Compliant.
4. Technical Security Testing Integration Verified
Verification Criteria: The independent review includes or references technical validation, such as penetration testing or vulnerability assessments, to verify control effectiveness.
Required Evidence: Recent Penetration Test reports or Vulnerability Scan results performed by an independent third party.
Pass/Fail Test: If the “Independent Review” is purely document-based and fails to verify that technical configurations are active and effective, mark as Non-Compliant.
5. Management Reporting and Transparency Confirmed
Verification Criteria: Results of the independent review, including identified non-conformities and risks, are formally reported to top management.
Required Evidence: Final Internal Audit Report or Executive Summary presented at a Management Review Meeting (MRM).
Pass/Fail Test: If audit findings are suppressed or only reported to mid-level management without reaching the designated ISMS owner, mark as Non-Compliant.
6. Corrective Action Tracking Integrity Verified
Verification Criteria: All non-conformities identified during the independent review are recorded in a tracked log with assigned owners and realistic remediation dates.
Required Evidence: Non-Conformity Report (NCR) log or a CAPA (Corrective and Preventive Action) tracker showing current status.
Pass/Fail Test: If the organisation cannot produce a list of open findings from the last independent review and their respective remediation status, mark as Non-Compliant.
7. Remediation Evidence and Closure Validation Confirmed
Verification Criteria: Evidence of remediation for previously identified findings is reviewed and validated by the independent reviewer before the finding is closed.
Required Evidence: Re-test logs, configuration screenshots, or “Follow-up Audit” reports confirming that the root cause was addressed.
Pass/Fail Test: If findings are marked as “Closed” in the tracker based on a verbal update without technical evidence of the fix, mark as Non-Compliant.
8. Professional Competence of Reviewers Validated
Verification Criteria: Personnel or third-party firms conducting the review possess the necessary certifications and technical expertise relevant to the scope.
Required Evidence: Training certificates (e.g. CISA, ISO 27001 Lead Auditor) or corporate capability statements for external consultancy firms.
Pass/Fail Test: If the review was conducted by personnel without formal audit training or a basic understanding of the ISO 27001 standard, mark as Non-Compliant.
9. Continuous Improvement Loop Evidence Identified
Verification Criteria: The outcomes of independent reviews are used to adjust the ISMS, policy frameworks, or technical standards to prevent recurrence of issues.
Required Evidence: Updated Policies or Technical Standards with changelogs citing “Internal Audit Finding” as the driver for the update.
Pass/Fail Test: If the same non-conformities appear across multiple audit cycles without any change to the underlying process, mark as Non-Compliant.
10. Scope and Boundary Alignment Verified
Verification Criteria: The independent review covers the entire defined scope of the ISMS, including all relevant technical assets and physical locations.
Required Evidence: The “Scope” section of the audit report cross-referenced against the organisation’s official Statement of Applicability (SoA).
Pass/Fail Test: If the independent review intentionally excluded high-risk areas of the business (e.g. offshore development sites) without justification, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Independent Review | GRC tool identifies that a “Self-Assessment” was completed by the CISO. | A self-assessment is not independent. Auditor must verify that a third party or separate department conducted the test. |
| Audit Scope | Tool records “ISO 27001 Audit” as complete. | Verify the SoA coverage. GRC tools often audit only the cloud tenant, ignoring physical security and local networking. |
| Competence | Platform marks “Reviewer” as a valid user role. | Check the reviewer’s CV or Lead Auditor certificate. The tool cannot judge if the person actually knows how to audit. |
| Technical Depth | GRC tool pulls in a list of “Policy Documents.” | The auditor must verify technical settings. Independent review must check if the policy matches the firewall reality. |
| Remediation | Tool logs a task as “Done” by the IT team. | Verify the Validation. An independent reviewer must sign off on the fix; IT cannot mark their own homework as finished. |
| RCA Integration | Platform provides a “Notes” section for findings. | Demand a Root Cause Analysis (RCA). If the tool doesn’t force an RCA, the organisation will just fix the symptom. |
| Reporting | Tool sends an automated “Status Report” to the CEO. | Verify the Management Review minutes. CEO awareness in a dashboard is not the same as a formalised review of non-conformities. |
About the author
