Maybe today you woke up and thought, “it’s about time I started thinking about certifying our company practices with an international standard,” and decided to go with ISO 270001.
ISO 270001 describes best practices and a systemic approach composed of people, processes, and technology. When applied properly, ISO 27001 helps you protect sensitive information in your organization and helps you manage this information by managing the risks associated with it.
One big part of ISO 27001 compliance is confidentiality or data privacy. In this article we will cover what you need to do to be privacy compliant for ISO.
In ISO 27001 there are several parts which describe processes which are linked to privacy:
There are other processes which more or less impact privacy in your organization, but it’s better to consider them together with information accessibility and integrity. Here I am talking about processes such as change management: for example, the organization of processes to defend your information systems which contain personal data from unauthorized changes.
The general aim of these processes when it comes to privacy is to ensure access to the information only for those which have the right to access it and to make sure the level of access is set correctly.
So now we need to consider who has access to, requests, and works with personal data:
In other words: your task is to make sure that anything that has access to information has been authorized to do so in line with your set IT and business processes.
So how do you do that?
The first thing you need to do is define what information you need to protect and classify it as:
Private information is things like personal data, commercial data, analytical data, strategy, financial data, etc.
Public information is all the data that, if made public, wouldn’t do your company any harm.
After you have classified your information, you will be able to split it into different types of data:
You need to appoint someone responsible for each type or several types. This could be a person, a department, or a team. Who is responsible for what depends on how your company has been built, who is working there and what their skills are. The situation may be completely novel for your company or be based on simple logic: the finance department is responsible for financial data; the analytical department is responsible for analytical data; etc.
Together with the people appointed responsible, define who, which data, and the extent to which access is granted. Record everything and fix the rules in place. This will be the starting point for the granting of any access or other rights to data in your company.
Based on the current business and IT processes in your company, you can arrange a system for how employees, customers, third parties, etc. have access or should have access to data and how much access they should have. You do so by setting roles and rights levels.
At this stage, you will probably see that there are a few places or people with excessive access rights to data. For example, you might find that interns in the infrastructure department have access to analytical reports which show financial data because the analytical platform doesn’t separate access rights and access to the platform is granted to anyone on your domain, LDAP, or Google sign-in.
After the first three steps, you will probably have a list of things you need to sort out. I wouldn’t exclude that your employees in infrastructure should have access to other employee’s passport data, but be ready to demonstrate exactly why this is a real need for your business operations to auditors when you are preparing to undergo personal data compliance certification.
As a result of this step you will create a matrix which demonstrates who should have access to different data.
An infrastructure map which shows the places, types, and channels through which you transfer data would be a great result for this stage. You should have a transparent understanding of what you store, where you store it, and why you have it, concerning:
In addition to understanding the processing and transferral:
Companies often have no idea where and what data they are transferring and processing because their infrastructure has been growing for several years or there are just so many processes with data that it is just difficult to keep track of it all. To resolve this, you will need to either:
Here it is worth mentioning that these solutions don’t do everything for you; they just make your job easier.
As a result, here you should have an understanding of what data you have where and who it is transferred to.
This is actually the simplest part of your job: setting who, what, and how much access you grant to data. You need to compare current employee, partner, third-party, etc. access and rights’ levels in your systems and applications with your access matrix as you defined in step 3. If you need to make changes to your access matrix at this stage, don’t be afraid to do so.
To complete this step, you will probably need to define roles and break them down into segments for specific access. To do so you will need to have completed steps 3 and 4 above.
The part where this step gets tricky is when you need to set similar levels for interactions between systems, services, components, clouds, etc.
Your customer support system has access to your CRM with full read access to customer order data. After you have defined that customer support shouldn’t see customer personal data, you altered the system view for customer support so that they can only see order status and customer IDs.
And this is where a problem crops up. To fit within the system you previously designed, you need to rewrite all of your systems or change the applications. This is either something that will come at great cost, will take you a lot of time, or simply be impossible.
Nothing, except in extremely rare cases, works out ideally. You’ll find that somewhere:
But this is where risk assessment and management comes in. Here you define the risks that could come about in the areas which don’t stack up to how you tried to set things up in theory.
Let’s take your employees from infrastructure in the example above which have access to employee passport data. And now let’s say that your ideal access settings are that only HR and accounting have access to this data as they are the only ones who need it for their work.
The risk here is the excessive access to employee personal data. The consequences of this risk are that data could be copied, altered, or deleted by unauthorized parties which in any case have access to this data (i.e. employees from infrastructure). This could lead to a data breach and/or changes/deletion of the data which would harm the data integrity.
As a result, we have a risk which impacts on the private nature of this information, in addition to the accessibility and integrity of the data (which is something we aren’t exploring in this article). Your task is to use the resources you have to cover or reduce the effects of this risk coming to fruition.
In our example, passport data is only stored in system X and this system has an audit set up that monitors the actions of all users. In the event that someone accesses the passport data the audit informs the data owner of this request/operation.
By putting an audit in place, you reduce the risk because the personal data can’t be quietly siphoned off or even touched without someone knowing about it (i.e. you partially reduce the risk by monitoring).
As a result of the different steps I explained above, you will have:
Now you’ve done all the legwork for your ISO 27001 privacy compliance, the final task now is to describe your internal controls and processes, according to the domains (sections in the standard) which will be assessed as part of your ISO 27001 audit. You then add the risk matrices to them to cover your deficiencies or lack of processes.
There’s no set way for describing your processes, but it’s worth keeping a few things in mind:
Take a look at the documentation for ISO 27002. It contains methods and recommendations for processes, plus the requirements for each domain across the standard.
Upon needing to do so, a manager creates a ticket in a tracking system to provide or change a certain set of access rights in the business systems for one of their subordinates. The ticket contains a request for one of the set system roles or describes a unique set of roles. The system owner agrees to the request and the system admins make the relevant changes to the access rights and close the ticket.
All the actions and processes are the same as what you need to do to ensure information integrity and accessibility. The thing is, you’re best to start with privacy because it will really simplify your work if you are aiming to become ISO 27001 certified.
Basically, by following the advice I have outlined above, you will not just lay down the foundations for privacy compliance as part of ISO 27001, but also improve your company’s security practices overall.