ISO 27001 Needs and Expectations of Interested Parties

Home / ISO 27001 / ISO 27001 Needs and Expectations of Interested Parties

Introduction

Hi, I’m Stuart Barker, the ISO 27001 Ninja and this is going to be a deep dive into ISO 27001 Needs and Expectations of Interested Parties, looking at how you should implement it, what the requirements are, what an audit is going to look for, what the mistakes are, the common mistakes that people make.

Watch

So what are the needs and expectations of interested parties?

The needs and expectations of interested parties

If you’ve ever in traditional business projects done a stakeholder analysis, this is pretty much that. What we’re looking at is who might have an interest in our information security management system, who might have an interest in the outcomes of that management system and what are their interests? What is it that they want to see from it? What are their, you know, what are their goals? What are their objectives for it? Now there are a common list, there is a common list of interested parties and they come up time and time again.

Needs and Expectations of Interested Parties Template

It won’t come as a surprise to you to realise that I have a template, an ISO 27001 Context of Organisation Template that covers it, pre-populated, fully populated, pre-written and ready to go and it sets out what those needs and expectations are per interested party but if you were going to go through it you’re going to think about what the interested parties could be, both internally and externally to you. So let’s have a think, who could have an interest in our information security management system?

Examples Of Interested Parties

Well senior leadership, the board, our shareholders – they’re all going to have an interest in our management system. Whether or not it’s mitigating risk, whether or not it’s consuming resources, we’re going to have our staff are going to have an interest in it, our clients, our customers, potentially our competitors. So, there’s a whole list of people that are in there and as I say they’re already in that template for you but let’s have a little look at some of the detail that goes with it.

The Purpose Of ISO 27001 Needs And Expectations Of Interested Parties

What is the purpose of the ISO 27001 Needs And Expectations Of Interested Parties? The purpose is to make sure that you have considered people, their requirements and also how you’re going to address those requirements through information security. We have to tie our information security back to their requirements.

The Definition Of ISO 27001 Needs And Expectations Of Interested Parties

What is the definition? The the ISO 27001 standard defines ISO 27001 Clause 4.2 Needs And Expectations Of Interested Parties as – the organisation shall determine interested parties that are relevant to the information security management system, it shall determine the requirements of those interested parties and, this is relatively new, well it is new, which of these requirements will be addressed through the information security management system?

The Requirement Of ISO 27001 Needs And Expectations Of Interested Parties

ISO 27001 Needs And Expectations Of Interested Parties, the requirement, as you would expect, it is actually part of ISO 27001 clause 4 context of organisation. I have included it in the context of organisation document, it’s in that same document and it’s broken down into identifying internal and external issues as well as the needs of the interested parties.

How To Identify Interested Parties

When it comes to implementing that how would I identify interested parties? Well interested parties is just another way of saying stakeholders. We’ve already touched on that, right? So you could do a traditional stakeholder analysis. It really depends on what you’re trying to achieve from this. If you want to do more informally you could just get people in a room, you could brainstorm it, or you could take the context of organisation template that I’ve already done for you, download it, reuse it, follow the guide on how to tweak it and adapt it for you. Lots of different ways right?

How To Identify Requirements

Once we have identified who they are, how are we going to identify their requirements? We could ask them, you know, I mean, that’s the probably the most simplest way. We could ask them. Or again using the template I give you guides on that.

The Blog

Now there is a detailed blog – ISO 27001 Clause 4.2 Understanding The Needs And Expectations of Interested Parties  – Ultimate Certification Guide that goes along with this blog. In that blog I set out all of the details. I give you a table of all of the interested parties and all of their requirements and I show you exactly how to do it and I give you some examples.

Example Requirements

So the kind of requirements that people are going to have on an information security management system are that it meets our legal and regulatory requirements, that it avoids or contributes to the avoidance of a data breach, that it reduces our number of incidents, that it helps us to avoid Legal and Regulatory fines, that it gives us a commercial advantage for tenders and that it gives us a commercial advantage when it comes to sales. That it protects our company reputation, that it provides a work environment that is safe, that it allows people to conduct their role without undue bureaucracy, that it is providing us the ability to cooperate with external investigation if they come up in a timely and an efficient manner. So there are lots of different requirements and all of them are listed in the template.

Implementation Guide

The basic principle is do a stakeholder analysis, ask the  people in the room who might have an interest in this, identify what their interest may be, document that and then be able to tie that back to your information security management system. Now the approach I’m taking currently is not to write down how the management system directly reflects their needs because by its very existence it does. So what I would do come the audit is I would verbalise and I would provide a narrative around what it is that I have done and how that links directly back to those requirements.

What an auditor will check

What is an auditor going to look for? An auditor is going to look that you have documented the interested parties. If it isn’t written down it doesn’t exist. They’re going to look for how you address those requirements and again that you can link those requirements back to the Information Security Management System (ISMS). 

The Top 3 Mistakes People Make

What are the top three mistakes that people make?

The top three mistakes are that you know you have no evidence of anything happened. What do I mean by that? As a bare minimum you need that list of interested parties and requirements, you know if you can evidence that meetings were held and you’ve got meeting minutes where you discussed it, if you can provide ancillary documentation in terms of stakeholder analysis’s or whatever, it may be then all the good. You don’t have to do that, but that is going to add some additional weight when it comes to the audit. 

The number 2 mistake a top mistake might be that you didn’t link it to your ISMS, so you just chucked a bunch of requirements down but none of them are actually specific or addressed by the ISMS. It’s apparent if you take the list that I’ve got, you know reduction of legal and regulatory breaches and data breaches you can see and you can narrate and discuss exactly how that would tie back.

