Implementing ISO 27701 – Privacy for ISO 27001

When the GDPR came into force on the 25^th May 2018, a number of Articles referred to the creation of certification schemes that could be approved by Authorities, to make it easier for data subjects to understand whether an organisation had appropriate privacy controls. Implementing ISO 27701 looks like the easiest route currently to this goal.

ISO 27701 is the newly released ISO standard intended to allow this kind of Privacy certification, by tying it to the ISO 27001 Standard.

This marriage makes logical sense, as a large majority of the controls required for ensuring the privacy of data, are the same as ensuring the security of your data and infrastructure.

The downside however, is if you want to be Privacy Certified, you need to have ISO 27001 as well. If you have ISO 27001 certification already, the changes required should be relatively minimal and we intend to walk through them here.

The ISO 27701 standard makes reference to a PIMS: a Privacy Information Management System. This is in direct alignment with your ISMS (Information Security Management System). Running the two management systems as a single management system with augmented controls seems like the logical extension of ISO 27001 that is being implied by this new standard.

So what exactly do I need to change in my ISMS to make it ready for ISO 27701 certification?

The ISMS Manual

Currently your ISMS Manual describes how Information Security Governance works in your organisation, and how all of the Management System elements fit together. Now all you have to do is to bolt on Privacy. Easy! Right?

Implementing ISO 27701 effectively will depend largely on how you implemented Privacy Governance for the GDPR. If you have ended up with two separate structures, one for Information Security Risks and one for Privacy Risks, this is not the end of the World. Just describe it that way in the ISMS Manual.

One can argue that this kind of distributed governance is not optimal. It will result in Senior Management asking why they need to go to so many meetings. But as long as you have a coherent story for why it is the way it is, write this down in the ISMS Manual.

The Management commitment to Privacy is easier to confirm than for Information Security. With the GDPR, Privacy is a legal obligation rather than a “nice to have”. So what you are asking for here is for Management to commit to not breaking the law.

Your Risk Management really should be a single Methodology, even if Privacy hold their own Risk Register. Managing multiple Risk Registers is not a sin. Managing multiple Risk Methodologies is.

Make sure you can show that Information Security and Privacy are using the same Risk Methodology, so that when the Risks are raised through the Governance process, you will end up comparing apples with apples.

Ideally, one Risk Register that can be used in one Senior Risk Governance meeting is the way to go. This shows that you have thought about the Management and Governance efficiencies that naturally exist in a Privacy & Information Security marriage like this. The more joined-up you can make this Management System look, the better.

The Statement of Applicability

Your Statement of Applicability already has the flexibility to allow for additional controls to be implemented outside the standard 114 controls proposed in ISO 27002. Here we have to expand our Statement of Applicability to add Privacy controls into the Management System. ISO 27701 outlines additional controls that it believes should be considered as applicable controls. Check these carefully and if you think some can be dropped, make sure you explain why in the Statement of Applicability.

The new areas for the ISMS Manager to get to grips with, come directly from the GDPR and the explicit Privacy requirements that it requires. The underlying security controls will be very familiar, but some of the Privacy requirements of the GDPR will be new to ISMS Managers. A basic understanding of Privacy and a certification like CIPP/E will go a long way to educating an ISMS Manager in the dark arts of Managing Privacy Regulation.

Context of the Organisation

The ISO 27701 Standard is new, and it is to be expected that in some areas, a few corners will need to be chipped off to make it the ageless Global Standard the ISO 27001 has become. So the first area for some chipping, I propose is in this area.

The ISO 27701 Standard asks you to determine your role as a data controller or processor within an overall organisational context. This is slightly broken thinking, and hopefully will be changed in the future.

The reality is that an organisation is not a controller or a processor at this highest context level. It will be handling data in many different forms and is highly likely to be a controller for some data (e.g. its employees data) and a processor for other forms of data (e.g. a specific data processing task set by a client contractually).

The determination of whether you are a controller or a processor happens at a data processing level, not at an organisational context level. Leaving this to one side, let’s try to provide what I think the ISO 27701 Standard is angling for.

All you can do at an organisational context level, is state how your organisation will determine whether it is a controller or processor for any type of data it is required to handle.

This requires a few paragraphs to be added to your ISMS Manual. Articulate the logic the organisation will follow, such that when it is presented with the opportunity to handle and process data, it can consistently and systematically determine if it is handling that data as a controller or processor. This applies to the determination of the lawful basis of processing also.

External and Internal factors

In implementing ISO 27701, an organisation is required to determine external and internal factors that are relevant to its context. Whilst the ISO 27701 Standard asks for additional factors relevant to PII, the reality is that there are no new factors to consider from what is already in place within your ISMS.

