How to implement ISO 27001 Annex A 5.1 Policies for Information Security

Summary

This video script provides a comprehensive guide to implementing information security policies in line with ISO 27001 Annex A 5.1. It emphasizes the distinction between policies and processes, advocating for clear communication of policies to staff and stakeholders without compromising confidentiality. The script introduces the updated 2022 standard's approach to information security, suggesting a high-level policy supported by topic-specific policies. It outlines steps for policy creation, ownership, approval, distribution, and annual review, highlighting the importance of documentation and employee acknowledgment. The narrator, Stuart Barker, offers practical advice for policy management and preparation for ISO 27001 certification.

Takeaways

• 📜 ISO 27001 Annex A 5.1 focuses on establishing information security policies.
• 💼 Policies should state what the organization does, not how it does it.
• 🔗 Policies are separated from processes to protect sensitive information and avoid confusion.
• 📈 The updated 2022 version of ISO 27001 emphasizes a high-level information security policy and topic-specific policies.
• 🛠️ The ISO 27001 toolkit is a valuable resource for creating and implementing policies.
• 📝 Policies should be based on identified risks and the controls chosen to mitigate them.
• 👤 Policies should have clear ownership and accountability within the organization.
• ✅ Policies must be approved through an internal approval process.
• 📢 Policies need to be distributed and acknowledged by relevant personnel.
• 🔄 Regular updates and reviews of policies are necessary, at least annually.
• 📈 Auditors look for evidence of policy approval, distribution, and acceptance.

Q & A

What is the main focus of ISO 27001 Annex A 5.1?

The main focus of ISO 27001 Annex A 5.1 is on information security policies, which are statements of what an organization does for certain topics related to information security.

Why is it important to separate policies from process documentation?

Policies should be separated from process documentation to avoid exposing sensitive internal operations and to prevent confusion. Policies communicate what is done, while processes explain how it is done.

What is the difference between a high-level information security policy and topic-specific policies?

A high-level information security policy provides an overarching statement of the organization's commitment to information security, while topic-specific policies address particular areas or requirements of ISO 27001.

Where can one find resources to help with implementing information security policies for ISO 27001?

Resources for implementing information security policies can be found on hightable.io, which includes a video guide, a step-by-step guide, and a blog for more detailed information.

What is the recommended approach to creating information security policies according to the script?

The recommended approach is to start with downloading the ISO 27001 toolkit, which contains pre-populated policies that can be rebranded and used as a starting point.

Who should own the information security policies within an organization?

Policies should be owned by someone within the organization who is responsible for them, ensuring accountability.

How often should information security policies be reviewed and updated?

Information security policies should be reviewed at least annually, and updated whenever there are changes to reflect those changes.

What is the importance of distributing and acknowledging policies within an organization?

Distributing policies ensures that relevant staff are aware of them, and obtaining acknowledgements verifies that they have been read, understood, and accepted.

What does the ISO 27001 standard say about the necessity of policies for every control?

The ISO 27001 standard does not require a policy for every single control. Policies should add value and be relevant to the organization's processes and risk management.

What are some top tips for maintaining and communicating information security policies?

Top tips include regularly communicating the location of policies, reinforcing the message throughout the year, integrating policy communication into the HR onboarding process, and ensuring document markup and version control are consistent.

Who is Stuart Barker and what is his role in relation to ISO 27001?

Stuart Barker is referred to as the ISO 27001 Ninja, and he provides guidance and resources for implementing ISO 27001 standards, including information security policies.

Outlines

00:00

📜 Introduction to Information Security Policies for ISO 27001

The paragraph introduces the implementation of ISO 27001 Annex A 5.1, focusing on information security policies. It clarifies the difference between policies and process documentation, emphasizing that policies are statements of what an organization does, not how it does it. Policies are meant to communicate actions to staff and stakeholders without compromising confidentiality or security. The speaker highlights the importance of separating policy from process to avoid confusion and protect sensitive information. The ISO 27001:2022 standard is mentioned, advocating for a high-level information security policy and topic-specific policies to cater to different audiences without overwhelming them with irrelevant details. The speaker also discusses the process of creating, owning, approving, and distributing policies, as well as the importance of policy review and updates.

