ISO 27001 Clause 5: What the standard requires from management

What clause 5 covers

An ISMS (information security management system) is the set of processes you use to keep information safe. Clause 5 says what the people at the top have to do with it.

"Top management" means the people who run the company. In a 40-person company that is usually the managing director and one or two others. It is not your IT lead. It is not whoever wrote the policy.

Clause 5 applies to every company that wants the certificate. A team of 12 has the same three requirements as a bank. The certificate cannot be issued without them.

5.1 What management has to show

The standard lists eight things top management has to demonstrate. In practice they group into four.

Direction. Management approves the policy and the security goals, and keeps them in line with what the company actually does. An example: you win your first healthcare customer, so you now hold patient data. Your goals still only cover office laptops. Management has to notice that and set new ones.

Integration. Security sits inside normal work instead of next to it. Concretely: a security check is a step in your supplier selection, access removal is part of the offboarding checklist, and a code change gets reviewed before release. If security only exists in its own folder and its own meeting, it is not integrated.

Resources. Money, people and time, all three.

• Money: budget for training, a password manager, an external audit.
• People: a named person with hours reserved for the work, not an extra duty squeezed into a full week.
• Time: a slot in the release process for a security check, and paid working time for staff to do the training.

The common problem is one person doing all of it on the side while they also keep the laptops running. That is a resourcing decision, and management answers for it.

Visible backing. Security has to come from the top, not only from the IT person. In practice: it is on the agenda of a meeting the company already holds, staff hear about it from the managing director, team leads give their people time to train, and when the security person stops something risky, management stands behind that decision.

Each of these leaves a record: a budget approval, a written assignment, the goals agreed for the year, or the notes from the management review.

5.2 The policy

The policy is one short document. Four things have to be in it.

1. It fits what your company actually does. It says what your business does and what you need to protect, for example the customer data in your product and the laptops your team works on. Your list of risks does not belong here. That is a separate document.
2. It holds your security goals, or says how you set them. A security goal is a target for your security work, with a number, a date and someone who owns it. For example: every new joiner finishes security training within 30 days. Either the goals sit in the policy, or the policy says who sets them and where they are kept.
3. It promises you will meet the rules that apply to you. Not just laws. Contracts count too. In practice you keep a short list of what applies to you and check it once a year. An example: your contract with a bank customer says you report an incident to them within 24 hours and let them audit you once a year. Those two promises sit under this line exactly like GDPR does.
4. It promises you will keep improving. In practice: you record problems as they happen (incidents, audit findings, customer complaints), you fix them, and once a year management reviews whether the system as a whole needs changing. Improvement is visible when something actually changes as a result.

Three things are about where it lives:

• it is written down
• it is shared inside the company
• it is available outside when that makes sense

Two mistakes are common. The first is a 30-page policy full of technical rules that nobody reads, which fails the "shared inside the company" point. The second is reading "rules that apply to you" as laws only, and forgetting what you promised your customers.

5.3 The two assignments people miss

Management decides who is responsible for what in security, and tells those people. Two jobs need a name.

Job one: keep the system in line with the standard. Day to day that means keeping the documents current, making sure the goals and the risk work actually get done, preparing for the audit, and closing out findings.

Job two: report to management. That means bringing the facts to the management review: incidents, progress on the goals, overdue fixes, audit results.

Both come from clause 5.3. You do not need to hire anyone for this. You do not need a Chief Information Security Officer, and the standard has never asked for a "management representative". One person can hold both jobs, and in a small company that is normal. The role can be part-time, and it can be supported from outside. It cannot be nobody, and it cannot be a name on a chart that the person has never been told about.

Responsibility without power does not count. Take a release planned for Friday, where the security check found a serious problem. The person responsible says it cannot ship. If a sales deadline overrules that and nobody records why, they were given a task, not authority. Auditors ask that person what happens when they say no, then ask their manager the same question.

How an auditor finds clause 5 problems

Rarely by reading clause 5 documents. The problems show up elsewhere:

• Security goals with no owner, no number and no deadline (5.1 and 6.2).
• Management review notes that describe the quarter but record no decisions (5.1 and 9.3).
• Overdue security fixes. After a risk assessment you have a list of fixes, each with an owner and a date. If they slip for months and nobody at the top hears about it, that is a clause 5 problem as much as a risk problem.
• Someone saying they asked for money for a security fix last year and never got an answer (5.1, resources).
• A team lead who cannot name the person responsible for security (5.3).

Briefing the CEO the day before the audit does not help. By then the rest of the audit has already shown how things really work.

Where to start

This is about a week of work, spread across a few short sessions.

1. If you have a policy, read it against the four content points in 5.2 and the three points about where it lives, and mark what is missing. If you have no policy yet, write one page covering the four content points and keep the technical rules out of it.
2. Check that the policy is written down, shared with staff, and ready to show a customer who asks.
3. Write down who holds the two assignments in 5.3, what authority comes with them, and confirm it with the people named.
4. Check your security goals. Each one needs an owner, something to measure, and a date.
5. Look at your last management meeting notes. If nothing was decided, fix the agenda for the next meeting before anything else.

What's next?

Clause 5 comes after the groundwork and before the planning. If you have not done the groundwork yet, start with ISO 27001 Clause 4: how to perform a context analysis. That is where you work out who your customers are, what rules apply to you, and what you need to protect, which is where your security goals come from.

Once management has set the direction, ISO 27001 Clauses 6 & 8: planning and executing your risk management turns those goals into a plan.