All that is required is to add the appropriate Privacy legislation that you need to be compliant to. Your ISMS should already state that you will comply with any applicable legislation that affects the organisations context globally. Likewise, any contractual requirements placed upon the organisation are already an external factor that affects your ISMS.

The most important element of External and Internal factors is to show how you can keep track of relevant changes to legislation and contractual commitments. This is no different when implementing ISO 27701 than it is for the implementation of the ISO 27001 Standard.

Contractual commitments affecting the ISMS should be based on a standard contractual template. By applying a standard contract template to every client and third-party negotiation, you know and can support your baseline.

Where changes are negotiated that may impact the ISMS, there should be a Policy requirement that states that changes to contracts that may need additional Security or Privacy controls must go through some form of Governance process to capture them within the ISMS.

Legislative changes can be covered by having some form of General Council support either internally or externally, which can describe the legislative changes and the likely impact on the Organisational context. These can then be transposed into additional controls within the ISMS as required.

Don’t forget to record all of these actions within the ISMS, as they will form part of the ISMS Governance process.

The process flow for a legislative change then becomes:

• Identify the legislative change
• Risk Assess the change within the ISMS
• Identify potential additional controls as required.
• Raise within ISMS Governance process

Needs and Expectations of Interested Parties

Within the ISO 27701 standard, this only gets one paragraph with 3 notes. There is a lot that sits in this section that is not mentioned in the ISO 27701 Standard.

This section should explain how the ISMS meets the needs and expectations of Interested Parties for Privacy. From a Privacy perspective, there are three key groups.

The Data Subject

Whether you are a controller or a processor, the Data Subject has needs and expectations on what you will do with the data they will give you.

Your Data Controller

If you are the Data Processor, the Data Controller may have specific needs that are required to be addressed. Most of these will be explicit contractually.

The Regulator

Your Data Regulator also has needs and expectations on what you will do with the data you receive. The GDPR is quite prescriptive on what a Regulator expects a Data Controller and a Data Processor to provide as evidence of compliance.

Data Subject Access Requests (DSARs)

The Data Subject is granted a number of fundamental rights under the GDPR, which we can simply transcribe here as “Needs”.

This section of your ISMS Manual should set out at a high level, how each of those DSARs will be handled, essentially to prove that they have been considered and accounted for.

This can be as simple as stating that the Data Subjects Rights under the GDPR are addressed by a Data Subject Access Requests Process, assuming that you have one of these handy. If not, I would highly recommend creating one, both for your ISMS auditor and for your Data Regulator.

The Record of Processing

There are specific documents that the Data Regulator requires you to create as either a data controller or a data processor, that need to be described at a high level in this section of your ISMS Manual. One such document is your Record of Processing, which records each type of data processing being undertaken and what your legal basis is for doing that processing, amongst a number of other properties .

Your Legal Basis of Processing Assessment is also a process that your regulator would wish that you record. The high-level logical determination for how you decide on the Legal Basis of Processing for any type of processing you may receive. The high-level statement in the ISMS Manual may be simply to point to another formal process document or your DPIA (Data Protection Impact Assessment), whichever has that detail embedded in it.

Scope of the ISMS

This is a one-line statement in the standard that again undersells the importance of this section.

It is important to note when implementing ISO 27701, that if your current ISMS scope does not cover all of your areas of data processing, then simply bolting on an ISO 27701 extension will only cover the Privacy of the data within the current scope.

If you require a Privacy Certification that covers all of your data processing, then your ISMS must also have that scope. The scope must be identical. It is difficult to see how a Privacy Certification can means anything sensible if the scope does not cover all of the data processing activities undertaken.

Clearly if you are an Outsourcer, and your Client requires you to achieve ISO 27001 certification for the entire scope of the outsourced activities handed over to you, then implementing ISO 27701 to that scope does make sense.

Leadership

The ISO 27701 Standard assumes that this area is covered by the existing controls laid out in ISO 27001. But be careful. If you are a large organisation, Information Security and Privacy may not have common management structures until they meet at Board level.

Information Security may go up through a CISO to a CIO, whilst Privacy may go up through your General Council. And never the twain shall meet.

If there is no common intermediate leadership structure, you will have to articulate both leadership structures in the ISMS Manual. In other words, you will have to describe how decisions are made within the Information Security part of the business, as well as describing how Privacy decisions are made in the Privacy part of the business.

Your ISMS Manual may have two parts under Leadership: one describing Information Security Leadership, roles and responsibilities; and one describing Privacy Leadership, roles and responsibilities.

The next part in this series will pick up with Planning under ISO 27701 and ISO 27001.