Chapter 16: Transitioning and Demonstrating Compliance – EU General Data Protection Regulation (GDPR): An Implementation and Compliance Guide


Organisations that already have processes in place to manage compliance with current data protection and privacy laws will need to make adjustments to ensure they are complying with the new requirements.

Assuming your current compliance programme is aligned with the Data Protection Directive (DPD), it should be relatively straightforward to compare your current established requirements against those of the GDPR. You should seek legal advice to ensure that you get a clear overview of what changes are appropriate to your specific circumstances.

If you already have a privacy compliance framework, transition may be somewhat simpler than it will for organisations that are currently managing DPD compliance on a more ad hoc basis. However, you should still define a process for transition and prepare to demonstrate your compliance with the Regulation.

Transition frameworks

Existing transition frameworks can be leveraged to manage the transition from meeting the requirements of the DPD to meeting those of the GDPR. The COBIT 4.1 transition model, as shown in Figure 13, is a particularly straightforward model for planning the transition.

Figure 13: The COBIT 4.1 transition model

In this model, each phase is represented by a question that can be answered incrementally. This enables the organisation to adjust its approach as it progresses through the change lifecycle and encounters new challenges or is presented with new information.

While the COBIT 4.1 model is normally cyclical and iterative, your transition does not need to be. If you have an existing privacy compliance framework, a single iteration of a change process, like COBIT 4.1, to make a broad change to the framework and its requirements should suffice. The updated framework should then be capable of managing compliance on an ongoing basis.

Every phase and iteration of the transition process above should generate reports of some kind. These outputs provide the basis for following stages. If you use the process iteratively, each complete cycle provides a report that can be reviewed separately or independently, as well as informing the next iteration.

Each iteration needn’t take long; how long will depend on the scale and complexity of the organisation. As in any large or important process, maintaining momentum and keeping people interested is critical, and taking too long to get from phase to phase can jeopardise the entire process. Given the potential severity of administrative fines associated with the GDPR, it’s especially important that the transition from DPD compliance to GDPR compliance is managed effectively; the target date by when you should want to have completed the transition to a new business as usual environment is, after all, 25 May 2018.

In COBIT 5, this lifecycle process becomes more detailed and clarifies its relationship with other areas of the business. It will be a useful reference if you need a tested and proven change management lifecycle to support your transition process.

Transition – understanding the changes from DPD to GDPR

While the DPD and its supporting case law and findings is a complex area of law, the GDPR as an instrument is itself large and complex, so a comprehensive, detailed statement of the differences between the two is more likely to emerge as a series of legal documents than from anywhere else. The key areas of change, though, are clear.

The GDPR introduces a number of new concepts beyond those contained in the DPD, as follows:

  • Scope – the geographic scope of data protection is extended to include controllers and processors outside the EU but who are providing services that involve collecting the data of EU citizens.
  • Accountability – the GDPR clarifies who is responsible for data protection and privacy at each stage of data processing. Processors now have a legally defined role in data processing.
  • Transparency – the GDPR introduces a set of requirements to ensure that processing is conducted in accordance with this principle.
  • Children’s data – the GDPR clarifies what constitutes children’s data and sets minimum standards for its processing. There is a stronger emphasis on protecting children’s data, and many organisations will need to change how they operate in order to comply with the Regulation.
  • Definition of personal data – the GDPR provides a clear definition of personal data – including biometric and genetic data – that did not previously exist. Furthermore, the range of ‘special categories of personal data’ contained within the GDPR is clearer and broader than that within the DPD.
  • Pseudonymisation – the GDPR presents pseudonymisation as a method of securing personal data. Given the emphasis placed on this, it’s safe to assume that the Commission considers it one of the better ways of protecting personal data.
  • Data breach reporting – the GDPR makes reporting requirements consistent across the EU, including much more specific requirements regarding who must be told what and by when.
  • Enhanced rights – the GDPR strengthens and broadens the rights of data subjects. The data subject now has considerable control over how their personal data is to be used.
  • European Data Protection Board – the GDPR establishes the Board as a central authority on data protection to oversee the application of the Regulation, ensure that it remains effective in protecting data subjects’ rights and enforce consistency across the Member States.

The eight privacy principles of the DPD have been reduced to six data protection principles in the GDPR. The two principles that have been removed relate to “data subjects’ rights” and “international transfers”, which are both topics that are covered by separate chapters in the Regulation, but should be considered as separate matters for compliance. For instance, complying with all of the six data protection principles should be designed, checked and enforced in one way, while ensuring that data subjects’ rights have not been infringed is managed by a second process and the manner in which personal data is transferred is managed by a third.

The GDPR also presents data subjects with two new rights: the right to data portability and the right to be forgotten. The right to data portability provides a mechanism for the free movement of data that is arguably in the best interests of the market.

The right to be forgotten had already been granted in some jurisdictions, and some interpretations of the DPD had already moved towards this, but the GDPR makes clear what controllers must do in response to requests for erasure of personal data, and the conditions under which they can refuse to do so.

Using policies to demonstrate compliance

The Regulation identifies a number of specific practices and documents that any organisation should be able to provide. Several of these refer specifically to “policies”, which can be used to demonstrate that your organisation has at least established its fundamental approach to privacy.


In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default.240

The “internal policies” here indicates that the organisation should have stated and consistent views on how to meet the Regulation’s requirements. While this recital is talking primarily about the principles of data protection by design and by default, the GDPR also describes a number of other policy positions that organisations need to establish.

