Annex A 5.35: Independent Review of Information Security

Annex A 5.35 is one of the controls auditors use to test whether your ISMS has a functioning “check-and-improve” loop rather than a static set of policies. A CCO or GRC lead usually feels this requirement in two moments: (1) preparing for an ISO/IEC 27001 certification audit, and (2) trying to defend the program to customers, regulators, or board stakeholders who want assurance that security isn’t self-attested.

The control is straightforward in concept: independent parties review information security at planned intervals and after meaningful changes. The operational challenge is defining “independent” in your org structure, selecting review mechanisms that fit your maturity (internal audit, cross-functional peer review, external assessor), and producing evidence that stands up to scrutiny. Annex A 5.35 does not require a specific reviewer type; it requires independence and effectiveness.

This page translates annex a 5.35: independent review of information security requirement into an execution-ready approach: scope, roles, cadence, reporting, corrective actions, and audit-ready artifacts. It also flags common failure modes that lead to nonconformities: unclear independence, “reviews” that are really status meetings, and findings that never close. Framework context: ISO/IEC 27001 overview (ISO/IEC 27001 overview) and Annex A control listing (ISMS.online Annex A control index).

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.35 implementation expectation (Independent Review of Information Security).” (ISO/IEC 27001 overview; ISMS.online Annex A control index)

What an operator must do: establish a defined method for independent review of information security, perform the review on a planned basis (and when triggers warrant it), document results, and manage remediation through your corrective action process so gaps close and stay closed. Treat this as a control with inputs, steps, outputs, and retained evidence, not as an aspirational principle. (ISO/IEC 27001 overview; ISMS.online Annex A control index)

Plain-English interpretation (what auditors expect)

Auditors look for proof that:

1. You perform reviews that evaluate the ISMS and security controls, not only policy compliance.
2. The reviewer is independent of the activity being reviewed. Independence can be organizational (internal audit), functional (a different team), or external (consultant/assessment firm), but it must be defined and defensible.
3. The review produces an actionable output (report, findings, recommendations, nonconformities) that maps to scope and criteria.
4. Findings drive corrective action with ownership, deadlines, and verification of completion.

A practical way to think about Annex A 5.35: you need an “assurance mechanism” that periodically challenges your security program with fresh eyes, then forces accountability for fixes. (ISO/IEC 27001 overview; ISMS.online Annex A control index)

Who it applies to

Entity types: service organizations pursuing or maintaining ISO/IEC 27001 certification, or aligning their security program to ISO 27001 expectations. (ISO/IEC 27001 overview)

Operational contexts where this becomes mandatory in practice:

• You operate an ISMS in scope for certification (products, systems, locations, and teams included in the ISO scope statement).
• You have internal control owners (security engineering, IT operations, identity, SDLC, third-party risk) whose work needs independent verification.
• You rely on third parties for security-relevant services (cloud hosting, SOC, MSSP, core SaaS). Your reviews should cover the governance of those dependencies when they are in scope.

Where teams commonly misunderstand applicability: limiting the review to IT controls while excluding governance, risk treatment, third-party oversight, and exception handling. If it’s in ISMS scope, it is reviewable.

What you actually need to do (step-by-step)

Step 1: Define “independence” for your organization

Write and approve an Independence Criteria section inside your review procedure. Include:

• Who can review whom (e.g., Internal Audit can review any control; Security GRC can review operational security teams if it is not the control owner; Engineering leadership cannot “review” their own SDLC controls).
• Conflict rules (no reviewer can be the control owner, approver, or primary operator for the control being reviewed).
• Escalation path when independence is hard (small company): use cross-functional peer reviewers, board audit committee oversight, or an external reviewer for high-risk areas.

Output: “Independent Information Security Review Procedure” with a short independence matrix.

Step 2: Set triggers and a repeatable review plan

Document:

• Planned cadence (a recurring schedule appropriate to your risk and change rate; define it as a policy decision and apply it consistently).
• Event-based triggers such as major incidents, significant organizational changes, technology migrations, or scope changes.

Output: annual (or equivalent) Review Program Plan listing scope items, review criteria, and reviewer assignment.

Step 3: Define scope and review criteria that map to your ISMS

For each review engagement, document:

• Scope: business units, systems, processes, third-party dependencies, locations.
• Criteria: ISO 27001/27002-aligned control set, internal policies/standards, contractual requirements, and prior corrective actions.

Keep it tight: a scoped plan is easier to execute and defend than a vague “security review.”

Output: “Review Charter” or “Engagement Plan.”

Step 4: Execute the independent review with evidence-based testing

A defensible review includes:

• Document review: policies, risk assessments, SoA mappings, prior audit reports, exception registers.
• Interviews: control owners and operators.
• Sampling/testing: check whether controls operated as designed (tickets, logs, access reviews, change records). Define sampling rules in the review method so results are repeatable.
• Third-party coverage: verify how you assess and monitor third parties that support in-scope services (e.g., due diligence evidence, contract clauses, ongoing monitoring artifacts).

Output: working papers (can be lightweight) that show what was tested and what evidence was examined.

Step 5: Produce a formal report with graded findings

Your report should include:

• Executive summary for leadership.
• Scope and criteria.
• Findings: nonconformities, observations, opportunities for improvement.
• Risk statement per finding (impact and likelihood qualitatively, if you don’t have a scoring model).
• Recommendations and required corrective actions.

Output: “Independent Information Security Review Report.”

Step 6: Track remediation to closure (this is where audits are won)

Create a corrective action workflow that:

• Assigns an owner and due date per finding.
• Requires a root cause statement for repeat issues.
• Captures closure evidence (screenshots, tickets, configs, approvals).
• Includes verification by someone independent of the implementer, if feasible.

