Information Security Management
ISO 27001 Clause 5: Leadership
ISO 27001 Clause 5 highlights the leadership role in an ISMS. An ISMS will be “checkbox compliance” and ineffective without senior management backing.
Leadership actions under Clause 5 must align with the organisation’s purpose and strategic direction, ensuring that information security objectives support the business’s overall goals.
Written By: Alan Parker, ISO 27001 Consultant
Last Updated: 27/4/26
Explore Each ISO 27001 Clause in More Detail by Selecting One to View
Table of Contents
For SMEs, Clause 5 of 27001 often means involving the owner, CEO, or top management team in information security.
I can’t think of anything more destined for disaster in an ISO 27001 project than just assigning it to a junior team member as a compliance activity and never thinking about it again.
You must demonstrate ongoing involvement, awareness and guidance from the highest level of your organisation.
This guidance focuses on Clause 5 but is part of the wider introduction to ISO 27001’s Clauses. Please click the link below for a higher-level view and context of all the clauses.
What are the Subclauses of ISO 27001 Clause 5: Leadership?
Three main subclauses outline how an organisation should approach leadership.
They are;
Clause 5 didn’t change materially in the 2022 update – the structure and requirements are essentially the same as in the 2013 version.
ISO 27001 Clause 5 — Leadership
How leadership commitment drives the policy and structure your ISMS is built on
Top management must establish a documented IS policy, communicate it across the organisation, and make it available to relevant interested parties.
Top management must assign and communicate responsibilities for ensuring the ISMS works and for reporting its performance back to leadership.
Clause 5.1 – Leadership and Commitment
Clause 5.1 requires ‘top management’ to demonstrate leadership and commitment for the information security management system (ISMS).
Who is ‘Top management in an SME?’
It’s simply going to be your founder, CEO, or someone that reports directly into that person. So, I’d say sponsorship and support from the CTO, but awareness from the CEO would be sufficient.
What does leadership commitment mean practically?
It means senior leaders should:
- Ensure the information security policy and objectives are established and aligned with the organisation’s direction. Management needs to integrate ISMS requirements into the organisation’s processes, ensuring that security controls and measures are embedded rather than treated as an isolated IT project.
- Provide the necessary resources and ensure adequate support for the ISMS. If the security team says, “to mitigate this risk, we need to implement X,” leadership should consider and allocate budget, personnel, or other resources as appropriate to support the information security management system.
- Communicate the importance of information security and conformance to ISMS requirements. Leaders should set the tone. This could be done through emails to staff about security, discussions in all-hands meetings, or the inclusion of ISMS performance in management discussions. Actively engaging with staff helps foster a strong security culture and promotes information security awareness throughout the organisation.
- Support roles and collaborate. They need to empower the person in charge of the ISMS (like an Information Security Manager), supporting persons, and other relevant management roles, and remove obstacles to their duties. Clearly defining key roles and involving the leadership team ensures the ISMS is effective.
- Promote continual improvement. Leaders shouldn’t see ISMS as “we did it, check the box” but encourage ongoing security enhancement. Regular management reviews and evaluations help ensure the management system and the ISMS achieve their intended outcomes.
In a small company, leadership and commitment might be demonstrated by the managing director personally kicking off the ISO 27001 project, regularly checking progress, and being present at key meetings (such as risk assessment workshops or the management review), with senior management and human resources actively participating in ISMS activities.
It could also be as straightforward as the CEO addressing all employees with a statement such as “we are implementing ISO 27001 because we value our customers’ trust, and we expect everyone to follow the new security policies.” Addressing information security risks and achieving reduced risk through effective information security management are key parts of this commitment.
The main point I’m trying to underline here is: the ISMS must have visible and genuine support from the top.
Auditors, including the external auditor, often interview top management to gauge their commitment and require evidence of leadership’s involvement.
If an MD or CEO is clueless about the ISMS or treats the audit as a nuisance, that’s a red flag. Conversely, if they can explain why security is important, the ISMS goals, and how the information security management system supports the protection of information assets, it demonstrates compliance with 5.1.
ISO 27001 auditors want to see that senior leaders feel accountable and don’t consider themselves “above” the ISMS policies.
Clause 5.2 – Policy
ISO 27001 Clause 5.2 requires establishing an Information Security Policy.
This is a high-level document, typically a brief policy statement from top management, that sets the direction for information security in the organisation. It may then link to subpolicies on the acceptable use of equipment or Bring-Your-Own-Device (BYOD) policies.
So, I refer to it often as the ‘Parent Policy’, which signposts to the topic-specific sub-policies that every employee, contractor and supplier should be issued with, so they can review them and understand how the organisation approaches security.
The standard says the policy should:
- Be appropriate to the organisation’s purpose (so it reflects your business context and needs).
- Include commitments to satisfy applicable requirements (like laws, customer requirements) related to information security.
- Include a commitment to continually improve the ISMS.
- Include the objectives of the ISMS or the framework for managing them.
In simpler terms, the policy should explain why information security is important to the organisation and what it intends to do about it. Information security policies are essential for guiding employee and stakeholder behaviour, ensuring compliance, and supporting the overall security management system, ISMS, by providing a formal statement of the organisation’s approach to information security.
Example: I typically include a statement from the CEO in the policy, such as: “This company is committed to preserving the confidentiality, integrity, and availability of all forms of information within our scope. We will meet all regulatory and contractual security obligations, manage risks through an ISMS per ISO 27001, and continuously improve our security posture.”
The policy should also be approved by top management (often literally signed by the CEO or equivalent), a strong signal of leadership commitment (per the above example).
Additionally, the policy must be communicated within the organisation and be available to interested parties as appropriate.
In practice, you should distribute it to employees (via email, intranet, training, posters, etc.) and possibly share it externally (some companies publish a sanitised version of their policy or at least make a statement on their website for transparency).
For a smaller organisation, don’t overthink the policy—it doesn’t have to be long.
Clear, concise, and endorsed by the boss is the way to go.
My toolkit below contains policies, leadership statements, scope documents & workbooks to help you.
ISO 27001 Full Document Toolkit
Every document your auditor
expects to see.
130 Word & Excel templates, ready to edit. Policies, risk register, Statement of Applicability, audit pack, staff communications — all updated for ISO 27001:2022.
130 templates
Instant download
Written by practising consultant
ISO 27001:2022
Tip: I highly recommend keeping the policy super simple. Too often, the ones I see are like legal jargon, difficult for people to understand and, therefore, comply with, which is the primary purpose of the policy—compliance.
Make sure employees are aware of it; sometimes, auditors will ask a random employee whether they’ve seen the information security policy or what it says in general. Often, HR has systems that can track who has ‘read and accepted’ a policy, which is great for tracking as an ISMS KPI for performance later.
Ultimately, the Information Security Policy document, Clause 5.2, must be documented. Auditors will ask to see it and check that it meets the criteria (commitments, etc.) and that it’s current (e.g., version controlled, signed in this year).
Clause 5.3 – Organisational Roles, Responsibilities and Authorities
Clause 5.3 requires top management to ensure that roles and responsibilities for the ISMS are assigned and communicated.
Essentially, everyone should know what they are responsible for in the ISMS.
Clause 5.3 also states that those in roles must have the authority to fulfil their responsibilities. It’s pointless to make someone responsible for security if they can’t make changes or enforce policies, for instance.
In a small business, roles may overlap – that’s okay, but clarity is key. You might formally document roles & responsibilities in an “ISMS Roles and Responsibilities” document or within job descriptions.
At a minimum, ensure that by the time of the audit, it’s crystal clear who the ISMS leader is and that other staff know their part. A common way to implement this is via an organisation chart for the ISMS or a RACI matrix that lists tasks vs. people.
Auditor’s perspective: They will check that responsibilities are indeed assigned. They might review an org chart or a responsibility matrix and confirm that an ISO 27001 coordinator or lead has been appointed (auditors often like to interact with that person).
They might also interview a few people: e.g., ask the CEO, “Who is in charge of day-to-day ISMS management?” or ask some department head, “What is your responsibility in the ISMS?” to ensure effective communication of roles.
If your documentation says Alice is responsible for risk assessment, but Alice doesn’t know that, that’s a problem.
Tip: The ISO 27001 standard says only two responsibilities are mandatory: one to ensure the ISMS conforms to the standard and one to report on the ISMS’s performance to management. If these are the only roles you define, then I (and any auditor) would argue that you haven’t considered the R&Rs thoroughly enough.
A subtle point: Clause 5.3 ties to Clause 7.2 (Competence) – it’s not enough to assign someone; you must also ensure they’re competent (Clause 7.2) and Clause 7.3 (Awareness) – ensure they know their role. So these clauses interlink.
Examples of ISO 27001 Roles & Responsibilities
Clause 5.3 — ISMS Roles and Responsibilities
Two assignments are mandatory under the standard; everything else follows good practice
"Ensuring that the information security management system conforms to the requirements of this document."
Someone must formally own the ISMS and be accountable for ensuring it meets ISO 27001. This is typically the ISMS Lead, Information Security Manager, or equivalent — and the assignment must be documented and approved by top management.
"Reporting on the performance of the information security management system to top management."
Someone must be responsible for feeding ISMS performance — including audit results, incidents, and metrics — back to senior leadership. This is often the same person as 5.3a, and provides the input for the management review (Clause 9.3).
The day-to-day owner of the ISMS. In smaller organisations this is often a senior IT or operations manager; in larger ones a dedicated security role.
Provides direction, resources, and ultimate accountability for the ISMS. Must actively participate — not simply delegate everything downward.
Owns the technical controls and infrastructure. Often holds the ISMS Lead role in smaller organisations, though this conflation can create audit issues.
Owns the people-related controls across the employee lifecycle. Often under-represented in ISMS governance despite owning significant Annex A obligations.
Accountable for specific risks in the risk register — typically a senior manager in the function where the risk resides. May be the ISMS Lead or delegated to department heads.
Conducts the internal audit programme required by Clause 9.2. Must be independent of the area being audited — in small organisations this often means using a different staff member or an external resource.
What Clause 5.3 actually looks like in a Smaller Business
In a small business, the realistic structure is much simpler than the standard language suggests.
You’re typically looking at three roles, not three departments:
A top management sponsor – usually the CEO, MD, or founder. Owns the ISMS in name, attends management reviews, signs the policy, and is publicly accountable.
An ISMS lead – the person actually doing the day-to-day work. Often, this is the IT manager, an operations lead, a CTO, or, in very small businesses, the CEO.
Departmental contacts – one nominated person in each in-scope area (HR, engineering, sales, finance) who can speak for their department in audits and respond to security incidents.
Role overlap is fine and often unavoidable in a micro-business. A developer who is also the security lead is a perfectly valid arrangement. The CEO acting as both the top management sponsor and the ISMS Manager is something I see quite regularly in 5-15-person businesses. ISO 27001 doesn’t prohibit overlap – it just expects clarity.
The documentation needs to show which hat the person is wearing when, particularly for the two mandatory responsibilities the standard names: ensuring ISMS conformance, and reporting on ISMS performance to top management. If both fall to the same person, document this explicitly with a note on how performance reporting is handled (e.g., “the CEO presents the ISMS performance report to the board quarterly”).
The single most common SME pitfall is failing to formally assign those two mandatory responsibilities. Auditors will check. A simple one-page roles document or a small RACI matrix is enough.
A worked example – small SaaS business (12 staff)
| Activity | CEO | ISMS Lead (CTO) | Engineering Lead | HR Manager | All Staff |
|---|---|---|---|---|---|
| Approve Information Security Policy | A | R | C | C | I |
| Manage risk register | A | R | C | C | I |
| Conduct an internal audit | A | C | C | C | I |
| Run an annual management review | R | R | C | C | I |
| Report ISMS performance to top management | A | R | I | I | I |
| Ensure ISMS conforms to ISO 27001 | A | R | C | C | I |
| Respond to security incidents | A | R | R | C | I |
R = Responsible, A = Accountable, C = Consulted, I = Informed
In the above example, the CEO is “Accountable” for almost everything (which makes sense – they sign the policy and own the ISMS at the board level), but the CTO is “Responsible” for the day-to-day execution.
Both mandatory responsibilities (the last two rows) are clearly assigned. An auditor reading this matrix would have no questions about who owns what.
You don’t need a complex RACI – even a simple “X person does Y” list works for very small businesses. The point is that someone, somewhere, has the responsibilities written down – but that’s just good business practice isn’t it?
What are the Documentation and Outputs for ISO 27001 Clause 5?
Clause 5 — What Evidence Is Required?
Documents and records an auditor will expect to see at certification and surveillance audits
A documented, approved IS policy that commits the organisation to satisfying applicable requirements and to continual improvement. Must be appropriate to the organisation's purpose — a generic downloaded template with your logo added will attract scrutiny. The policy must be version-controlled, dated, and attributable to a named senior leader.
A signed or formally approved policy document with a named signatory in a leadership role — CEO, Managing Director, or equivalent. Auditors distinguish between a policy "approved" by an IT manager and one demonstrably owned by the business. The management review record (Clause 9.3) provides supporting evidence of ongoing leadership engagement.
A documented assignment of ISMS responsibilities — who owns the ISMS, who owns individual controls or policy areas, and who is responsible for reporting performance to top management. This can be a RACI matrix, an annex to the IS policy, or a standalone roles document. It must name roles or job titles, not just functions.
Records showing staff have received and acknowledged the IS policy — typically through induction records, all-staff emails, intranet publication logs, or training completion records. Auditors may ask employees whether they are aware of the policy; communication records demonstrate it was formally distributed, not just posted somewhere and forgotten.
Where relevant — typically for customer-facing or supplier-facing contexts — evidence that the IS policy is accessible to interested external parties. This is often achieved by publishing a summary or the full policy on the organisation's website, or including it in supplier onboarding packs. Many organisations publish a high-level IS policy statement publicly while keeping the detailed policy internal.
A formal record — letter, email, job description, or board minute — designating the individual responsible for the ISMS. This provides a clear audit trail linking top management accountability (5.1) to the operational ownership of the system (5.3). Without it, auditors may question whether the ISMS owner role has genuine organisational authority.
What Do Auditors Look For in Clause 5
When preparing for ISO 27001 Clause 5, it’s essential to be ready for both external audits and the internal audit process. Demonstrating leadership commitment and providing clear evidence of compliance are critical for success in both types of audits.
Auditors will scrutinise Clause 5 to ensure the ISMS isn’t just an “IT initiative” without real management buy-in. Typical things they check:
Clause 5 — What Auditors Look For
Five areas auditors examine to verify genuine leadership commitment, not just paperwork
Case Study
In one company I was consulting with, the auditor asked to see the information security policy and found it nicely written, signed by the CEO, and published on the intranet. Lovely.
Then, during interviews, the auditor asked another manager, “How do you know management is committed to this ISMS?” The manager referenced that the CEO sent quarterly updates that included security elements and that the CTO led a monthly security team meeting. The auditor also asked the CEO what the biggest security risks to the business were. The CEO was able to mention a couple of relevant points (showing he was briefed and aware) and reach for the risk log, but only those items that were big enough to get escalated to him – he didn’t need to know the details of every risk (just the big ones).
The interactions weren’t in-depth, but they satisfied the auditor that Clause 5 was well implemented: leadership was visibly engaged, not just something written on paper. Two short interviews. No deep-dive into documentation. The CEO didn’t need to recite the policy or risk register verbatim – he just needed to know where the risk log was, what the top risks were, and that he’d seen the CTO’s quarterly updates. That was enough.
The lesson: visible engagement beats memorised content. The whole thing isn’t a memory test, but it is an awareness test – if that make sense?
Common Mistakes in Clause 5
In ten-plus years of helping organisations through Clause 5, the same handful of mistakes come up again and again. None of them is fatal on its own, but they all tend to undermine the credibility of an ISMS in front of an auditor.
Treating the policy as something IT writes. If the Information Security Policy is drafted, signed, and owned by IT, it can’t credibly demonstrate top management commitment. I’ve sat in audits where the policy was perfectly well written but signed by an IT Manager – the auditor’s first question was “where’s the CEO’s involvement?” The policy needs to come from, or at least be visibly owned by, the business’s leadership.
Defining only the two mandatory responsibilities. This is like doing your homework 3 minutes before handing it in. Yes, the standard names two specific responsibilities that must be assigned: ensuring ISMS conformance, and reporting on ISMS performance to top management. If those are the only two things in your role’s document, you’re meeting the bare minimum, but you’ll struggle to show the depth of governance an auditor expects. The mandatory pair is a floor, not a ceiling.
Letting the CEO opt out. Clause 5.1 implies leadership should set the example – locking screens, attending awareness training, following the policy like everyone else. If a director refuses to do something the policy requires of “all employees”, that’s a real finding waiting to happen. It doesn’t come up often, but when it does, it’s awkward and damaging.
Confusing the ISMS Manager with top management. These are two different roles. The ISMS Manager runs the day-to-day; top management owns the ISMS at the board level. In a small business, they can be the same person, but the documentation should make it clear which hat they’re wearing when. Auditors will spot the conflation if you blur the line.
“We have a policy” without distribution evidence. The standard requires the policy to be communicated within the organisation. A policy file sat on the network drive that nobody’s seen doesn’t satisfy this. I’d always recommend keeping a record – email confirmation of receipt, intranet read-and-acknowledge tracking, induction completion – so you can prove distribution happened.
Treating policy review as a once-every-three-years job. The policy should be reviewed at least annually, and absolutely whenever something significant changes (a new product, a regulatory shift, a major incident). Auditors check the version date – and a policy signed three years ago by someone who’s no longer at the company is a finding waiting to happen.
Assigning roles without authority. It’s pointless to make someone responsible for security if they can’t make changes, allocate budget, or enforce policies. I see this most often when an enthusiastic mid-level manager is given the ISMS Lead role but no actual authority. The auditor will ask “and what happens when you need to push back on a senior decision?” – if the answer is “I’d raise it with my boss”, the role isn’t really a role.
What If Leadership Won’t Engage
So here’s one last thing to consider, and it’s a question I get asked privately more than any other, because people don’t want to acknowledge it: what happens when the CEO doesn’t really want to be involved, or the leadership team treats ISO 27001 as an IT problem they’ve delegated and now want to forget about?
It’s more common than you’d think (and it’s a general problem I’ve seen over my 30 years of IT project management, to be honest). It doesn’t have to be fatal to the project, but it does have to be managed honestly.
A few practical strategies I’ve used in real engagements:
Document everything you ask for and the response. Email the CEO requesting their input. Capture the response – or the silence. This isn’t passive-aggressive; it’s evidence for the auditor that you’re trying, and it’s protection for you when leadership engagement is later questioned, or you are issued a non-compliance. I hate to say it, but a bit of arse covering is important here.
Get one specific commitment per quarter. Don’t ask for “more involvement” – that’s vague and easy to defer. Ask for something specific and time-bound, such as a 30-minute slot to review ISMS performance once a quarter. Or ask the CEO to record a 2-minute video for staff on why security matters, or sign off on a statement you’ve drafted but comes from them. Ask them to chair the management review, even if you’ve prepared everything for them and effectively carry the meeting. Specific, time-boxed asks get done; vague ones don’t (certainly in my experience).
Use the certification deadline as the lever. Most ISO 27001 projects exist because of a commercial driver – this is their ‘bruised rib’ weak spot – a tender, a client contract, a procurement requirement. Tie leadership engagement requests directly to that driver: “The auditor will want to interview you – we have until [date] to be ready.” External pressure tends to move leaders that internal asks don’t, I’m afraid to say.
Be honest with the auditor. If leadership engagement is a work in progress, say so. Auditors would rather hear “we know this is an area we’re developing, and here’s our plan” than discover a hollow ISMS through interviews and questioning. Honest framing can often get you a recommendation rather than a finding; deception or hoping it won’t come up usually gets you a non-conformity.
If leadership engagement remains absent despite all of this, the honest answer is that ISO 27001 certification probably isn’t the right goal for the business right now. A certificate without genuine leadership commitment is fragile – it’ll struggle through surveillance audits, and the ISMS won’t deliver value internally. Better to acknowledge that early than to push through and certify something that won’t last.
FAQs
Why is leadership so important in ISO 27001 Clause 5?
Clause 5 puts leadership at the centre of the ISMS. Without visible and active support from top management, an ISMS risks becoming a tick-box exercise rather than something that truly protects the business.
Leadership ensures that information security is aligned with strategic goals, properly resourced, and taken seriously across the organisation. Auditors expect to see senior leaders engaged, not just signatories to a policy.
What documents are required for Clause 5?
The only mandatory document under Clause 5 is the Information Security Policy (Clause 5.2), which must be formally approved and communicated. However, auditors will also expect to see:
– Defined roles and responsibilities (Clause 5.3)
– Evidence of management commitment (Clause 5.1), such as meeting minutes, CEO communications, or budget approvals
– Possibly training or awareness records for top management
These show that leadership is not only on board but also actively involved.
What’s the best way to assign ISMS roles and responsibilities?
You don’t need a complex org chart, but you do need clarity.
Assign key ISMS roles (e.g., ISMS Manager, Internal Auditor, Risk Owner) and make sure those people are aware of and capable of fulfilling their responsibilities.
This could be documented in a RACI matrix, ISMS manual, job descriptions, or a dedicated roles document. Auditors will want to see that people aren’t just named in documents — that they actually know their roles and what they are responsible for.
Further Reading
Get a copy of ISO 27001 from here.
Includes all the mandatory document templates — free, no commitment
Author Background
This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.
With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.
Qualifications: ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.
Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.
