Part 3 of the series looks at the applicable controls in ISO 27002 and the impact of Privacy on them. Click here to see the rest of the series.
Policies
The additional implementation guidance within ISO 27701 on this is slightly confused.
In ISO 27002 under A.5.1.1, it is a very clear requirement that you should have some Policies that are created and communicated to all that need them.
For some reason that is not currently apparent to me, after stating the obvious and saying you need to augment your existing control by adding some Privacy Policies, the ISO 27701 standard clause then carries on into contractual commitment territory, which has absolutely nothing to do with the original control. Contractual and legal/regulatory requirements is A.18 territory, not A.5.
Your Privacy Policy should contain all of the appropriate Privacy controls elements. Detailing only a few within A.5.1 guidance is confusing to the practitioner. The practitioner will assume that these areas are highlighted with some specific purpose in mind, maybe to highlight their importance over other areas. This is not the case here, and the rest of this guidance can be left to its appropriate place in the standard. Just for good measure, it also throws in roles and responsibilities, even though that should be covered by the next clause in A.6.1.
What this implementation guidance note for A.5.1.1 should say is that Privacy Policies should be created that cover the scope of the PIMS. Use the exact same wording as appears in ISO 27002 A.5.1.1 with “information security” replaced with “Privacy”. It is that simple.
The review of Policies clause can be applied unmodified if we accept that this clause now means the review of Policies in general (i.e. all of them, Information Security and Privacy), as per the control in A.5.1.2.
Organisation of Information Security
Under Roles and Responsibilities in A.6.1.1, the ISO 27701 Standard describes a Data Protection Officer role, with an implication that there may be more roles within the wider Privacy programme, but does not extend the guidance to these other possible roles.
Whilst the DPO role is covered by this guidance requirement, best practice would be to describe any other Privacy-based roles that have a specific responsibility for Privacy Protection within the organisation.
The note at the bottom of the guidance highlights that the DPO can be an outsourced role. This may lead to some confusion as the A.6.1 clause is titled “Internal Organisation”, but this seems genuinely the most appropriate place to put this role requirement.
Segregation of Duty
Whilst the original control guidance in A.6.1.2 is valid, it should be noted that care needs to be taken in the areas of Privacy where your Regulator is expecting a segregation of duty.
This is no longer becomes your own choice based on internal views. You should consider your Regulators guidance on this topic and comply accordingly.
The Data Protection Officer Role is there to represent the data subjects’ interests within the organisation. In some ways, it is very similar to an internal auditor role, where you are employed by the organisation, but your role is to hold the organisation to account.
Ensure that you highlight how this segregation of duty is embodied in a single role, and how this works within the organisation.
Other segregation of duty issues may arise with Subject Access Rights requests. Employee SAR requests may be dealt with by Privacy Staff who may personally know the employee making the request.
Describe how these kinds of issues will be handled to ensure the privacy rights of the data subject.
Contact with Authorities
The guidance in ISO 27701 rather glosses over the requirements for Privacy in this clause. Contact with the Data Regulator is really important to establish. One of the primary responsibilities of the DPO is to establish the appropriate interface with their Regulator, on behalf of their organisation and their Data Subjects.
Additional guidance should state that it is important to ensure that contact with the Data Regulator is effectively managed on behalf of the organisation and on behalf of Data Subjects.
Contact with Special Interest Groups
There is an area that is not covered by the clauses and controls currently, which needs to be raised and it needs to be slotted in somewhere. So I’m going to slot it in here.
The Privacy requirement is to support the rights of the Data Subject. Currently, there is no clause dedicated to “Contact with Data Subjects”.
For completeness, you should outline somewhere in your ISMS Manual, the high-level mechanisms that will be used to enable the contact with Data Subjects. I suggest that this is the easiest clause to abuse for this need.
Likewise, there are specific Privacy Interest groups to note within your response to this clause.
Information Security in Project Management
Clearly this should be read as “Privacy in Project Management” for ISO 27701, and the current guidance of “you should have some” still stands.
The requirement here is to show how data minimisation and data anonymisation/ pseudonymisation are being considered during the project management lifecycle. Exactly the same requirement applies to the procurement or creation of software applications/solutions. This is A.14 territory and we will cover this later.
Mobile Device Policy
This clause in ISO 27001 this was all around managing the risks introduced by mobile devices. The additional guidance for 6.2.1 can be ignored as it adds nothing in terms of clarity and is actually more likely to confuse.
Additional guidance should state that you need to conduct a risk assessment on the use of mobile devices and within that risk assessment, take into account the Privacy risk to the organisation and to the Data Subject.
Teleworking
The ISO 27701 decides to stay quiet on Teleworking, and I think there is valuable guidance to be provided in this area. Another missed opportunity.
The organisation should consider the risk of a remote data loss that the organisation is a custodian of. Clearly a laptop can be encrypted such that a device being stolen becomes purely an asset loss, not a data loss.
However, we have to be careful of data availability. If that was the only copy of the data that has been lost, you do end up with a data loss due to lack of data availability.
You do need strict guidance on hard-copy data also. How it is stored and how it is transported and destroyed. You run the risk of an employee disposing of PII hard-copy into their home recycling, only to be collected by a dumpster-diver somewhere. This should all be detailed in your Acceptable Use Policy.
I can count on numerous fingers the times when I have been told the story of being handed paper for children to draw on while visiting friends or relations, only for the reverse of the paper to be some form of company printout.
Part 4 will pick up again with Human Resource Security.
