Feb 2, 2022
9 min read

Privacy compliance for ISO: what you need to do

One big part of ISO 27001 compliance is confidentiality or data privacy. Read on to discover what you need to do to be privacy compliant.

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:

  • Access management processes (granting, blocking, reassessing of rights, etc.)
  • Role management and delineation of responsibilities for processes (including access rights and role reassessments)
  • Authentication and authorization processes
  • Information classification processes
  • Information storage
  • Information transfers
  • Use of confidential information

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:

  • Employees (salaried, freelance, etc.)
  • Customers (users of your product)
  • Third parties (partners, merchants, contractors, etc.)
  • Internal systems and applications (in-house solutions, scripts, code, etc.)
  • External systems and applications (off-the-shelf or custom-made solutions from third party providers)
  • Network and server software and their environment (load balancers, clouds, databases, etc.)

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?

1. Classify information

The first thing you need to do is define what information you need to protect and classify it as:

  • Private
  • Public

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.

2. Define data owners

After you have classified your information, you will be able to split it into different types of data:

  • Financial
  • Payment
  • Analytical
  • Personal
  • etc.

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.

3. Define who should and has access to this data

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.

4. Define data processing and storage locations

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:

  • Employee personal data in HR systems
  • Client data in your CRM
  • Financial and analytical reports in analytical platforms, etc.

In addition to understanding the processing and transferral:

  • From your CRM to your logistic system to form customer orders
  • From your analytical platform to your ERP for business planning activities, etc.

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:

  • Analyze your processes and create a data transfer map
  • Use third-party solutions to define traffic and the data within it or services that record events and create a data-flow map
  • Already have everything recorded and documented in the right format and kept updated

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.

5. Define access and rights

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.

For example

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.

6. Assess and manage risks

Nothing, except in extremely rare cases, works out ideally. You’ll find that somewhere:

  • Processes don’t allow you to limit data access
  • Systems don’t support your segmentation for the required access rights’ levels
  • etc.

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.

For example

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.

How to reduce the risk

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).

Learn other ways to reduce risks for your information assets

Wrapping up the above

As a result of the different steps I explained above, you will have:

  • Classified and segmented of data types for personal data
  • Defined the list of who has access to data and how much access (in a data access matrix)
  • Defined the list of systems, applications, etc. which store data
  • Created a data rights and access matrix implemented within your systems and applications
  • Created an infrastructure map with information about storage locations, channels which transfer data, etc.
  • Compiled a list of risk or a matrix which outlines them

Final step

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:

  • Processes can be manual, automated, or semi-automated
  • Someone should be responsible for each process
  • Incoming and outgoing information or events need to be defined for processes
  • Processes should have a certain frequency and be trackable

Tip

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.

For example

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.

  • The incoming information here is the rights or role in the ticket
  • The process of giving access is manual or the frequency is upon request
  • The system owner and admins are listed as responsible
  • The process is tracked by the ticketing system

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.

Author
Alex
Alex is an expert in information security with more than 10 years of experience. Currently a CISO of a giant e-commerce marketplace with 400M+ users and with previous experience working as a consultant for Deloitte.

Receive helpful tips, practical content, and updates

Thank you! You have been successfully subscribed
Oops! Something went wrong while submitting the form.