Privacy Management Programme – what does one look like?

October 2021

The concept is nothing new, but the term Privacy Management Programme (PMP) has been flung into the spotlight by the UK Government’s plans to reform data laws.

In a nutshell, the Government plans to revise the current accountability framework, replacing existing obligations (some of which are mandatory) with a requirement to implement a PMP.

It’s argued the current legislative framework ‘may be generating a significant and disproportionate administrative burden’ because it sets out detailed requirements organisations need to satisfy in order to demonstrate compliance.

The idea is a new ‘risked-based accountability framework’ will be introduced, requiring organisations to implement a PMP, but allow flexibility to internally tailor the programme to suit the organisation’s specific processing activities.

What is a Privacy Management Programme?

A PMP is a structured framework which supports organisations to meet their legal compliance obligations, the expectations of customers and clients, fulfil privacy rights, mitigate the risks of a data breach – and so forth.

Such a programme should recognise the value in taking an all-encompassing, holistic approach to data protection and privacy; embedding data protection principles and the concept of privacy by design and default.

Core components of a Privacy Management Programme

There are a number of PMP approaches and frameworks in existence. The UK Government has not yet elaborated on what they would expect a PMP to look like.

This top-level summary is broadly based on the IAPP’s Privacy Programme Management approach.

  • Governance

Organisations should develop and implement a suitable framework of management practices which make sure data is used properly and in line with organisational aims, laws and best practice. This should include adopting a privacy by design and by default approach; ensuring appropriate measures are in place to prevent unnecessary risks.

  • Assessments

Achieving clear oversight of the data held and processed, including any suppliers used to support business activities. Developing risk assessment tools which help to identify privacy risks and manage them effectively (e.g. Privacy Impact Assessments / Data Protection Impact Assessments).

  • Record-keeping

Mapping and maintaining an inventory of where personal data is, its purpose, how it is used and who it’s shared with.

  • Policies

Developing and implementing clear policies and procedures to guide staff and give them clear instructions about how personal data should be collected, used, stored, shared, protected and so on.

  • Training and awareness

Making sure adequate and appropriate training is conducted to give staff the knowledge and understanding they need to protect and handle data lawfully and in line with organisational expectations in their day-to-day roles. Making sure people are aware of how their organisation expects them to behave.

  • Privacy rights

Putting in place appropriate procedures to effectively and efficiently fulfil individual privacy rights requests, such as the right of access, erasure or objection.

  • Protecting personal information

Crucial to any PMP is protecting personal information. Working in conjunction with information security, a data protection by design approach would be expected – a proactive rather than reactive approach.

  • Data incident planning

Creating and developing data incident procedures and plans. Having appropriate methods to assess risk and potential impact, as well as understanding breach notification requirements.

  • Monitoring and auditing

Last, but by no means least no PMP would be complete without a methodology for tracking and benchmarking the programme’s performance.

What might change?

To many who’ve endeavoured to comply with the GDPR, all of the above will sound very familiar.

So, the Government isn’t proposing we do away with all the hard work already done. It’s planning a relaxation to some of the mandatory requirements; giving organisations more flexibility and control over how they implement certain elements of their programme.

On the one hand, this could be seen as a welcome move away from a ‘one-size fits all’ approach under UK GDPR, giving organisations more flexibility around how implement their privacy programmes to achieve desired outcomes.

On the other hand, there are fears the removal of mandatory requirements will lead to a watering down of the fundamental principle of accountability (a principle significantly bolstered under GDPR).

UK data regime change consultation: 12 highlights

September 2021

The Government’s consultation on UK data protection reform contains a number of sensible proposals to ease the burden on business. There are also a few surprises likely to raise eyebrows in Brussels. The headlines are:

  • The UK is not about to become the ‘Wild West’ for data, as some may have feared
  • Changes to both UK GDPR and the UK’s Privacy and Electronic Communications Regulations (PECR) look likely
  • A probable relaxation of several areas of UK GDPR, with a focus on outcomes rather than prescribed processes
  • Plans to increase fines under PECR to match those under GDPR, a clear warning to those flagrantly disregarding marketing rules
  • The consultation is a ‘direction of travel’ – nothing’s carved in stone. It’s business as usual for now

