Implementing ISO 27001 Annex A 5.35 is a critical assurance mandate requiring the objective, independent assessment of information security controls by competent reviewers separated from the implementation process. This control forces organizations to valid technical reality against documentation, providing the business benefit of unbiased validation, reduced blind spots, and defensible regulatory compliance.
ISO 27001 Annex A Independent Review of Information Security Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.35. This control demands that your information security practices be audited by objective, competent reviewers who are technically capable of testing the reality of your controls, rather than simply reading your policy documents.
1. Formally Define ‘Independence’ Criteria
Control Requirement: Ensure the reviewer has no conflict of interest with the area being reviewed. Required Implementation Step: Create a policy statement explicitly barring IT managers from auditing their own infrastructure and C-levels from auditing their own governance decisions. Define “Independence” as: “A reviewer who has not designed, implemented, or managed the control within the last 12 months.”
Minimum Requirement: A signed ‘Conflict of Interest’ declaration for every internal or external reviewer.
2. Establish a ‘Hard’ Review Schedule
Control Requirement: Reviews must occur at planned intervals. Required Implementation Step: Publish an annual audit calendar that is approved by Top Management and cannot be moved by operational teams. Schedule reviews to occur before external certification audits to allow time for remediation, covering all 93 controls over a 3-year cycle (at minimum).
Minimum Requirement: A published 12-month audit schedule with assigned dates and named reviewers.
3. Define ‘Significant Change’ Triggers
Control Requirement: Conduct reviews when significant changes occur. Required Implementation Step: Update your Change Management Policy to automatically trigger an independent security review for specific events: major infrastructure migrations (e.g., on-prem to Cloud), new product launches, or mergers/acquisitions. Do not wait for the annual cycle.
Minimum Requirement: A “Post-Implementation Review” step in your Change Management procedure for high-impact changes.
4. Vet Reviewer Competence
Control Requirement: Reviewers must be competent to assess the specific controls. Required Implementation Step: Verify that the assigned reviewer has the technical skills relevant to the scope (e.g., a network engineer should review firewall rules; a lawyer/DPO should review privacy clauses). Do not assign a “Compliance Officer” with no technical background to review AWS security groups.
Minimum Requirement: CVs or qualification records on file for all internal and external reviewers.
5. Execute Technical Reality Checks
Control Requirement: Verify the implementation of information security, not just the documentation. Required Implementation Step: Instruct reviewers to ignore the policy manual initially and go straight to the configuration. If the policy says “passwords must be 12 characters,” the reviewer must query the Active Directory or Okta settings to prove it.
Minimum Requirement: Audit evidence must include screenshots of configurations, not just copies of policies.
6. Conduct Physical and Personnel Interviews
Control Requirement: Assess the ‘People’ aspect of the ISMS. Required Implementation Step: The reviewer must interview random staff members (not just heads of department) to test their awareness. Ask: “How do you report an incident?” or “Show me how you lock your screen.” Record the answers verbatim.
Minimum Requirement: Interview notes from at least 5% of the staff within the scoped area.
7. Integrate Penetration Testing Results
Control Requirement: Use technical testing as an input for the independent review. Required Implementation Step: Commission annual third-party penetration tests. The independent reviewer must analyse these reports to validate if the technical vulnerabilities align with the risk assessment and if the remediation was effective.
Minimum Requirement: A Pen Test report referenced as evidence within the Independent Review.
8. Produce Uncensored Audit Reports
Control Requirement: Report results to the management body. Required Implementation Step: Produce a formal report detailing Non-Conformities (NCs) and Opportunities for Improvement (OFIs). This report must go directly to Top Management without being “sanitised” or edited by the IT team or the CISO.
Minimum Requirement: A final audit report signed off by the Board or Steering Committee.
9. Track Corrective Actions to Closure
Control Requirement: Ensure issues identified are actually fixed. Required Implementation Step: Log every finding in a central Non-Conformity Register (NCR). Assign a specific owner and a deadline. The review is not “complete” until the remediation plan is agreed upon.
Minimum Requirement: An NCR log where every audit finding has a status, owner, and due date.
10. Verify Remediation Effectiveness
Control Requirement: Confirm that the fix works. Required Implementation Step: Schedule a follow-up review for closed non-conformities. The original reviewer (or another independent party) must re-test the control to ensure the fix was implemented and didn’t introduce new risks.
Minimum Requirement: Evidence of “Re-testing” appended to the original audit finding.
ISO 27001 Annex A 5.35 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Independence | The CISO logging in as “Auditor” to mark their own work as “Compliant”. | If the person who wrote the policy checks the policy, you have zero assurance. Auditors must be separate from implementers. |
| Technical Competence | Using a GRC tool’s “Auto-Audit” feature that only checks if a field is filled in. | A script checking if a field is not null is not an audit. A human needs to verify if the content is correct and secure. |
| Evidence | Linking a policy document as “Evidence” of implementation. | A policy is a promise; a config screenshot is proof. SaaS tools rarely force you to upload the latter. |
| Significant Changes | Reviewing security only when the GRC tool sends an annual email reminder. | Real risk happens during changes (e.g., new deployments). If your review cycle is static, you miss the actual danger windows. |
| Reporting | Generating a pretty PDF graph showing “98% Compliance” to show the Board. | Percentages are vanity metrics. A real report details what failed and the specific risk exposure, not a high score. |
| Scope | Auditing only the departments that use the SaaS platform. | Shadow IT and physical security often exist outside the GRC tool’s visibility. If you don’t walk the floor, you don’t know. |
| Follow-up | Marking a ticket as “Resolved” without re-testing. | SaaS tickets get closed to meet SLAs. Independent review requires re-opening the case to prove the vulnerability is actually gone. |
About the author
