ISO 27001 Annex A 5.35: independent review of information security

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 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:

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 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 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