For instance, in Article 4, the definition of binding corporate rules states that it “means personal data protection policies which are adhered to by a controller or processor”241. The Regulation also mentions policies in the following contexts:


Where proportionate in relation to processing activities, measures […] shall include the implementation of appropriate data protection policies by the controller.242


[The DPO will] monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data.243

The controller should develop an explicit (therefore documented) policy on the protection of personal data, which will be closely associated with the organisation’s compliance with the GDPR. Because of the relationship between policy and compliance, relevant DPOs should monitor the organisation’s compliance with the policy as part of ensuring compliance with all appropriate laws and regulations.

It should be no surprise that an auditable, formal data protection and privacy policy will also be of interest to potential partners and clients.

A privacy policy that is available to the public should be a primary consideration for ensuring that processing abides by the principles of the Regulation. A publicly-available policy supports transparency, allows customers and partners to assess it, and provides a clear statement that supervisory authorities and other regulators can assess the organisation against.

Article 13 of the Regulation lists what information should be provided within a privacy policy. This includes those details that should be provided whenever personal data is collected, such as the identity and contact details for the controller, any relevant DPO, whether the controller intends to transfer the personal data to a third country or international organisation, and so on244.

Your privacy policy should also provide additional information relating to fair and transparent processing, such as the retention period, the data subject’s rights (e.g. the rights to access, erasure and restriction of processing), the right to withdraw consent (where applicable), the right to lodge a complaint with a supervisory authority, and so on245.

Information about fair and transparent processing is supplemental and could vary considerably in detail depending on the specifics. You might need to refer to other documentation or, if the cases are simple enough, could be stated in general terms. For instance, the storage period for personal data could be described as “for the length of the contract with the data subject”.

Your privacy policy should be readily accessible from the same place that you collect personal data. If you collect personal data via a website, for instance, your privacy policy should be available to be viewed there. If you collect personal data from a physical location, that location should have a copy of your privacy policy. If you collect data from a number of sites, such as by going door-to-door, you should ensure that data subjects will have no difficulty finding a copy of your privacy policy. This might be via your physical offices, a website or some other mechanism.

In addition to the privacy policy, you should determine what other policies will be necessary to your organisation. An information security policy in particular would be valuable. This could comprise a single policy document or a collection of different policies, not all of which will need to be as readily accessible to data subjects as the privacy policy.

The topics you might consider for information security policies include:

  • access control,
  • information classification,
  • backup,
  • information transfer,
  • antivirus and anti-malware,
  • vulnerability management,
  • cryptography,
  • communications,
  • supplier relationships.

In order to be effective, these policies will need to meet certain conditions. A good policy both reflects an organisation’s aims and directs its actions, so these conditions are really symptoms of good policies.

  • Policies must:

      be capable of being implemented,

      be enforceable,

      be concise and easy to understand,

      balance protection with productivity.

  • Policies should:

      explain the need for the policy,

      describe what is covered by the policy (the scope),

      define contacts and responsibilities,

      include at least one objective,

      explain how violations will be handled.

These conditions should tie into the organisation’s other operations. For instance, the objectives should link to the organisation’s broader business objectives – if the organisation is aiming to increase profitability by a given percentage, then the information security policy might have an objective to reduce losses by eliminating fines for non-compliance.

Establishing good policies is only part of the battle. In order for a policy to work, it needs to be supported by processes and procedures that fall within the defined parameters set by the policy. Processes and procedures should be created with a view to producing evidence that they are being correctly deployed and thereby demonstrating that the policy they support is effective.

The ability to prove compliance is critical, and a comprehensive and effective privacy compliance framework will develop evidence to support your claims of compliance.

Documentation toolkits can be a practical and cost-effective starting point for developing appropriate GDPR compliance documentation; these toolkits (and there is one published by IT Governance Publishing246) provide pre-written templates for all key GDPR documents, and you can then adapt these templates as appropriate to meet your own compliance and privacy framework requirements.

Codes of conduct and certification mechanisms

One of the more prominent methods of demonstrating compliance will be through implementing approved codes of conduct and participating in approved certification mechanisms. You’ll need to identify approved codes of conduct and certifications, but this should be made clear by your supervisory authority, and it’s safe to assume that frameworks such as ISO 27001 will be included, alongside possibly regional variations of personal information management systems like BS 10012.

These codes of conduct should be taken into account in your privacy compliance framework from the start because they could have a significant bearing on how your organisation manages its compliance or protects personal data. You should be aware of sector-specific codes of conduct and certifications, as well as model contract clauses, binding corporate rules, and so on.

Codes of conduct and certification mechanisms do not prove compliance with the Regulation, but they do support claims of compliance. If you have a current valid certification to ISO 27001, for instance, it doesn’t necessarily mean that your organisation is actually compliant with the Standard. What it does mean is that your organisation had all of the measures in place to support effective information security at a specific point in time. As these measures necessarily include mechanisms for keeping that system working, it’s a good bet that your organisation still conforms to the requirements of the Standard. The same is true in relation to compliance with the GDPR.

Being compliant with approved codes of conduct and/or certification mechanisms has some impact on how the supervisory authorities are required to assess the organisation in the event of a personal data breach. Given the potential scale of fines and other penalties, as well as the potential intrusiveness of an investigation, it would be wise to put your organisation in a position whereby it can provide auditable evidence that best practice has been applied.


240 GDPR, Recital 78.

241 GDPR, Article 4, Clause 20.

242 GDPR, Article 24, Clause 2.

243 GDPR, Article 39, Clause 1 b.

244 GDPR, Article 13, Clause 1.

245 GDPR, Article 13, Clause 2.