05:02

🔄 Policy Approval, Distribution, and Management

This paragraph delves into the process of policy approval, emphasizing the need for internal approval mechanisms and the importance of documenting approvals in Version Control. It discusses the distribution of policies to relevant personnel, suggesting methods for tracking distribution and ensuring accessibility. The paragraph also addresses the need for acknowledgment from staff that they have read, understood, and accepted the policies. The speaker advises on regular communication of policy updates and the importance of integrating policies into HR onboarding processes. Additionally, the paragraph provides tips for auditors, such as ensuring document markup is consistent and that there is evidence of policy approval, distribution, and agreement. The speaker concludes by reinforcing the idea that not every control requires a policy and that policies should add value and be relevant to the organization's processes.

Keywords

💡ISO 27001

ISO 27001 is an internationally recognized standard that provides a framework for establishing, implementing, maintaining, and continuously improving an organization's information security management system (ISMS). The video discusses the importance of adhering to this standard, particularly in the context of information security policies. It is foundational to the video's narrative as it sets the stage for the discussion on policies and risk management.

💡Annex A Controls

Annex A Controls refer to a set of controls provided in the ISO 27001 standard that organizations can use to manage information security risks effectively. The video script mentions starting a series of implementation videos on these controls, emphasizing their significance in achieving compliance with ISO 27001.

💡Information Security Policies

Information Security Policies are formal statements that outline the measures an organization takes to manage information security risks. The video emphasizes the creation and implementation of these policies as a critical component of ISO 27001 compliance. Policies are distinguished from procedures, which describe 'how' to achieve the objectives set by policies.

💡Risk Management

Risk Management is a systematic approach to identifying, assessing, and controlling risks. In the context of the video, risk management is central to the development of information security policies, as these policies are designed to mitigate risks identified through the risk assessment process.

💡Policies vs. Procedures

The video script makes a clear distinction between policies and procedures. Policies are what an organization does (the 'what'), while procedures explain how to do it (the 'how'). This differentiation is crucial for clarity and effective communication within the organization.

💡High Level Information Security Policy

A High Level Information Security Policy is a broad, overarching policy that sets the tone for an organization's commitment to information security. The video suggests that ISO 27001:2022 emphasizes the need for such a policy, which then branches out into more specific topic-related policies.

💡Topic Specific Policies

Topic Specific Policies are detailed policies that address particular areas of information security, such as cryptography or physical security. The video advocates for a structured approach where these policies are tailored to the specific needs and risks of different parts of the organization.

💡Policy Ownership

Policy Ownership refers to the assignment of responsibility for a policy to a specific individual or team within an organization. The video stresses the importance of clearly defining ownership to ensure accountability for the policy's development, implementation, and ongoing review.

💡Approval Mechanism

An Approval Mechanism is the process by which policies are reviewed and sanctioned within an organization. The video mentions that policies should be approved using the organization's internal approval processes, which may include management review meetings.

💡Distribute Policies

Distribute Policies is the process of making policies available to the relevant stakeholders within an organization. The video highlights the need to ensure that policies are communicated effectively and are accessible to those who need to adhere to them.

💡Acknowledgement

Acknowledgement in the context of the video refers to the process of obtaining confirmation from employees that they have read, understood, and agree to comply with the policies. This is a critical step in ensuring that policies are not only communicated but also accepted and internalized by the staff.

💡Version Control

Version Control is a system used to track and manage changes to documents, including policies. The video suggests that maintaining version control is important for showing the evolution of policies over time and for documenting when policies were reviewed or updated.

Highlights

Introduction to ISO 27001 Annex A 5.1 Policies for Information Security

Resources available on hightable.io for implementing ISO 27001

Explanation of the difference between policies and process documentation

Policies should communicate actions without revealing internal operations

ISO 27001:2022 emphasizes high-level information security policy and topic-specific policies

Advantages of separating policies from processes for clarity and security

How to create policies efficiently using the ISO 27001 toolkit