Output: corrective action register entries linked to the report.

Step 7: Management review integration (don’t leave it isolated)

Feed results into ISMS governance:

• Include review outcomes in management review agenda and minutes.
• Update risk treatment plans if findings change risk posture.
• Update the Statement of Applicability rationale if control applicability or implementation changes.

This aligns Annex A 5.35 outcomes with ISMS operating rhythm. (ISO/IEC 27001 overview)

Step 8: Operationalize with a control map and recurring evidence capture

Make the requirement auditable by design:

• Map Annex A 5.35 to a control owner (usually GRC or Internal Audit).
• Define “evidence due” dates and an evidence repository location.
• Standardize report templates and corrective action formats.

This directly matches the recommended approach: map 5.35 to documented control operation and recurring evidence capture. (ISO/IEC 27001 overview; ISMS.online Annex A control index)

Required evidence and artifacts to retain (audit-ready)

Use this checklist to avoid “we did it, but can’t prove it.”

Artifact	What it proves	Minimum fields auditors look for
Independent review procedure	Defined method + independence criteria	roles, independence rules, triggers, reporting, retention
Annual/periodic review plan	Planned intervals, consistent execution	scope list, dates, assigned reviewers
Engagement plan/charter	Defined scope and criteria	scope boundaries, criteria, stakeholders
Review working papers	Evidence-based testing	evidence list, sampling notes, interview notes
Final review report	Formal output and conclusions	findings, severity rationale, recommendations
Corrective action register	Findings tracked to closure	owner, due date, status, closure evidence
Closure validation evidence	Fix verified, not self-attested	reviewer sign-off, retest notes
Management review minutes	Governance linkage	discussion, decisions, follow-ups

Common exam/audit questions and hangups

• “Who performed the independent review, and how are they independent?” Expect to show org charts, RACI, or a signed independence statement.
• “Show me the review plan and the last completed review report.” Auditors want planned vs. actual and evidence you didn’t skip hard areas.
• “Pick one finding and show end-to-end remediation.” This tests whether corrective action works.
• “How did you decide the scope and criteria?” Weak answers sound like “we looked at some controls.” Strong answers cite the ISMS scope and risk drivers.
• “What changed after the review?” Be ready to show procedure updates, risk treatment updates, or control enhancements.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Calling a security steering committee a “review.”
   Fix: require evidence-based testing and a written report with findings.

2. Mistake: Reviewer independence is implied, not defined.
   Fix: publish explicit independence criteria and maintain conflict-of-interest attestations for reviewers.

3. Mistake: Reviews cover policies only, not control operation.
   Fix: include testing steps (samples of access reviews, change approvals, incident records).

4. Mistake: Findings live in slides and never enter corrective action.
   Fix: enforce a corrective action register with closure evidence and independent validation.

5. Mistake: Third-party dependencies are ignored.
   Fix: add a section in the review program for third-party oversight testing where third parties support in-scope services.

Enforcement context and risk implications

ISO 27001 is a certifiable standard, so “enforcement” typically shows up as audit nonconformities and certification risk rather than regulator-issued penalties. The operational risk is broader:

• Without independent review, you increase the odds of undetected control drift, especially in identity, change management, logging, and third-party oversight.
• Customers can treat weak assurance as a trust issue during security reviews and procurement cycles.
• Internally, the absence of independent findings makes it harder for a CCO/CCO-equivalent to secure resourcing because there is no documented gap narrative.

Practical 30/60/90-day execution plan

First 30 days (stand up the mechanism)

• Appoint the control owner and approve independence criteria.
• Publish the independent review procedure and report template.
• Build the review universe: list in-scope processes, systems, and key third parties supporting in-scope services.
• Schedule the first review and secure reviewer capacity (internal audit, cross-functional, or external).

By 60 days (complete a first review cycle)

• Execute at least one scoped independent review with evidence-based testing.
• Issue the report with findings and assign corrective actions.
• Start corrective action tracking with owners and due dates.
• Decide how results feed management review and risk treatment updates.

By 90 days (prove it runs and closes the loop)

• Close or materially progress the highest-risk corrective actions with closure evidence.
• Perform validation (retest) for at least one remediated finding.
• Update policies/standards where findings show systemic issues.
• Lock in the recurring review plan and evidence capture calendar.

Where Daydream fits naturally: Daydream helps you turn Annex A 5.35 into a scheduled, repeatable control by mapping the requirement to owners, workflows, and recurring evidence requests so reviews and corrective actions don’t disappear into email threads.

Frequently Asked Questions

Do we need an external auditor to satisfy Annex A 5.35?

No. The requirement is independence, not “external.” You can meet it with internal audit, a separate internal function, or an external reviewer, as long as independence is defined and defensible.

We’re a small company. How can we prove independence?

Use cross-functional reviewers who are not the control owner or operator, document conflict rules, and escalate high-risk areas to an external reviewer when separation of duties is limited. Keep written independence attestations for each review.

Can our security GRC team perform the independent review?

Sometimes. If GRC designs or operates the controls being reviewed, independence is weak. If GRC is separate from control operation and can show objective testing and conflict management, it can be acceptable; document the rationale.

What’s the minimum evidence an ISO auditor will expect?

A procedure, a review plan, at least one completed report within the audit window, and a corrective action trail with closure evidence. Missing any one of these usually leads to audit friction.

Does this review replace internal audits of ISO 27001 clauses?

It can be part of your internal audit program, but it should explicitly cover information security controls and their operation. Keep the mapping clear so you can show how this review ties into ISMS governance.

How do we keep reviews from becoming check-the-box?

Tie the scope to risk, test control operation with real evidence, and require remediation verification. If findings never close, the review function loses credibility fast.