---
title: "ISO 27001 Annex A 5.35: independent review of information security"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-35-independent-review-of-information-security
published: 2023-04-07
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.5.35 Independent review of information security"
journeyStage: implementation
---

# ISO 27001 Annex A 5.35: independent review of information security

## Key takeaways

Annex A 5.35 asks for a planned and event-driven review of your whole security approach by someone outside the line of authority, followed by real corrective action. A small firm can meet it with one risk-based programme that also serves Clause 9.2. The evidence trail from finding to verified closure is what certification auditors trace.

- **What it requires** — Review the whole security approach, covering policies, controls, people and technology, on a planned cycle and after significant change, using a reviewer outside the area's line of authority.
- **Who can review** — An external specialist, a trained peer from another department or a board-facing internal audit function. A vCISO or MSP cannot review what they built or run.
- **One programme** — One risk-based programme serves this control and Clause 9.2, stating scope, frequency, criteria and method, with event triggers written in alongside the planned annual cycle.
- **Audit evidence** — Programme, reports, competence and independence records, time-boxed access logs, management review minutes and a corrective-action log, linked so one finding traces to verified closure.

The due-diligence questionnaire from your biggest prospect asks who independently reviewed your information security last year. The honest answer is the person who built it, and the deal is waiting on the reply.

This guide explains ISO 27001 Annex A 5.35 for security managers, heads of IT and compliance officers at 25–250 person firms heading for Stage 2 or customer diligence. It covers who can review and how to fold the work into Clause 9.2. It then covers which events trigger an extra review, how to control reviewer access, and what auditors trace from the report to the fix.

## What does 5.35 independent review of information security require?

Annex A 5.35 asks for your whole approach to security, from policies and controls to the people and technology behind them, to be reviewed on a planned cycle and after significant change. The reviewer must sit outside the line of authority for the area. Findings go to management, and gaps lead to fixes, not filing.

The control separates design from evaluation. The scope is the whole approach, so a technical scan or a read of the policy set is not enough on its own.

Two kinds of review satisfy the control:

- **A planned cycle.** Scope, frequency and method are fixed in advance and tied to risk, usually annually and timed to the certification calendar.
- **An event-driven review.** A significant change, such as a serious incident, prompts an extra look outside the calendar.

Results go to the managers who commissioned the review, and higher where the findings warrant it. The control is corrective as well as preventive: a finding that sits unactioned fails its second half, however good the review was.

The control overlaps heavily with the internal audit machinery of Clause 9.2 and feeds the management review. It differs from Annex A 5.36, which covers the narrower, ongoing checking of compliance with your own rules.

## Why does ISO 27001 Annex A 5.35 catch out small security teams?

In a 40-person company the obvious reviewer is the person who built the ISMS, which is precisely what the control forbids. Designers are the least likely to spot their own flaws. Certification bodies also expect a completed internal audit cycle before Stage 2, so independence gates the certificate itself.

Self-assessment has a blind spot. A founder who feels secure is usually measuring effort rather than effectiveness. An independent reviewer corrects that cheaply, where an attacker or a certification auditor would correct it expensively.

A review the ISMS owner performs on their own build is not independent. It is a status report.

The commercial stakes sit on both sides of the table. A review that fails on independence delays the certificate. Regulated buyers, and regimes such as DORA and NIS2, increasingly ask for evidence of independent testing too. The control is a diligence question as much as an audit one.

The trap is rarely carelessness. In a lean team the ISMS builder is also the only person who understands the scope, so the shortcut feels reasonable. The fix is structural: choose the reviewer when you write the programme, not when the report falls due.

## Who can perform the independent information security review?

Anyone competent who sits outside the line of authority for the area. That can be an external specialist, an internal audit function reporting to the board, or a trained peer from another department. Operational owners such as the CISO or IT manager cannot review their own areas, and no external firm is mandatory.

An external specialist is the clean answer and often the cheapest at small scale, because you buy days rather than a standing function. A trained internal person from outside the security reporting line also satisfies the control. A finance or operations lead audits security, and the security lead returns the favour elsewhere.