Importance of writing policies based on business risk and controls

Assigning ownership and accountability for each policy

Process for getting policies approved within the organization

Distributing policies to relevant staff and ensuring accessibility

Need for staff acknowledgement of policies

Annual policy review and update process

Tips for communicating policies throughout the year

Importance of document markup and version control for policies

Auditor expectations regarding policy documentation

The ISO 27001 standard does not require a policy for every control

Final thoughts and call to action for the next video in the series

Transcripts

ISO 27001 Annex A 5.1 Policies for Information Security. We're going to start 

doing implementation videos now on the ISO 27001 Annex A Controls.  

This one is specifically looking at information security policies and 

resources to help you. You've got a load of resources on the 

hightable.io website that are going to help you out. There's a video on how to implement 

it. A step-by-step guide and how you deploy them. There's a blog that you can 

read that gives you a lot more detail but for now let me give you an 

introduction and a bit of a dive into information security policies for ISO 27001. 

So, ISO 27001 is founded on risks and risk management and also on policies. 

One of the things that I see out in the real world is a little bit of a 

misunderstanding around what policies are and what policies you need. Let's 

make a start with that. Policies are statements of what you do. They're 

documents that state what it is that you do for certain topics. They are not 

statements of how you do it. How you do it is covered in your process 

documentation and in your own individual process implementations. 

We separate out the process  of what you do from how 

you do it because by having a policy that states what you do you can 

communicate that to staff and to stakeholders. That clearly shows what it 

is that we're doing and we can share those externally under audit or with 

potential clients without compromising things like confidentiality or 

informationsecurity by not having specific project steps in there. Often 

what we see is policies are written in such a way that they include process 

steps. These may be bespoke to you. They may include people's names, they 

may include email addresses and telephone numbers and internal 

operations. We don't want to expose that internal operation externally and we 

don't want to confuse that necessarily internally so we separate 

those out and we have policies. When it comes to ISO 27001, the 2022 updated 

version of the standard calls out having a high level information security policy 

and then having topic specific policies. I think this is a fantastic move away 

from the old style of having one giant policy with everything in it. It 

allows us to communicate particular ISO 27001:2022 requirements, 

topics and specific topics to the relevant people without overly confusing people. 

We don't want to put a cryptography policy in something that's going to be 

shared with staff or cleaning staff or reception staff when it's just not 

relevant to them. Call centre staff don't necessarily need to know that. We're 

going to have a high level topic, uh sorry, a high level information security 

policy and then we're going to have topic specific policies under it. The 

quickest way to do this is clearly to download the ISO 27001 toolkit, the 

ultimate toolkit for ISO 27001 certification because I've written all 

of these for you. I've pre-populated them for you with what good looks like. Just a 

little bit of a rebrand and they're good to go. On the website you can actually 

download individual policies and there is a sub tool kit where you can just 

download the policy pack. That's going to be the quickest way to do it. If you 

don't want to do that be sure to head over to my YouTube channel or over to 

hightable.io where I go through in detail how you can create these policies in under 

five minutes each. I show you that and I give you a tutorial on that to satisfy 

the requirements of ISO 27001 Annex A 5.1 There's a couple of 

things that we're going to do. We're going to write our policies. Our policies 

are going to be based on the controls that we have and they're going to be 

based on our business risk. We will have done our risk identification and we 

will be seeking controls to mitigate those risks and we will be writing 

policies that back up those controls. They say what it is that we do as an 

organisation. We're going to write our policies. We're going to choose our 

policies. Policies that are specific to us. If we don't do software development, 

it is pointless having a software development policy. If we are fully 

remote, it is pointless having a physical security policy that covers the things 

that we don't have - CCTV, perimeter fences, things like that. There are lots of ways 

that we can go around that and sort of ways that we can address that but first 

of all what we're going to do is we're going to write our policies. We're going 

to choose our policies. The policies are going to be 

owned by somebody within the organisation. We want to assign ownership 

to these policies. Ownership and accountability. This is the person that's 

going to be ultimately responsible. We're going to assign that 

