ISO 27001 Control 5.35: Independent Review of Information Security

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Everyone believes their own security is reasonable. That is not a criticism; it is how people work. You build something, you test it the way you think it might fail, and you stop when it passes your tests. The trouble is that your tests are shaped by the same assumptions that shaped what you built.

Control 5.35 exists to break that loop. It asks for your approach to information security, and the way you have implemented it, to be reviewed by someone independent: someone who did not create it, set it up or run it. That review happens at planned intervals, and again when something significant changes.

This page covers what independence actually means in a business of twenty people, the review that no ISO 27001 audit will ever do for you, and how to make the reports work twice. There is a free review and compliance log further down.

What control 5.35 actually asks for

The control requires that your approach to managing information security, and its implementation across people, processes and technology, is reviewed independently at planned intervals or when significant changes occur. In practice that means:

• A plan. What will be reviewed, by whom and when. Annually across the whole ISMS is a common pattern, with deeper reviews of particular areas on their own cycle.
• Independence. The reviewer did not create or set up what they are reviewing, and does not report to the person who did in a way that compromises their judgement.
• Competence. They know enough about the area to find real problems. A generalist can review a policy; a generalist cannot review your cloud configuration.
• Triggers. A new product, a move to a new platform, an acquisition or a serious incident are all significant changes that should prompt a review outside the normal cycle.
• Results that go somewhere. Findings reported to management, actions tracked to completion, and the report kept as evidence.

In the 2013 edition this was control A.18.2.1. The 2022 version makes the scope clearer by naming people, processes and technologies, which is a reminder that a review of the policy documents alone is not enough.

Where 5.35 sits among the review activities

ISO 27001 has several overlapping kinds of checking, and it helps to know which is which, because an auditor will ask about each.

Internal audit under clause 9.2 is one way of meeting 5.35, but not the only one. A well-run internal audit programme covers much of what 5.35 asks for. What it usually does not cover is deep technical review, and for some organisations that is where the real risk sits. Control 5.36 is the other half: managers checking their own areas. 5.35 is somebody else checking.

What independence means in a small business

The auditor is looking for something simple: the person reviewing a thing did not create or set it up. That is the whole test. It does not have to be a third party, and the standard does not say it must be.

In a business of twenty people, that can be done internally more often than people expect. The operations manager can review the HR security process. The finance lead can review access to the finance systems. A developer from one team can review another team’s deployment process. What does not work is the person who wrote the ISMS reviewing the ISMS, or the IT lead reviewing the infrastructure they built.

Where nobody internal is both independent and competent, bring someone in. An external internal audit service like ours is one route, and for many small organisations it is the most practical one, because it gives independence and audit experience you could not justify hiring for. But the review does not have to come from an ISO consultant, and for some areas it should not.

The review no ISO 27001 audit will do for you

If you develop software, this is the most important section on this page.

An ISO 27001 certification audit, and an ISO 27001 internal audit, examine your management system. They will check that you have a secure development policy, that code is reviewed, that vulnerabilities are managed and that someone tests things before release. They will not read your code. They will not log into your cloud console and look at how it is configured. They will not try to break in. That is not what they are for.

Time after time, I meet software companies who tell me they do not need an independent technical review. “We’re good, thanks. We know what we’re doing.” Then they have one done by people who specialise in it, and the report comes back with serious vulnerabilities in their code and infrastructure. Exposed storage, excessive permissions, secrets in repositories, injection flaws, admin interfaces open to the internet.

It is rarely incompetence. Developers are paid to ship, and they are good at it. Working fast and working securely pull in different directions, and when the deadline arrives speed usually wins. And many capable engineers simply have not had the experience to know what secure really looks like, because nobody has ever shown them what an attacker would do with their work.

So, for any organisation that builds and runs software, I strongly recommend a specialist independent review of the code and infrastructure as part of meeting 5.35. Depending on what you build, that might be:

• A penetration test of your application and the infrastructure it runs on.
• A cloud configuration review of your AWS, Azure or Google Cloud environment.
• A secure code review of the parts of your product that handle authentication, payments or customer data.
• An external vulnerability scan on a regular cycle, with the results reviewed by someone outside the team.

Scope it to what matters, do it at least annually and after major changes, and treat the findings the same way you would treat audit findings: logged, owned, fixed and retested.

Proportionate review: what, who and when

A workable plan for a small business usually has three layers.

The whole ISMS, once a year

An annual review of the approach as a whole: the scope, the risk assessment, the policies, and whether the controls in the Statement of Applicability are actually working. This is the layer an internal audit programme covers well, whether you run it internally or bring someone in.

Specialist areas, on their own cycle

The technical review described above for anyone who builds or hosts software. A review of the IT support company’s work by someone who is not the IT support company. Physical security by someone who does not hold the keys. Each on whatever cycle the risk justifies.

When something significant changes