The Government’s overall aim is to drive economic growth and innovation and strengthen public trust in use of data.

The way they want to achieve this is to alleviate some of the more prescriptive GDPR obligations on business, whilst retaining a robust data protection regime built largely on existing laws.

This approach is in keeping with the UK’s common law tradition, also used in Australia, New Zealand, Jamaica, Pakistan and Singapore (to name a few), as opposed to the statute law system used across Europe. Common law is viewed by its proponents as more flexible. It’s also why legal proceedings tend to move more quickly in UK courts than those in the EU.

It’s clear the UK Government hopes any changes will be compatible with EU equivalency, enabling the UK to retain adequacy.

Data regime proposals 12 highlights

1. Accountability & Privacy Management Programmes (PMPs)

Changes to the accountability framework are proposed, with businesses expected to have a Privacy Management Programme in place. This approach to accountability is long-established in countries such as Australia, Canada and Singapore.

It’s argued this would allow organisations to implement a risk-based privacy programme based on the volume and sensitivity of personal data they handle, and the types of activities they’re involved in.

By doing this, the proposal seeks to do away with some of the accountability obligations under the current UK GDPR, which may be considered to be more burdensome.

Organisations will still need to know where their data is, what its used for, apply lawful bases, implement robust security measures, manage suppliers, assess privacy risks and fulfil privacy rights. But there could be more flexibility and control over how you achieve this.

This doesn’t mean ripping up all the hard work you’ve done to comply with GDPR.

When the dust has settled, many organisations may choose to stick with the tried and tested framework they’ve already established. Others may jump on the opportunity to adapt their approach.

And let’s not forget, UK businesses operating in Europe will still be governed by EU GDPR.

2. No mandatory Data Protection Officers

The consultation proposes removing the mandatory requirement to appoint a DPO.

Under GDPR, a DPO must be appointed by public authorities – and in the commercial sector – if organisations meet specific criteria. It also sets out requirements and responsibilities for the role.

It’s proposed the requirement for a DPO is replaced with a requirement to designate a suitable individual (or individuals) responsible for overseeing compliance. However, the new law wouldn’t lay down specific requirements & obligations for this role.

3. No mandatory requirement for Data Protection Impact Assessments 

Currently, GDPR makes a DPIA mandatory for high-risk activities. It also sets out core elements such an assessment must include.

Furthermore, it requires supervisory authorities to establish a list of processing operations which definitely require a DPIA.  This led authorities, including the UK’s ICO, to dutifully publish lists of where DPIAs would be considered mandatory, as well as best practice.

The Government is proposing removing this mandatory requirement, although this won’t mean throwing out screening questionnaires and DPIA templates, which are often very useful.

The onus would be on organisations to take a proportionate and risk-based decision on when they consider it appropriate to carry out impact assessments and how they go about this.

4. More flexible record keeping

Completing and maintaining up-to-date records, known as Records of Processing Activities (RoPA) has been one of the more onerous aspects of GDPR.

Again, current law and guidance is prescriptive about records keeping requirements – although small and medium sized organisations (with less than 250 employees) are exempt from this.

It’s proposed a more flexible model for record keeping is introduced.

Maintaining a central record of what personal data you hold, what it’s used for, where it’s stored and who it’s shared with is a sensible and valuable asset for any organisation. Many feel such records are vital to effective data risk management.

So again, you don’t need to rip up your current ROPA, but you may soon be allowed to adapt your record keeping to suit your business and perhaps make your records easier to maintain.

5. Data breach notification threshold changes

It’s clear GDPR has led to data protection authorities being inundated with data breach reports. The ICO, for one, has highlighted a substantial amount of over-reporting.

This isn’t surprising when there’s a legal obligation for organisations to report a personal breach if it is likely to represent a ‘risk’ to individuals.

Its proposed organisations would only need to report a personal data breach where the risk to the individual is ‘material’.  The ICO would be encouraged to produce clear guidance and examples of what would be ‘non-material’ risk, and what would or would not be considered a reportable breach.

6. Data Subject Access Requests changes

The stated purpose of a subject access request is to give individuals access to a copy of their personal data so they can ‘be aware and verify the lawfulness of processing’ (although many organisations might question if this is why some submit requests).

