Who are interested parties?
Let’s start with understanding what interested parties are – they are nothing else but stakeholders, i.e., persons or organizations that can influence your information security, or persons or organizations that can be affected by your information security.
Typically, interested parties could include:
- shareholders/owners of the business
- government agencies/regulators
- emergency services (e.g., firefighters, police, ambulance, etc.)
- employee families
- suppliers and partners
… and, of course, anyone else that you consider important for your business.
How can you identify them?
Just ask your top executives, as well as heads of departments about who is important for their business, and then assess whether they could be interested in your information security. Also, chances are that your existing documentation (e.g., business plans) already contains such information.
Why are these interested parties important?
The identification of interested parties is not as important as the second step: identification of their requirements. Here’s why it is important: you need to know what all the interested parties want from you, and you need to figure out how to satisfy all these requirements in your ISMS.
For example, shareholders want the security of investment and a good return, clients want you to comply with security clauses in the contracts you signed with them, government agencies want you to comply with information security/business continuity laws and regulations, the media want quick and accurate news related to your incidents, etc. However, you have to be more specific than this – you have to specify exactly which laws and regulations, which security clauses exist in the contracts, and so on.
The best way to collect this information is to study their written requirements (legislation, contracts, etc.) and/or interview their representatives.
Once you have all this information, you will need to “configure” your information security to be compliant with your stakeholder expectations – this means you’ll have to identify the requirements before you start developing the details of your ISMS.
How is this done?
Good practice is to write a procedure that defines who is in charge of identifying all the interested parties and their legal, regulatory, contractual and other requirements and interests; such a procedure also needs to define who is in charge of updating this information and how often this is done.
If you work in a larger organization, such organizations usually have compliance departments or compliance officers – they would be the most natural department/person to do this kind of a job. If not, you can try to negotiate whether your legal department could do this job – if not them, then you, the information security coordinator, will have to do it yourself.
Once the requirements are clearly identified, you need to define who is in charge of complying with them – these responsibilities could be very different: IT department would be in charge of complying with technical requirements, human resources department for, e.g., confidentiality statements, information security coordinator with new policies and procedures, etc.
So, the point is – if you didn’t identify all these stakeholders and their requirements, you would be in danger of falling short of their expectations. And not satisfying your shareholders, or a government agency, could be quite dangerous.