And the third mistake that people make it’s the common one that comes up time and time again your documentation is wrong, your housekeeping is wrong, so again I’m going to stop going through these, but for now as you’re following them in order you know Version Control, Version Control in the header or in the footer wherever you use the Version Control should all match up, there should be a Version Control table, there should be a last review date, there should be a document owner, there should be information documentation classification, all of that count towards housekeeping. Often times we see is wrong and that’s going to catch you and catch you out.

Who Is Responsible?

Who is responsible for ISO 27001 Needs And Expectations Of Interested Parties? As always senior leadership, it is a leadership top-down standard. The reality of the delivery of that is probably going to be the information security manager or worst case somebody in IT.

Conclusion

In summary – who is interested, who has a vested interest in the outcome of it, whose resources are you consuming, whose money are you spending, whose problems are you solving, list them, what are the requirements that they have, list them and then be able to tie that back to your information security management system.

So I’m Stuart Barker. I am the ISO 27001 Ninja. Be sure to subscribe to my ISO 27001 YouTube Channel, I am very needy, so subscribe to the channel. There is a wealth of information on there all of the information around ISO 27001 I provide you for free. I look forward to speaking to you and showing you the next clause in the series but for now peas out.

ISO 27001 QUICK LINKs

Organisational Controls - A5

ISO 27001 Annex A 5.1 Policies for information security

ISO 27001 Annex A 5.2 Information Security Roles and Responsibilities

ISO 27001 Annex A 5.3 Segregation of duties

ISO 27001 Annex A 5.4 Management responsibilities

ISO 27001 Annex A 5.5 Contact with authorities

ISO 27001 Annex A 5.6 Contact with special interest groups

ISO 27001 Annex A 5.7 Threat intelligence – new

ISO 27001 Annex A 5.8 Information security in project management

ISO 27001 Annex A 5.9 Inventory of information and other associated assets – change

ISO 27001 Annex A 5.10 Acceptable use of information and other associated assets – change

ISO 27001 Annex A 5.11 Return of assets

ISO 27001 Annex A 5.11 Return of assets

ISO 27001 Annex A 5.13 Labelling of information

ISO 27001 Annex A 5.14 Information transfer

ISO 27001 Annex A 5.15 Access control

ISO 27001 Annex A 5.16 Identity management

ISO 27001 Annex A 5.17 Authentication information – new

ISO 27001 Annex A 5.18 Access rights – change

ISO 27001 Annex A 5.19 Information security in supplier relationships

ISO 27001 Annex A 5.20 Addressing information security within supplier agreements

ISO 27001 Annex A 5.21 Managing information security in the ICT supply chain – new

ISO 27001 Annex A 5.22 Monitoring, review and change management of supplier services – change

ISO 27001 Annex A 5.23 Information security for use of cloud services – new

ISO 27001 Annex A 5.24 Information security incident management planning and preparation – change

ISO 27001 Annex A 5.25 Assessment and decision on information security events 

ISO 27001 Annex A 5.26 Response to information security incidents

ISO 27001 Annex A 5.27 Learning from information security incidents

ISO 27001 Annex A 5.28 Collection of evidence

ISO 27001 Annex A 5.29 Information security during disruption – change

ISO 27001 Annex A 5.31 Identification of legal, statutory, regulatory and contractual requirements

ISO 27001 Annex A 5.32 Intellectual property rights

ISO 27001 Annex A 5.33 Protection of records

ISO 27001 Annex A 5.34 Privacy and protection of PII

ISO 27001 Annex A 5.35 Independent review of information security

ISO 27001 Annex A 5.36 Compliance with policies and standards for information security

ISO 27001 Annex A 5.37 Documented operating procedures 

Technology Controls - A8

ISO 27001 Annex A 8.1 User Endpoint Devices

ISO 27001 Annex A 8.2 Privileged Access Rights

ISO 27001 Annex A 8.3 Information Access Restriction

ISO 27001 Annex A 8.4 Access To Source Code

ISO 27001 Annex A 8.5 Secure Authentication

ISO 27001 Annex A 8.6 Capacity Management

ISO 27001 Annex A 8.7 Protection Against Malware

ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities

ISO 27001 Annex A 8.9 Configuration Management 

ISO 27001 Annex A 8.10 Information Deletion

ISO 27001 Annex A 8.11 Data Masking

ISO 27001 Annex A 8.12 Data Leakage Prevention

ISO 27001 Annex A 8.13 Information Backup

ISO 27001 Annex A 8.14 Redundancy of Information Processing Facilities

ISO 27001 Annex A 8.15 Logging

ISO 27001 Annex A 8.16 Monitoring Activities

ISO 27001 Annex A 8.17 Clock Synchronisation

ISO 27001 Annex A 8.18 Use of Privileged Utility Programs

ISO 27001 Annex A 8.19 Installation of Software on Operational Systems

ISO 27001 Annex A 8.20 Network Security

ISO 27001 Annex A 8.21 Security of Network Services

ISO 27001 Annex A 8.22 Segregation of Networks

ISO 27001 Annex A 8.23 Web Filtering

ISO 27001 Annex A 8.24 Use of CryptographyISO27001 Annex A 8.25 Secure Development Life Cycle

ISO 27001 Annex A 8.26 Application Security Requirements

ISO 27001 Annex A 8.27 Secure Systems Architecture and Engineering Principles

ISO 27001 Annex A 8.28 Secure Coding

ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance

ISO 27001 Annex A 8.30 Outsourced Development

ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments

ISO 27001 Annex A 8.32 Change Management

ISO 27001 Annex A 8.33 Test Information

ISO 27001 Annex A 8.34 Protection of information systems during audit testing