The consultation recognises the burden of responding to DSARs has on organisations, especially smaller businesses which often lack the resources to handle them.

The possibility of charging a nominal fee could be reintroduced. It’s also proposed the threshold for judging when a request may be vexatious / manifestly unfounded is amended.

7. Cookies

Headlines surrounding UK data reform usually focus on ending the barrage of cookie pop-ups. The consultation proposes two main options:

  • Permitting organisations to use analytics cookies and similar technologies without the user’s consent. In other words, treating them in the same way as ‘strictly necessary’ cookies. It’s worth noting that this proposal is included in the most recent EU ePrivacy draft. (It’s accepted further safeguards would be required to ensure this had a negligible impact on user privacy and any risk of harm. It would also not absolve organisations from providing clear and comprehensive information about cookies and similar technologies).


  • Permitting organisations to store information on, or collect information from, a user’s device without their consent for other limited purposes. An example given is that this could include processing necessary for the legitimate interests of controllers where the impact on privacy is likely to be minimal.

The Government says it is keen to hear feedback on the most appropriate approach.

8. Legitimate Interests

There’s a proposal to create an exhaustive list of legitimate interests which organisations could rely on without needing to conduct the balancing test, i.e. no Legitimate Interest Assessment (LIA) required.

The following are some of the examples given:

  • ensuring bias monitoring, detection and correction in AI systems
  • statutory public communications and public health & safety messages by non-public bodies
  • network security
  • internal research and development projects

Where an activity is not on the list, we’re assuming assessments using the current 3-step test would still be needed.

9. Extended use of the ‘soft opt-in’

PECR currently permits email and SMS marketing messages where consent has been given, or for existing customers only, when the soft opt-in requirements are met.

This exemption to consent for existing customers is only currently available to commercial organisations. It’s proposed this could be extended to other organisations such as political parties and charities.

This could be great news for charities, but could it lead to a deluge of unwanted messages from political parties?

10. Research purposes

The Government wants to simplify the use of personal data for research, with a specific focus on scientific research.

Considerations include establishing new lawful grounds for research (subject to ‘suitable safeguards’) and incorporating a clear definition of ‘scientific research’.

11. Artificial intelligence

It’s proposed certain automated decision-making should be permitted without human oversight.

GDPR prohibits this unless necessary for a contract with an individual, authorised by law or based on explicit consent. The consultation suggests Article 22 is scrapped.

The aim is to ‘deliver more agile, effective and efficient public services and further strengthen the UK’s position as a science and technology superpower’.

It’s hoped this can be achieved by developing a safe regulatory space for responsible AI development, testing and training which allows greater freedom to experiment.

In the consultation press release, an AI partnership between Moorfields Eye Hospital and the University College London Institute of Ophthalmology is highlighted.  Researchers have trained machine-learning technology to identify signs of eye disease, which is more successful than using clinicians.

This is cited as a clear example of the type of data use which should be encouraged, not hindered by law.

12. Reform of the ICO

The Government wants to assert greater control over the UK’s data protection regulator, the Information Commissioner’s Office.

They propose to introduce a new, statutory framework to set out the ICO’s strategic objectives and duties and a power for the Secretary of State for DCMS to prepare a statement of strategic priorities to inform how the ICO sets its own regulatory priorities.

This would will bring the ICO into line with other UK regulators such as Ofcom, Ofwat and Ofgem.

The proposals also include introducing a new overarching objective for the ICO, in addition to its other functions, tasks and duties with two key elements:

  • Upholding data rights and safeguard personal data from misuse
  • Encouraging trustworthy and responsible data use, to uphold the public’s trust and confidence in use of personal data


Yes, a shake-up of UK data laws and enforcement is on the horizon, but the final outcome remains unknown, and a healthy debate will surely follow.

The consultation closes on 19th November 2021, and there will undoubtedly be some time before any changes become law.

For the time being its business as usual, but this document gives us a clear idea of what the future might look like.

Meanwhile, the EU will be keeping a very close eye on developments, and it’s possible the UK could be deemed to be going a step to far – it’s easy to see EC adequacy decisions being held over the UK Government like the Sword of Damocles.

The UK Government’s objective is to give organisations more control and flexibility around data protection management within a less burdensome regime, which supports the data economy and drives innovation.

