What A.5.35 independent review of information security asks for
A.5.35 Independent review of information security requires the organization's approach to information security, and its implementation across people, processes and technology, to be reviewed by someone outside the area under review. The review must happen at planned intervals and whenever significant changes occur. For a compliance lead or CISO preparing for an audit, this means the organization needs a documented schedule of independent reviews, a defined trigger list for ad hoc reviews, and records showing who reviewed what, when, and what they concluded. The control does not ask for a particular reviewer type or frequency, so the organization must set and justify both in its own terms.
The risk it addresses is self-assessment blind spots. Teams that operate a control tend to judge it by their own intentions, not by what actually happens. Over time the written policy and daily practice drift apart: access grants are not removed, a supplier changes its hosting without notice, or a new system goes live outside the documented scope. An outside reviewer tests the gap between the documented ISMS and reality, and that gap is what most assessors probe first. The control also sits alongside clause 9.2 Internal audit and clause 9.3 Management review, so reviewers should be able to show how their findings feed those activities. Note that A.5.35 carries forward control A.18.2.1 from the 2013 edition, so existing evidence from earlier certification cycles can often be reused if it is still current.
Independence is the hard part for small teams. A single security engineer cannot review their own work, and a part-time reviewer who reports to the same leadership as the operators may still fail the test of independence. Small organizations therefore need to decide early whether the reviewer will be an internal person outside the operating line, a non-executive or group function, or an external party, and record that choice. Scheduling is the second difficulty, because reviews slip when nobody owns them. Write terms of reference for each review that state its scope, criteria, method, reviewer, and reporting line, and confirm with your certification body or auditor which evidence they expect before the first review runs.
Which reviewers, areas and changes fall in scope for A.5.35
A.5.35 is only as strong as the scope behind it. The decisions below determine which parts of the ISMS get reviewed, who may perform the review, and which events trigger one outside the planned cycle. Settle them in writing before the first review starts so an assessor can see why the scope is what it is.
People, processes and technology
A.5.35 covers how the organization manages information security and implements it across people, processes and technology. A review limited to tools misses the question of whether staff follow the policy, and a review limited to policy misses whether the systems enforce it. Record which of the three areas each review covers, and where one area is excluded, state the reason and who accepted it.
Independence from the reviewed area
The reviewer must sit outside the area being reviewed. A security team cannot independently review its own controls, and neither can the engineering lead who built the system. Reviewers may be internal staff from a separate line, such as internal audit, or an external firm. Ask who reports to whom, and whether the reviewer had any role in designing or operating the control they assess.
Events that count as significant changes
Significant changes trigger a review outside the planned cycle. Typical triggers include mergers and acquisitions, adoption of a new cloud platform, a major security incident, a new regulatory obligation, and a large shift in the operating model. Write the trigger list into the review procedure, and record for each change whether it did or did not trigger a review, with the reason.
Cloud and hosting changes
Moving workloads to a new cloud account, region or provider changes where controls run and who operates them. Reviewers should confirm that the responsibility split with the provider is still documented, and that the review covers the new environment rather than only the one it replaced. Confirm with your cloud team which configuration baselines and access paths changed.
Third-party reviewers and their evidence
An external firm can serve as the independent reviewer, but the organization still owns the review scope and the actions that follow. Ask any third party to confirm its competence in ISMS audits and its independence from the work it reviews. Keep their terms of engagement, scope letter and report with the ISMS records. Note that ISO/IEC 27007 covers guidance on auditor competence and audit programmes, and it is useful reference material for both internal and external reviewers.
How an assessor tests independent review
This table sets out the steps an assessor takes to test A.5.35, from confirming the review schedule to checking whether reviewers sit outside the area they review. Read each row as a test step with the evidence it produces and the failure pattern that most often appears. The main takeaway is that an assessor looks for proof that reviews happened, were independent, and led to corrective action.
| Test step | What the assessor checks | Evidence requested or common finding |
|---|---|---|
| Review schedule and triggers | Whether the organization set planned intervals and defined events that trigger an extra review, such as major system changes, mergers or new service lines | Approved review calendar and a trigger list; common finding: no defined trigger, so reviews only happen when someone remembers |
| Reviewer independence | Whether reviewers sit outside the function that runs the controls and have no role in operating them | Reviewer names, reporting lines and conflict declarations; common finding: the security team reviews its own program |
| Reviewer competence | Whether reviewers have the knowledge to judge an ISMS, including people, process and technology | Role descriptions, training records or credentials; the auditor applies ISO/IEC 27007:2020 guidance on auditor competence |
| Coverage of people, processes and technology | Whether the review examined the approach, its implementation and all three dimensions, not only tools | Review scope statement and workpapers showing interviews, process walkthroughs and configuration checks |
| Sampling of past reviews | Whether the assessor can trace each review to its findings and to corrective actions | Review reports, action logs and closure records; common finding: findings recorded but never tracked to closure |
| Follow-through on findings | Whether management responded to findings and the next review confirmed the fix | Management responses, dated action plans and re-test results |
| Link to other controls | Whether the review feeds the internal audit, management review and compliance checks that sit beside it | Cross-references to clause 9.2, clause 9.3 and A.5.36 outputs; common finding: separate reviews with no shared action list |
| Triggered reviews after change | Whether significant changes produced a review, not just routine cycles | Change records linked to review dates; common finding: no review after a cloud migration or acquisition |
Setting up an independent review that stands up to audit
The sequence turns A.5.35 from a sentence in the control set into a repeatable review cycle. Each step produces a record an auditor can sample, from the scope and triggers through to findings that feed management review.
Define the review scope and triggers
Management sets out what the independent review covers: the information security approach, its implementation across people, processes and technology, and the business units, sites and systems in scope. Triggers are written down as well, covering the planned interval the organization chooses and significant changes such as a merger, a new business line, a major platform migration or a material change in suppliers. The step is done when the scope and triggers are approved by top management and recorded in the ISMS documentation, so an auditor can see what should have been reviewed and when.
Select reviewers and document their independence
Choose reviewers who sit outside the area under review. This may be internal audit staff who do not report into the function they examine, or an external firm or assessor. Record each reviewer's competence and the basis of their independence, such as reporting lines, absence of day-to-day responsibility for the controls and absence of conflicts of interest. ISO/IEC 27007 gives guidance on auditor competence and on managing audit programmes, and it is a useful reference when setting selection criteria. The step is done when a signed independence and competence record exists for every reviewer. Confirm with your own legal and procurement teams how external reviewers are contracted.
Agree terms of reference with the reviewers
Write terms of reference that state the objective, scope, criteria the review measures against (the ISMS policies, the Statement of Applicability, applicable legal and contractual obligations), methods such as interviews, document review and technical testing, access the reviewers need, reporting lines and the confidentiality rules that apply. Agree how the reviewers will raise urgent concerns before the final report. The step is done when management and the reviewers have both signed the terms of reference and the access they need has been granted in writing. Reviewers working in a self-hosted environment will need supervised access to logs, configuration and evidence stores, so confirm those arrangements early.
Run the review against the agreed criteria
Reviewers examine whether the approach to information security is still suitable, adequate and effective, and whether it is implemented as written. They interview process owners, sample records, inspect configurations and compare what happens in practice with what the policies say. Where the review is technical, reviewers may test controls directly, within the limits agreed in the terms of reference. The step is done when the reviewers have completed the planned work and have working papers that show what they examined, who they spoke to and what they sampled, so the conclusions can be traced back to evidence.
Record findings and assign corrective actions
Reviewers issue a written report with each finding stated clearly, the evidence behind it and the criterion it was measured against. Management responds to every finding with an owner, an agreed corrective action and a target date that the organization sets for itself. Findings about the approach itself, such as a policy that no longer matches the business, are logged separately from implementation gaps. The step is done when the report is accepted by management and every finding has a named owner and an action recorded in the corrective action log, so that follow-up can be checked at the next review.
Verify corrective actions are closed
The information security function or internal audit checks that each corrective action has been implemented and that it addressed the root cause, not only the symptom. Closure requires evidence, such as an updated procedure, a configuration change record or a repeat sample showing the control now works. Actions that slip are escalated according to the governance rules the organization has set. The step is done when each action is marked closed with the evidence attached, or formally accepted as a risk by the appropriate owner, and the log shows the closure date.
Feed results into management review
Present the independent review report, the status of corrective actions and any changes that have affected the ISMS to top management as part of management review under clause 9.3. Management decides whether the approach needs to change, whether resources need to be adjusted and whether the scope or triggers for the next review should be updated. The step is done when the management review minutes record the decisions taken, the changes approved and the next review date, so the results of independent review are linked to ISMS improvement.
Where reviewer independence draws the line
Independence under A.5.35 is about the reviewer's relationship to the work, not their job title. A reviewer does not own or operate the thing being reviewed, and does not report to the people accountable for it. The practical test is simple: if the person who designed, configured or ran a control is also the one judging whether it works, the review is not independent. An implementation partner that built the access reviews, logging pipeline or policy set should therefore not be the party that concludes the approach to information security is effective. That partner can prepare the evidence, explain the design and fix findings, but the independent review has to come from someone outside that delivery chain.
Three other activities are often confused with A.5.35, and the differences matter when you plan the year. Internal audit under clause 9.2 is a planned audit of the ISMS by people who may be employed by the organization, but who must be objective and must not audit their own work. Management review under clause 9.3 is top management assessing the ISMS's suitability and performance, which is a governance activity rather than an external check. A.5.35 asks for independent review at planned intervals or after significant changes, and it may be satisfied by an internal reviewer outside the area under review, an external assessor, or both. Certification audits are a different category again: an accredited certification body audits against the standard and issues the certificate, and that body must be independent of the organization it certifies.
DeployOpen prepares systems, controls and evidence for these reviews, including the records a reviewer will sample. It does not perform the independent review for a client, and it does not issue audit reports, attestations or certificates. Before work starts, confirm in writing who will act as the reviewer, what their independence is based on, how often reviews occur, and what triggers an extra review after a significant change such as a cloud migration or a new operating model. Ask your certification body or auditor how they expect to see A.5.35 evidenced, and keep the review terms of reference, scope, reviewer identity and resulting actions in a format they can sample.
Evidence that satisfies A.5.35 and how to keep it current
An assessor testing A.5.35 wants to see that independent reviews were planned, performed by people outside the area reviewed, and led to tracked action. The six artifacts below connect those steps, and each one is only useful if it is refreshed between audits rather than rebuilt the week before one.
Review plan and triggers
A dated plan listing which parts of the ISMS are reviewed, by whom, and when, covering people, processes and technology. Alongside the planned intervals, write down the events that force an unscheduled review, such as a major acquisition, a new cloud platform, a material incident or a restructured security team. Check that the plan names the interval chosen by the organization and that each trigger has a documented owner. An assessor will compare the plan against the review records you actually hold.
Reviewer independence declarations
Signed statements from each reviewer confirming they do not run, operate or report on the area they assess. For internal reviewers, this usually means someone outside the team under review. For external reviewers, it covers any prior work for the organization, such as implementation or remediation. Refresh these declarations for each review, since staffing and engagements change. Missing or stale declarations are a common reason an assessor questions whether a review was truly independent.
Terms of reference
A short document that states the objective, scope, criteria, sampling approach and expected output of each review. It should say which parts of A.5.35 the review addresses and which policies, controls or standards it measures against. Keep one per review and version it, so that the scope shown to the assessor matches the scope the reviewer actually tested. Terms of reference also show whether the review covered technology as well as process and people.
Review reports
Written reports that state what was examined, the evidence reviewed, the conclusions reached and the reviewer's name and role. A useful report separates observations from findings and says where the approach to information security is working as designed. Ask whether reports go to the people who can act on them, such as the ISMS owner and top management. Reports that restate the scope without evidence give an assessor little to test.
Findings log with corrective actions
A register that records each finding from each review, its severity, the owner, the corrective action, the due date and the evidence that the action closed. This is where A.5.35 connects to the ISMS improvement requirements. Review the log at each management review and mark overdue items explicitly. An assessor often picks a finding and follows it from report to closure, so every entry needs a traceable end point.
Records feeding management review
Minutes, decision logs and action lists from the management review meetings that consider independent review results alongside internal audit and other performance data. These records show that leadership saw the findings, decided what to do and tracked the outcome. Keep the inputs and outputs of each meeting together so the link between a review and a management decision is visible. Confirm with your certification body how it expects these records to be sampled in surveillance audits.
What an independent review costs in money and effort
This table breaks down the cost components of an independent review of information security, showing who is paid for each one, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where open-source tooling changes the spend. No fees are given because none were supplied; confirm figures with each reviewer and vendor against your own scope.
| Cost component | Who is paid or who bears the effort | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Internal reviewer time | Your staff or an internal audit function, paid through existing salaries | Recurring, each review cycle | Scope and number of policy areas. Ask the reviewer to confirm independence from the area under review and the hours planned. |
| External reviewer fees | Independent assessor or consultant, billed on a written scope | Recurring at planned intervals, plus one-time for significant changes | Size of the ISMS, number of sites and systems sampled. Ask for a fixed scope, deliverables and named exclusions. |
| Auditor sampling time | Certification body or external auditor, billed on its audit plan | Recurring during each surveillance or recertification audit | Quality of evidence on hand. Ready, indexed review records usually shorten sampling. Confirm how the auditor plans days. |
| Tooling for tracking findings | Licensed GRC or ticketing vendor, or self-hosted open-source platform | Licence recurring for commercial tools; infrastructure and upkeep recurring for self-hosted | Number of users and findings history. Ask whether the license is per user, per module or per instance, and whether data stays in your environment. |
| Evidence upkeep | Control owners and the team that stores records | Recurring, continuous | Number of review records, retention rules and how often controls change. Automated collection reduces manual effort. |
| Remediation of review findings | Control owners and implementation partners where engaged | One-time per finding, with follow-up checks | Severity and number of findings. Ask a partner to separate remediation work from the review itself in the quote. |
| Reviewer independence and competence | Internal audit staff training or external reviewer qualifications | Recurring, as competence is maintained | Reviewer background and reporting line. ISO/IEC 27007:2020 gives auditor competence guidance to check against. |
Who runs the review, who prepares evidence, who audits it
The organization owns the control. Its leadership decides how often independent reviews happen, what triggers an extra review after a significant change, and who is accountable for the outcome. Someone outside the area under review must perform or direct the review, so the organization usually selects reviewers from internal audit, a separate risk function, or an external assessor. Your team then acts on what the review finds, because an assessor will check whether findings were tracked to closure rather than just recorded.
- Set the review calendar: Document the planned interval and the events that trigger an unplanned review, such as a major platform migration or an acquisition.
- Select independent reviewers: Confirm in writing that reviewers do not design or run the controls they examine, and record their competence.
- Approve terms of reference: Agree the scope, people, processes and technology covered before fieldwork starts.
- Own the findings: Assign owners, due dates and status to each finding, and report them to management.
- Confirm closure: Keep the decision record for each finding that shows whether it was fixed, accepted or deferred.
Before relying on the program, check that your own sign-off trail shows who selected each reviewer and what management did with the last set of findings.
An implementation partner can prepare the systems and records that an independent review reads. This includes setting up the ticketing, document and evidence stores, building the review checklists against the organization's own policies, and running a mock review before the real one. The partner does not perform the independent review and does not judge the organization's own program. Where the partner also helped design the ISMS, a separate reviewer must still assess it, and the organization should say so in the review scope.
- Prepare review records: Structure the evidence library so that management reviews, internal audit reports and corrective action logs can be found quickly.
- Track tooling: Configure GRC or open-source tooling, such as CISO Assistant, to hold findings, owners and due dates, and to keep an audit trail of changes.
- Run mock reviews: Test a sample of controls and findings against the evidence, then report gaps to your team for correction.
- Support scoping: Help document which systems, sites and suppliers fall within the review boundary, and flag where the boundary has drifted.
- Document handover: Deliver runbooks so your staff can repeat the review without the partner.
Ask for a written statement of which tasks the partner performs and which remain with your staff or the reviewer, and confirm that the partner has no role in the reviews it prepares for.
An independent auditor or accredited certification body does not run the organization's internal review. It assesses whether the organization's review arrangements are designed and operating as the standard requires, as part of an ISMS audit. Accredited certification bodies work to ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024, and they issue the certificate, not the organization or any consultant. ISO/IEC 27007:2020 gives guidance on auditing the ISMS, including auditor competence and audit programme management.
- Sample the review evidence: Expect requests for the review plan, reviewer independence records, reports and closed findings.
- Test independence: Check that reviewers sit outside the area they examined and had the competence to judge it.
- Check follow-through: Compare findings against corrective actions and confirm that the ISMS improvement loop works.
- Report nonconformities: Record any gaps in the review arrangements in the audit report.
- Keep separation: The certification body must remain independent of the consultant or partner that helped prepare the organization.
Before engaging a certification body, confirm its accreditation status in the IAF CertSearch database and ask how it handles conflicts of interest with your implementation partner.
Where independent review usually fails and how to close it
A.5.35 is easy to write down and hard to evidence. The gaps below recur across organizations preparing for certification, and they share one root cause: the review is not visibly independent, planned, competent or connected to decisions. Each card names a gap, why an assessor notices it, and the closing action to take before the audit.
Reviews run by the control owner
When the team that operates the ISMS also reviews it, the review checks its own work and the assessor will treat it as self-assessment. Independence means the reviewer does not own the area under review and reports outside that line. Check who signed each review record, and whether the reviewer had any role in designing or running the controls they examined. Close the gap by assigning reviews to internal audit, a separate function or an external reviewer, and writing that assignment into the review plan.
No defined triggers for significant change
A.5.35 requires review at planned intervals and also when significant changes occur, but many organizations never define what counts as significant. Examples include a new cloud region, an acquisition, a change of identity provider or a major AI system going live. Without a written trigger list, an assessor cannot tell whether a missed review was a failure. Close the gap by documenting trigger criteria in the review procedure, linking them to the change management process, and keeping a log that shows each trigger and the review it started.
Findings without closure records
A review that lists weaknesses but never shows what happened to them gives an assessor little to test. Each finding needs an owner, a due date, the action taken and evidence that the action worked. Open findings that roll forward without a decision are a common nonconformity. Close the gap with a single findings register that holds every review output, with a status field that cannot move to closed without a linked evidence item, and a monthly check by the person who commissioned the review.
No competence evidence for reviewers
Assessors ask whether the people reviewing the ISMS can do it. A reviewer who has never tested access controls or read a cloud configuration will produce reviews that look complete but test little. Keep records of each reviewer's qualifications, training and relevant experience, and match them to the scope they cover. Where internal staff lack the skills, the organization can use an external reviewer, and the contract and their credentials then become part of the evidence. Confirm the expected competence criteria with your certification body before the audit.
Reviews not feeding management review
An independent review that stays inside the audit folder does not inform decisions. Clause 9.3 management review should take review results as an input, and the minutes should show management discussing them, approving resourcing or accepting residual risk. When the minutes never mention review outcomes, the assessor may conclude the review had no effect on the ISMS. Close the gap by adding review results as a fixed agenda item, recording the decisions taken, and tracing each decision back to the review finding that prompted it.
Questions buyers ask about A.5.35 independent review
Can our internal staff perform the independent review of information security?
Internal staff can run the review only if they sit outside the area being reviewed. A reviewer who runs the security program, or who reports to the person accountable for it, does not meet the independence the control asks for. Many organizations therefore assign the review to internal audit, which reports to the board or audit committee, or to a second-line risk function that does not own the controls. Where no such function exists, a reviewer from outside the organization is the usual answer. Ask the auditor how they will test independence in your setup, because the assessment looks at reporting lines and objectivity, not job titles alone.
How much effort does an independent review of information security take?
Effort depends on the size of the ISMS, the number of sites and systems in scope, how many significant changes occurred since the last review, and how much evidence already exists. An internal reviewer spends time on planning, sampling, interviews and reporting, while an external reviewer also needs onboarding time to understand your environment. Neither the standard nor the supplied facts give a number of days, so ask any provider for an effort estimate built from a written scope. Also ask what the review produces: a report, a list of findings, and records of how management responded.
How often must an independent review of information security happen?
The control asks for reviews at planned intervals and whenever significant changes occur. The organization sets the interval and must justify it, and it should be documented in the ISMS. Significant changes can include a new business line, a merger, a move to a new cloud platform, or a major change to the security architecture. Certification bodies also expect the review to fit into the broader audit program, and under ISO/IEC 17021-1 a three-year certification cycle includes at least one audit each calendar year. Your independent review plan should be documented in the same calendar so that reviewers and certification auditors can trace it.
Do we need an external independent review to get ISO 27001 certified?
A.5.35 does not say that the reviewer must come from outside the organization, so an internal reviewer who is genuinely independent of the area reviewed can satisfy the control. The certification body will still test whether the review happened, whether it was independent, and whether findings were acted on. Many organizations choose an external reviewer when internal independence is hard to prove, when they need a view from a party with no stake in the outcome, or when customers ask for it. An external review does not replace the certification audit, and the certification body, not the reviewer, decides conformity.
What should an implementation partner provide for an independent review?
A partner that helps you prepare for this control should provide the material your reviewer needs, not the review itself. Typical deliverables include:
- A review plan showing scope, interval, criteria and the people who will perform the review
- Current ISMS documentation, such as the policy set, the Statement of Applicability and the list of significant changes since the last review
- Evidence packs for sampled controls, including access reviews, change records and incident records
- A record of past findings and the corrective actions taken
The organization owns its controls and the review outcome. The partner should not sign, approve or issue any review report, and should say so in writing.
How do we check that an implementation partner is independent?
Start by asking whether the same firm is planning to certify you. Under ISO/IEC 17021-1, a certification body must be independent of the organization it audits, and it cannot provide consultancy that compromises that independence. Ask the partner to state in writing which work they do, which parts they will not do, and whether they hold any role that could conflict with a review. Check that the reviewer and the partner do not report to the same manager as the people whose controls are reviewed. Finally, confirm that the partner's contract makes the organization responsible for decisions, and that any reviewer has access to records without the partner editing them. Any answer that avoids these questions is a reason to look elsewhere.
How DeployOpen prepares evidence for an independent review
DeployOpen scopes the review and prepares the systems, records and evidence that an independent reviewer will examine, under a fixed scope agreed in writing before work starts. The organization keeps ownership of its controls and of the decisions the review produces. DeployOpen does not act as the reviewer, does not issue reports or certificates, and does not judge its own work. Those outputs come from an independent auditor or certification body that the organization appoints.
In practice, the preparation work for A.5.35 usually covers the areas the reviewer must be able to sample: the defined review scope, the review interval or trigger events for significant changes, the terms of reference for the reviewer, and the records of previous reviews and the actions taken on their findings. DeployOpen can help assemble these items from the implemented platforms, including configuration exports, logs, ticket histories and change records, so that the reviewer can trace each claim back to a source. Ask the partner to show, in the written scope, exactly which records will be produced, where they will be stored and who in the organization will sign off on them.
Before engaging any partner, confirm that the reviewer is independent of the area under review and of the team that prepared the evidence. Ask the auditor or certification body to confirm that the preparation work does not compromise its independence, and keep the separation of roles visible in the documentation. Also confirm with the organization's own certification body which evidence formats it accepts, since requirements for records and sampling are set by the auditor rather than by the implementation partner.

