The first few steps of your compliance project can be the most confusing. Where do you start? Who needs to be involved? How do you go about identifying and meeting all of your obligations? How will you prove that you’re meeting all of the Regulation’s requirements?
Such questions can distract you from the project’s core requirements and make the entire process seem incredibly daunting.
For most organisations, a simple approach may be to ignore the specific, detailed requirements of the GDPR for now, and start instead by building a framework to ensure compliance both now and in the years ahead. The GDPR has a specific requirement that controllers should, “taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, […] implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary”8.
This clause is, in effect, saying that organisations should put in place a compliance framework that ensures they are implementing appropriate technical and organisational measures to ensure that data processing is performed in compliance with the GDPR.
The GDPR also explicitly requires organisations to demonstrate that they have embedded the principle of ‘data protection by design and by default’ into their organisational culture. Although there are a number of specific steps necessary to embed data protection by design, the starting point is undoubtedly to create an appropriate compliance framework that makes sure that data protection is in reality at the core of the organisation’s behaviour.
A “compliance framework” is a structured set of guidelines and practices that bring together the regulatory compliance requirements that apply to an organisation, and the business processes, policies and controls that are necessary in order to meet these requirements. Technical measures include specific procedures, as well as staff training, audits and all the relevant technical and physical security controls that form part of an effective information security management system. These processes, policies and controls will generally outline how the organisation manages communication, risk and governance relevant to the compliance requirements. Because there will often be some overlap between different compliance requirements, the framework should identify this in order to eliminate redundancies and uncertainties.
All compliance frameworks have to include three categories of activity as illustrated in Figure 1: people, process and technology.
A compliance framework could be developed for any set of legislative, regulatory or contractual requirements. For the GDPR, of course, it will be a privacy compliance framework.
The development of a privacy compliance framework is comparable to any other ongoing business project; you want to establish a set of practices and policies that make sure that certain processes are always followed. Assuming those processes are aligned with the legal requirements, the framework should ensure that the organisation remains on the right side of the law. Importantly, all the necessary processes don’t need to be defined from the start: they can be built into the framework at appropriate stages in order to achieve compliance. The most important step is getting the initial framework in place.
There are two ways of approaching this task: work it all out for yourself, or deploy and adapt a publicly available compliance framework. The first option relies on some combination of trial and error and (probably expensive) consultancy support; the second draws on established best practice and can be a faster and more cost-effective route to compliance than doing it all yourself.
There are several compliance frameworks and standards to choose from. The GDPR explicitly identifies the use of international standards and privacy marks as effective tools for demonstrating compliance with requirements and it makes practical and commercial sense for a privacy compliance project to start off by drawing on such established best practice.
A privacy compliance framework is useful primarily because it provides a structured way of managing confidential data in such a way that the organisation is able to comply with often complex laws and, perhaps, on a multi-jurisdictional basis. Organisations that do not already have a privacy compliance framework can use a standardised framework to make the leap from exposure to compliance; organisations that do already have a privacy compliance framework can use national and international standards to obtain certifications that will enhance credibility with customers and stakeholders while also demonstrating to regulators and, perhaps, judges the due diligence and compliance efforts that have been made. There are currently two recognised standards or frameworks that could be used: ISO/IEC 27001:2013 and BS 10012:2017. There is an internationally recognised, accredited certification programme for ISO 27001. The certification status for BS 10012 is not yet clear. Other standards and Trust Marks are also expected to emerge.
The three key areas of a privacy compliance framework are:
- governance, risk management and compliance objectives;
- the data protection principles;
- policies, procedures, controls and records.
In most management systems and frameworks, there is a sense that the various processes are related, and that they feed into and are informed by a common set of controlling processes. That is, like most business processes, these functions will have defined inputs and outputs, and the privacy-specific inputs will eventually result in privacy-specific outputs.
Any framework applies to a specific scope, the area of the organisation and its operations that fall within it. For the purposes of compliance, the scope of the framework must be directly informed by the requirements of the Regulation, which is described in Article 2.
This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.9
That is, your framework must cover all activities that involve the collection, use or other processing (such as deletion or modification) of personal data. For many organisations, this will cover almost all of their activities. Remember that this does not specify that the personal data is that of customers: you must also include personal data of your employees, contractors, etc.
There are some exemptions, but these typically relate to either high-level Union activities (such as Member States operating in the interests of national or Union security), in the pursuit of criminal justice by competent authorities, or to very low-level activities (such as handling personal data as a natural person exercising activities that are exclusively personal or domestic, rather than as an organisation processing in pursuit of business objectives).
The GDPR is explicit10 in saying that it
applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:
(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or
(b) the monitoring of their behaviour as far as their behaviour takes place within the Union.
In other words, any organisation in the world may be subject to the GDPR if it provides services to data subjects that are within the EU. Please consider Recital 14: “the protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data”. GDPR confers the same rights on all data subjects, wherever in the world they may live, if that data is processed by a controller or processor within the EU or by one that is providing services into the EU. This may have significant implications on the scope of organisational privacy compliance frameworks.
Furthermore, the GDPR requires11 organisations that are based outside the EU to nominate in writing a representative organisation within the EU. This representative must be located in one of the Member States where the target data subjects are based and must be mandated by the data controller or data processor to be addressed by the supervisory authority or data subjects on all issues relating to the processing of personal data. The appointment of such a representative will not, however, enable the controller or processor to avoid legal action for breaches of the GDPR.
In terms of the compliance framework, there may be other considerations, such as local or sector-specific laws and regulations, that may also have to be taken into account.
All organisations have an obligation to comply with the law. One of the fiduciary duties of directors is to ensure that their organisation has taken appropriate steps to comply with all relevant laws. Directors also have a fiduciary – and in many cases also a legal and contractual duty – to ensure that risks to the organisation are appropriately managed. Cyber risk is an example of the type of risk of which directors have to be aware. Cyber attack exposes organisations to significant reputational and operational damage, as well as the possibility of legal action by those whose personal data has been compromised. The GDPR gives any data subject the right to pursue judicial remedies for both material and non-material harm arising from the processing of their data. This, combined with the specific GDPR requirements around data breach reporting and the significant administrative penalties for compliance breaches (up to 4% of global revenue or €20 million, whichever is greater), should be on the radar of all directors and on the agendas of all board meetings. Boards should ensure that the privacy compliance frameworks that are put in place are capable of ensuring GDPR compliance and that they contain mechanisms for providing regular reports and assurance to the board on the state of compliance across the organisation.
One way that boards can approach their governance responsibility in respect of information and privacy risk is through the appointment of a board-level senior information risk owner (or ‘SIRO’). The UK Government originated the idea of this role as part of its extended strategy to tackle information risk across the public sector and described the role of SIRO to be managing information risk from a business not a technical perspective, focusing on the strategic information risks related to the delivery of corporate objectives. This means taking a holistic approach to information risk across the supply chain and managing it in line with the organisation’s risk appetite. This is a useful role for a board to put in place. This role is expected to work with board colleagues to:
- establish an information risk strategy which allows assets to be exploited and risks to be managed effectively;
- identify business-critical information assets and set objectives, priorities and plans to maximise the use of information as a business asset; and
- establish and maintain an appropriate risk appetite with proportionate risk boundaries and tolerances.
Clearly this role has a broader responsibility than simply managing privacy risk. The reality, however, is that any framework you build to manage privacy risk must, perforce, be part of your wider framework for managing information risk. It therefore makes sense to tackle GDPR compliance as part of your wider strategy for managing information risk.
All international management system standards published after 2013 contain, in clause 5 and its sub-clauses, a number of specific requirements covering top management commitment; these provide a good starting point for any organisation in determining the leadership of a corporate governance framework. The clause 5 requirements are detailed below.
Top management demonstrates leadership and commitment to the management system by:
a. ensuring policy and objectives are established and are compatible with strategic direction;
b. ensuring integration of the management system into the organisation’s processes;
c. ensuring resources needed for the management system are available;
d. communicating importance of effective management and of conforming to the management system requirements;
e. ensuring the management system achieves its intended outcome(s);
f. directing and supporting persons to contribute to the effectiveness of the management system;
g. promoting continual improvement, and;
h. supporting other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility.
ISO/IEC 38500 is a standard that deals specifically with the corporate governance of information and communications technologies. It, too, is useful guidance for creating an effective technology governance framework.
Your privacy framework will have a number of objectives. Obviously, the overall objective should be to comply with the Regulation and to avoid the “dissuasive” fines and other punitive measures. Your framework should also identify specific subsidiary objectives relating to the rights of data subjects and the protection of personal data.
Objectives should be determined in a way that enables performance against them to be tracked and measured. An objective is only useful, after all, if you can determine how you stack up against it. The normal acronym used in relation to objectives is that they should be SMART:
- Actionable (or achievable)
The performance of information security controls should be capable of measurement and improvement and ISO/IEC 27004 provides specific guidance on control measurement. While this standard is a useful starting point for tackling control performance, it does not contain specific guidance on measuring performance against specific data privacy objectives.
Key objectives could include:
- the capability of responding to subject access requests within the new prescribed time frame (now one month12);
- the capability of identifying and reporting data breaches to supervisory authorities within 72 hours;
- retention periods of personal data;
- staff awareness training.
A privacy framework should have a number of key processes, some of which your organisation may already have, and others that may be new. These could include processes for incident management, change management, corrective action, risk management and continual improvement.
Incident management processes – which will be discussed in Chapter 14 of this manual – are all about what you do when there is a data breach or some other information security incident.
Fundamentally, the incident management process will comprise several stages: realising that something has happened and reporting it, understanding what has happened, containing the event to minimise damage, repairing the damage, making sure that the event cannot recur, and reviewing the organisation’s response. The outputs of the incident management process will inform how the organisation’s framework evolves to meet its current and future challenges.
The organisation will also need change management processes. All organisations have to change and adapt to risks and events, and to changes in customer and market requirements. When changes are rolled out to an organisation in an unstructured manner, new and unforeseen risks can be introduced. This is particularly true of ICT-related processes. Inadequate management of changes to business processes (or to departments or reporting structures) can create risks to personal information and possible breaches in existing privacy protection mechanisms. A change management process is an essential step in ensuring that rolling out a change is completely thought through, that possible deviations, problems and consequences have been identified and mitigated, and that roll-back options are in place.
A corrective action process is also necessary so that an organisation can make amends when something doesn’t work as intended. This might be as obvious as a control being inadequate and failing to suitably protect an asset, or it might be a larger, systemic fault that prevents a whole process from functioning. In either case, the organisation will need a systematic method of identifying and remediating the fault.
You’ll see the obvious connection here with the incident management and change management processes. Once an incident has been dealt with, there should be an analysis of the cause of the incident, which should lead to the identification of amendments to or changes in existing controls or processes. These changes should be dealt with through the corrective action process, ensuring that corrections are reviewed and approved, that they’re correctly implemented, and that they’re reviewed for effectiveness. This last point is worthy of note: a corrective action needs to correct the problem, so your process will need to include a review stage. This review might be a one-off confirmation or it might require ongoing attention – that’s something the process will need to identify.
One of the more critical processes is risk management, which is dealt with in much greater depth in Chapter 6 of this manual. All organisations face risks and, in the case of GDPR compliance, the focus will be on risks to personal data and to the systems and processes that interact with that data.
Risk management is very much at the core of any privacy compliance framework because the organisation needs to understand exactly what risks it needs to protect itself from. Just as a person might put on a suit of armour to save themselves from injury, that suit will be completely useless against poisonous gas, or might only have limited effectiveness against a bear. The organisation should ensure it invests its money and resources in the right areas, so having an effective risk management regime in place is a good way of ensuring that the return on investment is worthwhile.
Where privacy risk is concerned, though, the risk management programme must also look closely at risks to the ‘rights and freedoms of natural persons’ that might arise from the processing of their data. In a sense, the GDPR says to organisations that they face the risk of substantial administrative fines, as well as legal action from data subjects, if they fail to adequately manage risks to those data subjects.
A framework or management system should also have an underlying continual improvement process. A continual improvement process assesses existing processes and their outputs for conformity with laws, regulations or other requirements, determines any necessary adjustments, and then feeds these into the originating processes that determine the framework or management system’s inputs. In simpler terms, you might like to refer to the Plan-Do-Check-Act cycle (PDCA, also called the Deming Cycle), which is a popular management tool for ensuring ongoing improvement.
The PDCA cycle divides the standard processes and practices for a management system or development process into four distinct stages: planning, doing, checking and acting. As a cyclical process, each stage feeds into the one that follows and enables continual improvement.
- the organisation plans what it is going to do;
- does what it has planned to do;
- checks whether what it has done has achieved what it planned, and;
- acts on those findings to improve how it achieves its objectives.
The PDCA cycle is illustrated in Figure 2, below.
Understanding how the processes and continual improvement of those processes all fit together is a critical feature of any effective compliance framework. Under the assumption that all of your processes are adequate and that they are being followed, such a framework provides assurance that you are continuing to adapt and improve your processes so as to continue meeting your compliance requirements.
Personal information management systems (PIMS) are a form of management system dedicated to the management of personal information. As such, they can form a good basis for a compliance framework.
It is important to note that, while a PIMS and a compliance framework are broadly similar, there are distinctions. For instance, a compliance framework is not necessarily a “single object” but may be comprised of two or more management systems working in concert (a PIMS and an information security management system, or ISMS, for example). A PIMS may also be focused on simply managing personal information rather than necessarily protecting it in line with legal or regulatory requirements. In this sense, the PIMS may only provide some of the processes necessary to ensure overall compliance.
While a PIMS is not necessarily designed to ensure compliance with the GDPR specifically – or even with current laws such as the UK’s Data Protection Act (DPA) or Germany’s Federal Data Protection Act (Bundesdatenschutzgesetz, BDSG) – standardised models will usually include a requirement to identify legislative, regulatory and contractual requirements relating to personal information, and to include those requirements in the PIMS.
There are several possible ways to achieve this and BS 10012:2017 – Data protection – Specification for a personal information management system – provides one such framework for doing so. It provides a well-defined, well-understood structure for managing data protection, and it is designed to follow the PDCA cycle to ensure continual improvement. While the earlier version of the standard was specific to the UK’s DPA, it has been re-drafted and updated to reflect the requirements of the GDPR and, as such, BS 10012: 2017 should be generally suitable as the core of a privacy compliance framework.
BS 10012 includes a requirement to “define the scope of the PIMS and set personal information management objectives, with due regard to the […] applicable statutory, regulatory, contractual and/or professional duties”13. Properly applied, this means that the processes described in BS 10012 should take the appropriate legal requirements into account.
However, BS 10012 may not on its own be an adequate framework, depending on how your organisation collects, stores and uses personal data. BS 10012 is narrowly focused on privacy protection, and if personal data is more widely used across your business processes, then a more comprehensive security framework would be appropriate. In this circumstance, you may need to define additional processes in order to comply with the Regulation. This is where an additional management system may be useful, such as ISO/IEC 27001, which is the international standard that describes best practice requirements for an information security management system (ISMS).
Regardless of the standard or business process model employed, a PIMS is likely to be a useful core for your privacy compliance framework. Figure 3 provides an overview of the typical components of a PIMS.
The GDPR requires organisations to go further than simply putting in place a PIMS. There is an explicit requirement14 for organisations to have in place:
- the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
- the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident;
- a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
This really does mean that organisations have to integrate data and privacy protection into ‘business as usual’ and that a more comprehensive approach to information security – one which deals with the processing systems and services, as well as with security, continuity and continual security testing (primarily in the form of penetration testing) – is essential. This is where ISO/IEC 27001 comes in.
ISO 27001 is an internationally recognised, management system standard for information security management. It describes the requirements of an information security management system (ISMS) based on established best practice. It is sector-agnostic, does not favour any one technology or solution, and can be used by organisations of any size. It sets out requirements for what must be done to secure information but provides room for organisations to determine how they implement the requirements to meet their organisational objectives and risk appetite.
This framework for information security can also be used to achieve accredited external certification. The assurance provided by such certification is widely recognised as proof that the organisation protects information assets, and it is a requirement in a growing number of contracts that involve valuable information.
Structurally, it’s not too different from BS 10012; both describe processes that are critical to the protection of personal data, and both recognise that a number of processes are necessary to assure the security of this data. The distinction is that BS 10012 is specifically focused on personal information, while ISO 27001 is interested in information more generally. As such, an ISO 27001 ISMS could be used as a larger framework within which BS 10012 can sit. ISO 27001 encourages the organisation to seek out additional sources of best practice, and BS 10012 is certainly that.
Figure 4 shows the structure of an ISO 27001 ISMS.
ISO 27001 aims to safeguard the “confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed”15. In fact, information security is defined as the “preservation of the confidentiality, integrity and availability of information”. In information security:
- Confidentiality is the “property that information is not made available or disclosed to unauthorized individuals, entities, or processes”16;
- Integrity is the “property of accuracy and completeness”17;
- Availability is the “property of being accessible and usable upon demand by an authorized entity”18, and;
- Risk is the “effect of uncertainty on objectives”19.
Confidentiality, integrity and availability are often called the CIA of information security, because they’re the key attributes of secure information. The GDPR itself mentions them explicitly on a number of occasions. Similarly, ISO 27001’s approach to risk is in alignment with the Regulation’s requirements for impact assessments, as you’ll see later in this manual.
ISO 27001 takes the approach that information security must be driven from the top down. As such, it contains the requirement that an information security policy, signed off by top management, is enacted through critical processes such as risk management, monitoring and review, corrective actions, and so on.
ISO 27001 Annex A lists 114 controls, in 14 categories, which can be used to identify what may be appropriate controls to help manage the security of personal information. Figure 5 shows the 14 control categories.
The best book for detailed, practical guidance on implementing these controls is Alan Calder and Steve Watkin’s IT Governance: An International Guide to Data Security and ISO27001/ISO2700220, now in its sixth edition. For a straightforward description of how to design and implement an information security management system that meets the requirements of ISO/IEC 27001:2013, turn to Alan Calder’s Nine Steps to Success: an ISO27001 Implementation Overview21. IBITGQ also has relevant ISO 27001 implementation and audit qualifications available.
Organisations that implement ISO 27001 will naturally find themselves accruing evidence of their compliance to the Standard, especially if it has gone to the trouble of external certification for their ISMS. This evidence is useful beyond simply getting certification or showing clients that your processes are secure. In the event that an organisation is subject to an investigation or audit, it will be able to draw upon this evidence to show that it has been following best practice, that it has taken appropriate steps to prevent incidents, that it recognises the risks it faces, and that people at all levels throughout the organisation are appropriately trained, competent and responsible.
While ISO 27001 and BS 10012 are the most likely candidate standards to use as the basis of a privacy compliance framework, there are other standards and business process models which could also be used. Whichever you choose – and whether you decide to choose one of the standards or business processes mentioned here – will depend on your organisation and its specific processes, resources and requirements.
COBIT® (Control Objectives for Information and Related Technologies) is a control-based framework for the governance of IT and information. It may seem a slightly abstract approach to GDPR compliance, but establishing governance and oversight will be an important part of ensuring the security and privacy of personal data, as will asserting accountability and responsibility for maintaining this. COBIT is a widely used framework in some countries – particularly at the enterprise level – and so there are publications and experts available to provide advice and guidance, if necessary.
Other frameworks have been developed by government agencies to simplify the compliance process when working with complex sets of legislation. While these may not be immediately relevant to GDPR compliance, they often contain an effective structure and processes that can be applied to meet European compliance requirements. The Privacy Management Framework22 developed by the Office of the Australian Information Commissioner (OAIC), for instance, is a simple four-stage process that matches the PDCA cycle, and provides guidance at each stage to ensure compliance with the range of Australian law and other relevant requirements imposed by other nations that Australia regularly trades with.
The US National Institute of Standards and Technology (NIST) has also built an extensive collection of information security standards, known as the NIST Special Publication 800 series. While it is not specifically an information security management framework, the NIST SP 800-53 model is used by US government agencies that need to comply with the requirements of Federal Information Processing Standard (FIPS) 200. Although NIST SP 800-53 may be intended for government agencies, the framework could certainly be applied to other industries.
Selecting and implementing a compliance framework
The decision to select, design or compile a particular framework to ensure compliance will be based on a number of critical considerations.
To begin, the scope of the compliance project will inform the level of detail and the breadth of the organisation that the framework will need to include. You will need to consider a variety of factors in this regard, including whether your organisation is a data controller or a data processor, the type and volume of personal data that your organisation collects and/or processes, the end-to-end processes within which personal data is processed, the different ways in which data is collected and processed, and so on. Analysing this information in order to clearly define the scope of the project is an essential step, especially if you elect to use one or more management system standards (such as a PIMS) to develop your compliance framework.
As well as informing the scope, the personal data that your organisation collects, stores or processes will also influence your choice of compliance framework. If you work with special categories of personal information, such as health information, or process especially large quantities of data, the GDPR requires additional measures to ensure the data is secure. As such, your compliance framework may need additional processes to ensure that you meet these requirements and that you have sufficient evidence of compliance.
The complexity of your organisation will also impact your choice of compliance framework and its scope. A large organisation with a broad portfolio of processes will not necessarily want a framework that interferes with processes outside the data protection scope, for instance. In contrast, an organisation that makes extensive use of personal data for differing purposes across a range of functions will need a framework that accounts for data processing in relation to each of the various business objectives. The methods for protecting information in one process may be wholly incompatible with the methods for protecting it in another.
In addition to ensuring the framework is suitable to your organisation’s specific needs, you should also consider the frameworks used by others in your industry or sector. This will help you to think about the sector-specific needs that other organisations have identified, as well as allowing you to leverage any existing experience or knowledge.
As previously noted, many organisations will be subject to a number of additional legal or regulatory requirements, as well as differing jurisdictional requirements in different parts of the world, in relation to personal data or information, ranging from Freedom of Information legislation to HIPAA data portability requirements. These should also be taken into account in your choice of compliance framework. Some laws and regulations will require specific evidence in order to demonstrate compliance, and this may overlap considerably with the requirements of the GDPR.
Your organisation’s experience with management systems and frameworks will also influence your decision. For organisations with little such experience, we would generally recommend starting with established standards such as BS 10012 and ISO 27001, not least because of the wealth of standard-specific resources available to support your project. For organisations with more experience, the choice may be influenced by a desire to extend an existing integrated management system to include personal information management. In this case, you will need to ensure that the organisation’s internal pressures and documented processes do not interfere with the project’s primary goal: having appropriate and proportionate controls in place to protect personal data and demonstrate compliance with the GDPR.
Finally, the availability of resources, support and guidance is also an important factor. Once again, organisations with less experience in either compliance or data protection will need to ensure there are appropriate resources available, both internally and externally, to ensure that the project will be viable.
Implementing the framework
Once you’ve decided on the starting point for your privacy compliance framework, you will need to establish how it integrates with your organisation. Who is responsible and accountable for each process? Who needs oversight? What sort of training is necessary? These sorts of questions, in conjunction with the requirements of the GDPR, will inform how you build out the framework from the core requirements.
Beginning from first principles, the framework should be driven by a formal organisational privacy and data protection policy, which should be published and made available to appropriate interested parties, including employees. The policy needs to specify the organisation’s position on data privacy and protection, assert that it aims to comply with the GDPR and other relevant data protection laws and regulations, and be signed off by an appropriate top management authority, such as the board or CEO.
Beneath the data protection policy, you’ll need to define and document the essential data protection processes that convert the policy into practice. You could do this with a set of process maps. Each specific process should be sufficiently documented so that anyone who has identified responsibilities within the process is clear about what has to be done, by whom, and by when, in a way that will deliver consistent outcomes. Typically, this is done by means of a RACI chart. A RACI chart defines, for each process (or step in a process) in an organisation, who is:
The purpose of a RACI chart is to ensure that the process is designed and operates in line with business requirements, is consistently and reliably performed, and is in alignment with formal requirements, such that management can depend on it to deliver required results. Figure 6 shows what a simple RACI chart might look.
You will want the process outputs and activity records to confirm, first, that you are complying with the law and, second, that your framework is working in line with the organisation’s requirements. So you’ll need to think about the metrics that will provide this information and how you can gather them. Some may be as simple as keeping a record of the number of times a certain process is performed, others might be based on staff surveys.
Developing a compliance monitoring programme is a logical extension of this approach, and would involve implementing a compliance testing process to monitor your system or framework. There are many ways of measuring the effectiveness of any management system or framework, and at least as many books on the topic. This evaluation process will feed your continual improvement process. This involves recognising when your organisation has failed to comply and working to amend that, or seeing that a process isn’t working as well as it could and improving it.
Corrective action and continual improvement processes were discussed earlier. Such continual improvements are imperative to futureproof your compliance to the GDPR. As the business processes, policies and controls evolve, so must your framework.
8 GDPR Article 24, Clause 1.
9 GDPR, Article 2, Clause 1.
10 GDPR, Article 3.
11 GDPR, Article 27.
12 GDPR, Article 12.
13 BS 10012:2009, Clause 3.2 d).
14 GDPR, Article 32, Clause 1 – Security of Processing.
15 ISO/IEC 27001:2013, Clause 0.1.
16 ISO/IEC 27000:2016, Clause 2.12.
17 ISO/IEC 27000:2016, Clause 2.40.
18 ISO/IEC 27000:2016, Clause 2.9.
19 ISO/IEC 27000:2016, Clause 2.68.