In some ways, it could even be seen as a move towards giving organisations who don’t take data protection seriously more rope to hang themselves with.

The full consultation document is worth a read and can be found HERE.

Simon Blanchard, Phil Donn & Julia Porter – September 2021

Consent: Getting it right!

March 2021

Are you suffering from consent confusion? When must we rely on it? When is it not a good idea? And what must we do to make sure our consent is valid?

Here’s a short refresher to dispel the myths and a quick ‘consent checklist’ to make sure you are ticking all the right boxes!

For starters, one of the biggest myths surrounding GDPR (fuelled by news stories back in 2018) is that we need consent do almost anything with people’s personal data.

Simply not true.

Consent is one lawful basis, there are others

Consent is just one of six lawful basis. They are all equal, no one basis is better than another and you need to pick the right one for what you are doing.

Yes, sometimes consent is required by law for certain activities, but for many others a different lawful basis may be more appropriate.

But you do need to pick one. Data protection law across the EU and UK requires us have a lawful basis for processing personal data.

(By processing we mean doing anything with people’s personal information – from collecting, storing, sharing and even the action of deleting it).

GDPR raised the bar on what constitutes valid consent

GDPR defines consent and says it must be, “freely given, specific, informed and unambiguous” and  must be given by a “clear affirmative action by the data subject”.

This means you need to clearly tell people what they are consenting to and they need to take an action to give their consent. And consent shouldn’t be bundled up with providing another service or with T&Cs.

Just to be clear, the rules for consent under UK GDPR as the same as for EU GDPR. (See UK data protection and ePrivacy law post-Brexit).

When is consent the right lawful basis?

Consent is most appropriate to use when you can offer people a clear choice and give them control over how you use their data. If you can’t do this, you should look to rely on another lawful basis.

When is consent legally required?

There are some circumstances when the law tells us we must gain consent. Let’s take a look…

1. Marketing

In specific situations you need consent to send marketing emails or SMS messages under the UK’s Privacy and Electronic Communications Regulations (PECR).

This is where things can get a bit nuanced. Consent is not always legally required for all marketing emails/SMS. There are choices you can make.

For example, there’s a specific exemption for existing customers (known as the ‘soft opt-in’) and more relaxed rules for business-to-business marketing. For more detail see Understanding email marketing rules.

There are also circumstances in which you will need consent for telemarketing calls. See the ICO’s Guide to PECR.

2. Cookies

You need consent to place cookies or other online tracking methods on people’s devices (unless those cookies are ‘strictly necessary’). Or to install apps or software on people’s devices.

The ICO has confirmed such consent needs to meet the UK GDPR standard, and that cookies used for analytics, performance or marketing are NOT strictly necessary. See the ICO’s cookie guidance.

3. Special category data

If you are intending to handle special category data, for example health data on individuals, you may need to seek explicit consent to make sure this is lawful. This is unless you can rely on another specific legal condition.

GDPR requires you to have a lawful basis for processing special category data PLUS a specific condition under Article 9.

Special category data is information relating to someone’s health, race, ethnicity, political opinions, religious beliefs, trade union membership, sex life, sexual orientation and covers genetic and biometric data.

A word of caution here, if you’re using special category data for direct marketing or profiling purposes, you’ll need explicit consent.

4. If no other lawful basis applies

As you must have a lawful basis for each processing activity you undertake, if no other lawful basis obviously applies, you will need to obtain consent. Here are a couple of examples:

  • If someone would not expect you to be sharing their data with another organisation, it’s likely you would need to collect their consent to do so.
  • If you are planning to use someone’s data for a completely different purpose, which you didn’t tell them about when you collected their data, you are highly likely to need to collect their consent unless another lawful basis applies (e.g. its needed to meet a legal obligation).

Consent checklist

Consent checklist

You also need to consider other factors, such as if you are requesting consent for another organisation it must be separate and they should be named. Also consent doesn’t last for ever and should be refreshed (especially if anything changes).

If you offer online services which are likely to be accessed by children, you also need to consider whether you will need to seek parental consent and/or implement age verification measures. (Also see Children’s Code – deadline for conforming looms)

When is consent not a good option?

Consent will clearly not be the best approach if you will struggle to meet the requirements.