A new product, a move to a new cloud platform, an office move, a merger, a serious incident or a big change in headcount. Each of these can quietly undo controls that were working, and each is a reason to have someone look again before the next scheduled review.

Make the reports work twice

An auditor will expect to see the reports. A plan with nothing completed against it is weak evidence; a report with findings and a record of what you did about them is strong evidence, even if the findings were uncomfortable.

The same reports can also save effort elsewhere. If a certification auditor sees a recent SOC 2 report, a penetration test or another independent assessment, it gives them reliable evidence for the areas where the two overlap, and that can make those parts of the audit quicker. Ask your certification body how they take it into account. Customers asking security questionnaires will often accept the same reports, and a recent penetration test summary answers a good third of most questionnaires on its own.

Keep them together, in the log below or alongside it, so the evidence is in one place when somebody asks.

What auditors will look for

If I were auditing you, this is how I would work through 5.35.

1. The plan. Is there a defined programme of independent reviews, with dates, scope and reviewers? Does it cover people, processes and technology, or just documents?
2. Independence. For each review, who did it and did they build or run what they reviewed? I will look at names and roles, not just the word “independent” on a cover page.
3. Competence. Was the reviewer capable of finding real problems in that area?
4. The reports. I expect to see them. Findings, dates, who received them.
5. Follow-through. What happened to the findings? Pick one and show me it was fixed and checked.
6. Change triggers. What significant changes happened this year, and did any of them prompt a review?

Common issues

• The person who wrote the ISMS reviewing the ISMS, and calling it independent.
• Internal audit treated as the whole of 5.35, with no technical review at all in a software company.
• A penetration test done once, two years ago, for a customer, and never repeated.
• Reviews of documents only. Nobody looks at whether the controls work in practice.
• Reports filed with no record of what happened to the findings.
• Major changes, such as a platform migration, with no review before or after.
• An IT provider effectively reviewing its own work.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• When was your security approach last reviewed by someone who did not build it, and where is the report?
• If you build software, when did a specialist last test your code or infrastructure?
• What did the last review find, and is every finding closed?
• What significant change happened in the last year, and did anyone review its effect on security?
• Who reviews the work of your IT support company?

The second is the one to sit with if you write code. It is the area where confidence and reality are furthest apart.

A worked example

The details below are typical rather than drawn from a single engagement. This is a composite of what a first look at 5.35 turns up in a software business.

A 25-person SaaS company, preparing for certification. The CTO wrote most of the ISMS and the infrastructure. Internal audits had been planned with the CTO as auditor. There had been one penetration test, three years earlier, commissioned for a customer deal.

What the review found

• The planned internal auditor was the person who had built most of what was to be audited.
• No technical review since the old penetration test, despite a move from one cloud provider to another in the meantime.
• The old test’s findings had never been tracked. Two were still open.
• A new external review, once commissioned, found a storage bucket of customer exports open to the internet, an unused admin account with full rights, and API keys committed to a code repository.

What changed

• Internal audit moved to an external provider for the ISMS-wide review, with the operations manager reviewing HR and supplier processes internally.
• An annual penetration test and cloud configuration review added to the plan, plus a trigger for any platform change.
• All findings from both reviews logged, assigned and retested, with the reports filed together.
• The penetration test summary added to the pack sent to customers answering security questionnaires.

The technical findings were fixed within a fortnight. Every one of them had been there for months, and nobody inside the company had found them, because nobody inside the company was looking from the outside.

How control 5.35 links to other clauses and controls

• Clause 9.2, Internal audit. The main vehicle for independent review in most organisations. Auditors must be objective and impartial, which is the same independence test.
• Clause 9.3, Management review. Where the results of independent reviews go, and where decisions get made.
• Control 5.36, Compliance with policies, rules and standards. Managers checking their own areas. The companion to 5.35.
• Control 8.8, Management of technical vulnerabilities. Penetration test findings feed straight into your vulnerability management.
• Control 8.25, Secure development life cycle. and Control 8.29, Security testing in development and acceptance. Where secure code and testing live day to day. Independent review checks they work.
• Control 8.34, Protection of information systems during audit testing. Agree scope and timing before a penetration test touches live systems.
• Control 5.19, Information security in supplier relationships. An external reviewer is a supplier with deep access, so treat them as one.
• Clause 10.2, Nonconformity and corrective action. Findings that are nonconformities need corrective action and a record of it.

What I find in audits

Every software client I have worked with that commissioned its first external penetration test came back with at least one high-severity finding. Almost none of the software businesses I work with carry out security testing before release, which is one reason an independent review so often finds things for the first time. More detail is in my findings report.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• Penetration testing. NCSC guidance on commissioning and using penetration tests.
• Cloud security guidance. NCSC guidance on configuring and using cloud services securely.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.
• NCSC penetration testing guidance. How to scope, commission and use a penetration test.
• NCSC CHECK scheme. The NCSC scheme for approved penetration testing companies.
• OWASP Web Security Testing Guide. A widely used methodology for testing web applications.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call