accountability. It doesn't necessarily mean that they do the work. In writing it 

and if you're an information security manager like me it's going to be you 

that's writing it no doubt but they're going to own it going forward and 

they're going to be responsible for it. Once we have those information security 

policies written and we've got our accountability assigned, we're going to 

get those policies approved. Using whatever internal approval mechanism 

that you've got you need to get those policies approved. If you're following my 

ISO 27001 certainty methodology and / or using the ISO 27001 toolkit then the 

way that we're going to get those approved is by sharing those at the 

information security management meeting, walking through those in the information 

security management meeting, seeking approval for those policies and then in 

the meeting minuting that approval. In the implementation guide where I talk 

you through that, I also say that before they go out for release, when they become 

the next release, it's good practice from my perspective to write in the Version 

Control the change that happened, which was policy was approved at management 

review meeting, on what such and such a dat. It just can show you and it's 

an instant visual identification of that policy is now live. Once the policy 

has been approved you then need to distribute that policy. The policy is 

going to go out to the people to whom it is relevant. In a small organisation it is 

usually the case that all policies will go to nearly everybody, but in larger 

organisations, as we said, because we have topic specific policies, then we're going 

to target them to relevant people. From an admin point of view, belts and braces, 

could you have a table of the teams that you've distributed which policies to or 

could you automate it in some way? Yeah you can. It's not a requirement of the 

standard. You work out how that distribution works best for you. Once 

we've communicated out those policies we're going to communicate where 

those policies are and those policies are going to be located in an area that 

is accessible to the people that we distribute them to. Makes common 

sense. They need to be readily and easily accessible. Then what we need is 

an acknowledgement from people that they have read, understood and accept those 

policies. There are many different ways to do that from getting an email back 

from everybody and keeping email copies, getting people to sign copies,  

distributing from your Learning Management Systems and using 

those and the sign off methodologies in those or you may have some other way of 

seeking that approval. But you need to get those policies approved. So, 

we've created our policies, we've assigned accountability to them, we've 

approved them, we've distributed them and we've seen that they have been approved. 

The next step that we have in that is that when anything changes, and at least 

annually, we're going to update our policies. Even if it is the case that all 

we do is put 'policy review no update' in our Version Control and increment the 

version number.Just to show that at least we've done a review of it on an 

annual basis and of course if something's changed we're going to put 

the change in there. For the doc dot increment for documentation and how to 

manage your documentation and your numbering check out one of the other 

videos that's coming up imminently. At that stage our policies 

are pretty much done. They're pretty much done. From a top tip 

perspective what I would suggest is that you communicate throughout the year on 

where those policies are. It isn't just the one and done.That yes you include 

them in your communication plan which there are other videos on and that you 

are regularly communicating those and pushing those policies out. We don't want 

to just communicate them once a year. We don't want to just get them approved 

once a year. Ideally we want to keep reinforcing that message and of course 

it's going to be part of your HR onboarding process. That people are 

made aware of policies when they join your organisation. What are some of the other 

top tips that I can say? Things that auditors like to look for is they like 

to look at very simple things, like document markup. They want evidences that 

the Version Control matches in the headers and footers and in the in the 

Version Control table they want to see that those policies were approved. They 

do want to see that those policies were distributed and that people have signed 

up and agreed to them. When it comes to which policies you need, the ISO 

27001 standard does not say you need a policy for every single control and that 

rightly makes common sense. When I created the ISO 27001 toolkit I did it to 

remove fluff and filler. There are loads of policies people regularly ask 

me do you have? Such and such a policy. And the answer is usually no because the 

standard doesn't require it and it adds no value. Yes we can generate policy 

after policy after policy but if the policy adds no value and has very little 

content and the standard only requires a process then we're going to rely solely 

on that process and that is absolutely fine. So my name is Stuart Barker. I am 

the ISO 27001 Ninja. Thanks for joining me on the first of the ISO 27001 Annex A videos. 

There's only 90 odd left to go, as we go deep dive on each of the Annex A 

Clauses but until the next video be sure to check out the blog that goes along 

with this video for much more detail. Until the next one, peas out.