You should be careful about using consent where there’s likely to be an imbalance of power. In other words, where people might feel they have to give their consent.

This makes consent tricky if used by a business for purposes relating to their employees. Perhaps staff may feel a degree of pressure to give their consent, or feel they will be penalised in some way or treated differently if they refuse.

Saying this, sometimes there seems little option but to rely on an employee’s consent. I know a number of organisations using explicit consent for their diversity monitoring, which clearly entails special category data.

Consent isn’t easy

Collecting valid consent and meeting all the requirements may feel like a bit of a minefield. It does mean you need to take careful decisions. It’s worth double checking what risks may be lurking.

However, it is worth getting right, in the words of the ICO, “Genuine consent should put individuals in charge, build trust and engagement, and enhance your reputation.”

A final word of caution; be careful not to try and shoe-horn your activities into another lawful basis (such as legitimate interests), when consent really would be the most appropriate approach.


Data protection team over-stretched? Find out how we can help with our flexible no-nonsense Privacy Manager Service.

Getting your Supplier Contracts Right

A Guide to Controller-Processor contracts 

The GDPR sets out strict requirements for when an organisation decides to utilise the services of another company to process personal data. The most important aspect to establish first is whether you are both acting as controllers of the personal data being processed or whether the service provider is purely acting as a processor, acting at all times under instruction of the controller.

What is a controller?

A controller is person, or more commonly an organisation, which controls the ‘means and purposes of processing’. The controller makes the decisions about how this personal data is collected, used, stored, transferred, kept secure, destroyed etc. and among other matters is responsible for fulfilling individual rights requests, such as Subject Access Requests.

What is a processor?

To be recognised as a processor, a person or organisation, must processes personal data on behalf of a controller and not use this data for their own purposes. For example, a processor may be an external company utilised to provide payroll, printing, marketing or website services.

However, if an organisation determines the ‘means and purposes of processing’, i.e. uses the personal data for their own purposes, they become a controller. For example, if a marketing service provider uses the personal data it’s provided for its own internal analysis/profiling (which is not solely produced for the controller) it’s likely to be considered a controller for this activity.

It is worth noting that processors may be those who are offering hosted or cloud based services, which although not EU located are clearly caught by GDPR.

Establishing the relationship

It has proved very challenging for many organisations to clearly establish whether companies are acting as processors or controllers, with some organisations insisting they are a processor when actually they may be a controller. However, it is crucial for this to be established if you wish to ensure these relationships are compliant.

Where controllers are sharing personal data with another controller, this may under a joint-controller relationship or as separate autonomous controllers. In both circumstances, controllers have a duty to meet their data protection obligations as controllers. Therefore if they that act as joint controllers, they will have shared obligations.

What GDPR changed for Controller-Processor relationships

Prior to the GDPR, the accountability for compliance rested almost entirely with the controller, who was liable if things went wrong. Now, under the GDPR, the controller and processor could both be held accountable for compliance with the Regulation, and for compensating any damage (material or non-material) suffered by EU data subjects.

A controller or processor would only be exempted shall if they can prove they are ‘not in any way responsible’. And if the controller goes out of business, the processor carries the full burden.

Processors also have their own accountabilities, such as being responsible for their sub-processors, data transfers, staff training, fulfilling record of processing requirements (where necessary) and assisting the controller.

What does GDPR require for Controller-Processor agreements?

Article 28 sets out specific requirements for when a Controller utilises the services of a processor. Just to reiterate, Article 28 applies when the supplier/vendor is:

  • processing personal data on behalf of the controller (i.e. processing the controller’s own data)
  • under the instruction of the Controller
  • NOT using the controller’s personal data for its own purposes.

The law makes it very clear that this arrangement must be covered by a binding agreement (i.e. a live contract) and there are specific provisions that must be included in this agreement in order to comply with GDPR Article 28. Prior to GDPR written contracts were required, but GDPR requires more specific detail.

Core GDPR Contractual Requirements

1. Technical and Organisational Measures (TOMs)

The Controller must only use processors who have provided sufficient guarantees to implement appropriate technical and organisational measures to meet the requirements of GDPR and ensure the protection of data subjects’ rights.