Competence matters as much as distance. The [ISO/IEC 27007:2020 standard on ISMS auditing guidelines](https://www.iso.org/standard/77802.html) gives guidance on running an ISMS audit programme and on auditor competence. It is a sensible yardstick for what to ask of a reviewer. Collect CVs or certificates, and file a conflict declaration for internal reviewers or the engagement terms and an NDA for external ones.

Fractional CISOs and managed service providers need a straight answer. A vCISO cannot review the parts of the ISMS they built or operate. An MSP cannot review the infrastructure it runs. Both are the conflict the control exists to prevent, so pair them with a separate independent reviewer.

Distance without depth fails too. A reviewer with no technical skill reads the policies, ticks the boxes and returns a document check dressed up as assurance. Ask every candidate how they would test a control, not just how they would read about it.

The options compare as follows:

| Reviewer option | Independence | Competence evidence | Watch-out |
| --- | --- | --- | --- |
| External specialist | Clean by default | CVs, certificates, engagement letter | Needs time-boxed read-only access and an NDA |
| Internal peer from another department | Sound if outside the security reporting line | Training record, conflict declaration | Needs enough technical depth to test controls |
| Internal audit reporting to the board | Strong where the function is truly independent | Audit charter, auditor competence records | Uncommon in a lean firm |
| vCISO or MSP that built or runs the area | Not independent for that area | Not applicable | Pair with a separate reviewer |

## How do you combine Annex A 5.35 and Clause 9.2 into one audit programme?

Run one risk-based programme that satisfies both Annex A 5.35 and Clause 9.2, stating scope, frequency, criteria and method. A separate independent review programme layered on top of internal audit is duplication. One schedule, one set of findings and one corrective-action log serve both requirements.

The programme is a risk-based schedule. It states what is in scope, how often each area is reviewed, the criteria used to judge it and the method, such as interview, sampling or technical testing. Higher-risk areas get more frequent or deeper reviews, and stable low-risk ones get less.

Independence is what the combined programme must prove for every line. Each review needs a reviewer outside the line of authority for the area. The schedule should name that reviewer and record the conflict check beside the line.

A single programme gives you:

- **One schedule**, anchored on an annual cycle timed to the certification calendar.
- **One set of findings**, graded the same way whether the review served the control or the clause.
- **One corrective-action log**, so nothing is fixed twice or forgotten in a second tracker.

Design one report format up front, so nobody has to translate between two audit streams before the results reach the management review.

## Which events should trigger an unscheduled review beyond the annual calendar?

Review whenever something significant changes: new laws or regulations, a serious incident, a new business line or product, or a major change to controls or infrastructure. Write these triggers into the programme itself. Auditors now check that triggers were considered, not just that the annual slot ran.

The annual cycle is the floor of the control, not the whole of it. Write each trigger into the programme with an owner and a decision point:

- **Regulatory change.** A new or amended law or regulation that touches your services or your data.
- **A significant incident.** Decide at incident closure whether the response warrants an independent look.
- **A new business line or product.** Review the controls before the first customer data flows through them.
- **A major control or infrastructure change.** A platform migration, or a change to core controls.

A trigger does not always demand a full review. Record the decision either way. A short note that the change was assessed, and which scope was chosen or why none was needed, shows the trigger was considered.

Auditors probe this directly. A typical question names a platform change from earlier in the year and asks whether anyone considered a review. If the answer sits in a ticket or a decision log, the question closes quickly.

## How should reviewers get access to your systems?

Give reviewers temporary, read-only access protected by MFA, and revoke it when the engagement ends. Standing admin accounts for auditors are themselves a finding. Keep the access log with the review report so you can show exactly what the reviewer could see and when that access was removed.

Reviewers see sensitive configuration, so their access is a risk in its own right. Provision a named account per reviewer, scoped to the systems in the review scope, with MFA enforced from the first login. Set the expiry date when you create the account, not when you remember to remove it.

The access log should record four things:

- **Who** held the account and who approved it.
- **What** the account could see.
- **When** access started and ended.
- **How** revocation was confirmed.

The common failure is broad or permanent admin access that outlives the engagement. Read-only rights are enough for a reviewer sampling configuration and evidence, and a reviewer who needs more should ask, with the request recorded.

## How do findings become corrective action that survives re-verification?

Grade each finding as major, minor or observation, and give it an owner and a deadline. Run root-cause analysis on the significant ones and re-verify the fix before closing. Then land the results in the management review. The follow-through is the half of the control firms most often fail.

Grading gives findings a priority the business can act on: majors first, minors next, observations as improvement opportunities. Each significant finding then follows the same path:

1. **Assign** one accountable owner and a deadline that reflects the grade.
2. **Find the root cause**, so the fix removes the cause instead of patching a symptom.
3. **Fix and evidence** the correction, attaching proof to the ticket.
4. **Re-verify** the fix, ideally by someone independent of the person who made it, before closure.
5. **Report** closed and open items to the management review.

Closing a finding on the owner's say-so is how the same issues reappear review after review. If repeats show up, the root-cause step or the re-verification gate is being skipped.

The management review is the hand-off that makes leadership accountable. Results that land there formally also drive updates to the risk register and the Statement of Applicability where findings warrant them. Results that never reach leadership let management sign off a posture nobody independent has described to them.

## What evidence and questions will a certification auditor bring to Annex A 5.35?

Auditors expect the review programme, reports, reviewer competence and independence records, access logs, management review minutes and a corrective-action log. They then trace one report end to end and probe who the reviewer reports to. Missing independence or follow-through grades minor, aggregating to major; no review at all grades major.

Assemble the evidence set so each item points at the next:

- **The programme and schedule**, with scope, frequency, criteria, method and named triggers.
- **Review reports**, showing scope, method, findings and the evidence behind each.
- **Competence and independence records**: CVs or certificates plus conflict declarations, or the engagement letter and NDA.
- **Access records** showing temporary read-only credentials and their revocation.
- **Management review minutes** showing the results were formally received.
- **The corrective-action log**, with owners, root-cause notes, deadlines and re-verification.

The connective tissue matters more than any single document. An auditor takes the latest report and follows one finding to its corrective action, to verified closure, to its appearance in the minutes.

A report whose findings appear nowhere in the action log is theatre, however elegant.

Expect questions such as these in the room:

- Who performed your last independent review, and how do you show they were independent and competent?
- How did you decide scope and frequency, and which events would trigger an unscheduled review?
- Who owned this finding, what was the root cause, and how was the fix verified?
- What access did the reviewer have, and when was it removed?

Grading norms come from certification bodies, not from the standard. A single gap, such as a missing conflict declaration, usually lands as a minor. Several gaps across independence, tracking and reporting suggest the loop exists on paper only, and that pattern is what tips the grade to major.

A graded, closed-out review also serves regulators and buyers. The [ICO guidance on the UK GDPR accountability principle](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accountability-principle/) says you must have appropriate measures and records in place to demonstrate compliance. A closed-out review is one such record. If you run essential services, the [NCSC Cyber Assessment Framework guidance](https://www.ncsc.gov.uk/collection/cyber-assessment-framework) is a tool to assess and improve cyber security and resilience, and your findings can be mapped against it.

## How do you automate independent review triggers, evidence and access?

Run the programme as a scheduled workflow. Review cycles and event triggers open scoped tasks, evidence is collected all year, findings become tickets with a re-verification gate, and reviewer access expires on its own. The reviewer then samples a live record instead of spending two weeks digging.

Four pieces of engineering do most of the work:

- **Scheduled workflow.** Review cycles and event triggers, such as incident closure, major change tickets and regulatory watchlist hits, open scoped review tasks automatically. The "when significant change occurs" half of the control stops depending on memory.
- **Continuous evidence.** Control evidence gathered automatically all year makes each review cheaper and widens what it can cover.
- **Findings as tracked work.** Each finding is a ticket with an owner, root cause, deadline and re-verification gate, so the corrective-action trail assembles itself.
- **Reviewer access as code.** Time-boxed read-only credentials are provisioned and auto-revoked, with the access log filed alongside the report.

Automation does not replace the reviewer. It removes the clerical work, so the independent party spends the days on judgement: testing whether controls work, challenging scope and questioning root causes.

GRCMANA's internal audit service delivers exactly this independent, competent review, with graded findings and a tracked fix loop. Our readiness assessment is an independent, pre-certification review of the whole approach, and for many clients it is the first execution of this control. A fractional CISO can build the programme, triggers and corrective-action loop from the management side while the reviews stay with an independent party.

## Frequently asked questions

### How many reviewer-days does an Annex A 5.35 independent review take each year?

Our guidance for a 50-person regulated firm is to budget two to four external reviewer-days a year. A first review of a messy scope takes longer than a repeat of a well-scoped one. The larger cost is internal, because the real work is fixing what the review finds.

### When should the first A.5.35 independent review happen before certification?

Schedule the first full review once the ISMS has operated for a few months and before Stage 1. The certification body wants the cycle demonstrably run, and a few months of records give the reviewer something real to sample. Book the reviewer early, because their diary is the usual constraint.

### How does Annex A 5.35 differ from A.5.36 compliance checking?

A.5.36 covers the routine checking that people and systems follow your own policies, rules and standards. Managers can run those checks in their own areas, which A.5.35 rules out for its review. Feed the results to the independent reviewer as input, not as a substitute for their judgement on whether the whole approach works.

### Will DORA or NIS2 customers ask for Annex A 5.35 independent review evidence?

Often, though the question rarely names the control. Prepare a short pack: the programme extract, a summary of the latest report, the reviewer's independence statement and the corrective-action log. Read the customer's own questionnaire wording first, because it defines what they want to see, not the control number.