It is therefore strongly advisable that organisations, as part of their due diligence process, conduct an information security impact assessment of any potential new processor and to document the outcomes. The aim of this is to provide assurance to the controller that personal data will be properly protected both in transit and when at rest in the processors’ systems. It is advisable to include reference to necessary security measures implemented by the processor in any contract, which may include for instance any requirement for encryption, access controls, and so on.

Controllers should also look for assurance by the processor on aspects such as adequate training of the staff handling their personal data and that access to data is restricted to those that require it to provide the service.

2. Appointment of sub-processors

The processor must not engage another processor (often referred to as ‘sub-processor’) to conduct processing of the controller’s personal data without the specific or general written authorisation of the controller.

Furthermore, the processor needs to inform the controller of any intended material changes concerning additional/replacement sub processors as the controller must be given the opportunity to object to such changes.

A contract should therefore provide details of any sub-processors which will be used to handle the controller’s data. Updates should be provided when this list changes.

Under the law processors need to be aware they are accountable and liable for the actions of their sub-processors. Article 28(4) specifically states that the same obligations as set out in the contract between the controller and processor shall be imposed on another processor by way of contract (or other legal act).

Where a sub-processor fails to fulfil its data protection obligations, the initial processor will be fully liable to the controller for the performance of the sub-processor’s obligations. Processors are therefore responsible to conducting due diligence of any sub-processors they use.

3. Further contractual requirements

A contract (or other legal act) between a controller and processor must set out the following:

  • Types of personal data the processor will be processing on behalf of the controller (e.g. name, email address, telephone number, bank account number, date of birth – including any special category data)
  • Categories of data subject (e.g. employees, patients, customers, students, minors)
  • Nature and purpose of processing
  • Duration of processing (i.e. the term of the contract)
  • Obligations and rights of the controller

Article 28 continues to provide other specific details that must be covered in a contract.

a) Rights and duties of each party (e.g. the processors commitment not to use the controller’s personal data for any other purpose than for providing the agreed service).

b) Instructions from the controller – The agreement should include details of what the processor is permitted to do with the personal data it is provided. In practice, this may often be set out by the supplier (processor), but the controller should check and agree that these accurately represent their instructions.

c) International transfers – If relevant, the agreement should include details and provisions for any transfer of personal data to a third country (i.e. outside the EEA) whether this be to the processor itself or any sub-processors used. Post-Brexit this will become a key aspect of contracts as the UK itself would become a third country.

d) Duty of confidentiality – There must be a confidentiality clause which commits the processor to ensuring that people who are authorised to access the controller’s personal data have committed themselves to a duty of confidentiality or are under a statutory obligation of confidentiality.

e) Data subject’s rights – the processor must commit to assist the controller, where applicable, with the fulfilment of data subject’s rights, such as Subject Access Request, the right to erasure, the right to object to processing, etc.

f) Assistance with controller’s compliance – the agreement should set out that, as and when required, the processor will assist the controller with:

i. Security of processing
ii. Notification of any Data breaches
iii. Conducting a Data Protection Impact Assessments (DPIA), should this be required

g) Return or destruction of the data – the agreement should stipulate what happens to the controller’s personal data at the end of the term of the contract. The law states that at the choice of the controller all personal data must be returned or destroyed. If the controller’s choice is for the data to be destroyed, it would be advisable to ensure that a contract stipulates that a data destruction certificate will be provided.

h) Audits and inspections – the agreement should set out that the processor agrees to make available all information necessary to demonstrate compliance with Article 28 and will allow for, and contribute towards audits, including inspections, by the controller or an authorised auditor.

What might be the consequences of getting data contracts wrong?

It’s crucial that contracts relating to data processing include all the appropriate terms to make sure that individuals are properly protected and also that the accountabilities and liabilities of each party are clearly agreed should a data breach or other infringement of data protection law occur.

As GDPR states:

‘Any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered.

Any controller involved in processing shall be liable for the damage caused by processing which infringes this Regulation. A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller.’ (Article 82)

It’s worth noting that a Ponemon Institute study revealed that 56% of companies experienced a 3rd-party breach in 2017, which represented an increase of 7% compared to previous year. In the event of a supplier suffering a breach, contractual arrangements are likely to come under scrutiny.