Complete Guide to GDPR Compliance

A data controller determines the purposes for which an organisation collects and uses personal data. They can be an individual or a group, but as long as they have the authority to decide how and why information should be processed, they are a data controller.

However, the GDPR’s obligations mean that you can’t just start gathering personal information. You need a lawful basis, and it’s the data controller’s responsibility to decide which basis applies and to document their justification.

Data controllers must also determine:

A data processor is the person or organisation that handles personal data on behalf of the controller.

In general, data processors will be expected to:

However, this isn’t to say that the data processor must do exactly what the controller demands. Before processing any information, both parties must sign a contract agreeing to their responsibilities.

The contract must state that data processors may act only on the data controller’s documented instructions, that they won’t contract a sub-processor without prior approval, and that they will delete or return all personal data to the data controller at the of the contract.

Understanding your role as either a data controller or data processor requires you to identify the differences between the two roles.

Say, for example, that you are a marketing executive at a retailer who wants to conduct a survey on shoppers’ browsing habits.

That would make you a data controller. As such, you must find a data processor to conduct the survey and provide them with the necessary information to complete that task.

If you fail to do that, you’ve violated the GDPR and are subject to disciplinary action. The repercussions are even worse if the data processor suffers a data breach, because you’ll be liable for any mistakes they make.

However, it’s not always that simple. The GDPR permits two or more organisations to jointly determine the purposes and means of processing the same personal data.

Joint data controllers must agree which one will take primary responsibility for complying with the GDPR and to make this information available to individuals.

Despite that, all joint controllers have GDPR compliance responsibilities, and supervisory authorities and individuals may take action against a controller should those obligations not be met.

If you’re wondering how data processors fit into this – they must only act on behalf of, and follow the instructions of, the relevant controller.

It’s worth clarifying that if multiple data controllers are processing the same data but for different purposes, they are not joint controllers; they are instead two separate data controllers that happen to be performing a similar task.

In the most basic terms, personal data is any piece of information that someone can use to identify, with some degree of accuracy, a living person.

For example, the email address [email protected]” is considered personal data, because it indicates there can only be one John Smith who works at Company X.

Likewise, your physical address or phone number is considered personal data because you can be contacted using that information.

Personal data is also classed as anything that can affirm your physical presence somewhere. For that reason, CCTV footage of you is personal data, as are fingerprints.

That sounds simple enough so far – but things are complicated when you factor in that each piece of information doesn’t have to be taken on its own.

Organisations typically collect and store multiple pieces of information on data subjects, and the amassed information can be considered personal data if it can be pieced together to identify a likely data subject.

Think of it like a massive game of Guess Who?

Under certain circumstances, any of the following can be considered personal data:

You might think that someone’s name is always personal data, but as the ICO (Information Commissioner’s Office) explains, it’s not that simple:

However, the ICO also notes that names aren’t necessarily required to identify someone:

Sensitive personal data is a specific set of “special categories” that must be treated with extra security. This includes information pertaining to:

Sensitive personal data should be held separately from other personal data, preferably in a locked drawer or filing cabinet.

As with personal data generally, it should only be kept on laptops or portable devices if the file has been encrypted and/or pseudonymised.

A common misconception about the GDPR is that all organisations need to seek consent to process personal data.

In fact, consent is only one of six lawful grounds for processing personal data, and the strict rules regarding lawful consent requests make it the least preferable option.

However, there will be times when consent is the most suitable basis, and organisations need to be aware that they need explicit consent to process sensitive personal data.

Nuances like this are common throughout the GDPR, and any organisation that hasn’t taken the time to study its compliance requirements thoroughly is liable to be tripped up.

This could lead to lasting damage, such as enforcement action, regulatory fines, bad press and loss of customers.

Data protection by design is ultimately an approach that ensures you ‘bake in’ privacy and data protection into your processing activities and business practices.

To implement data protection by design, the GDPR says that you must:

Data protection by default requires you to ensure that you only conduct data processing activities if they are necessary to achieve a specific goal.

It links to the GDPR’s principles of data minimisation and purpose limitation.

To comply with data protection by default, you must consider:

The term ‘data subject’ refers to any living individual whose personal data is collected, held or processed by an organisation. Personal data is any data that can be used to identify an individual, such as a name, home address or credit card number.

DPIAs are a useful way of ensuring the efficiency – and cost-effectiveness – of the security measures you implement.

A risk-based approach ensures you do not waste resources attempting to mitigate threats that are unlikely to occur or will have little effect.

When required, not carrying out a DPIA could leave you open to enforcement action from the ICO (Information Commissioner’s Office) – the UK’s data protection authority. This could include a fine of up to 2% of your organisation’s annual global turnover or €10 million – whichever is greater.

Regular data privacy impact assessments also support the GDPR’s accountability principle. This helps your organisation prove its compliance with the Regulation – both to the supervisory authority and other stakeholders.

As the title suggests, EU representatives must be established in the EU and work on behalf of non-EU-based organisations.

In the case of UK organisations, this will primarily involve serving as the point of contact between the organisation, the ICO (Information Commissioner’s Office) and data subjects.

They’ll do this by:

The tasks of an EU representative sound a lot like those of a DPO (Data Protection Officer), but don’t confuse the two.

An EU representative is tasked with representing non-EU based organisations when it comes to their GDPR requirements. In other words, they are a function of the organisation’s GDPR compliance practices.

By contrast, a DPO is an independent expert who helps facilitate and assess the organisation’s compliance practices. They are responsible for monitoring compliance and advising organisations on how to navigate their requirements.

UK organisations only need to appoint an EU representative if they monitor or provide goods or services to EU residents.

If you deal exclusively with UK-based customers, you won’t be required to appoint an EU representative. That’s because as soon as the UK is no longer in the EU, your customers will cease to be EU residents.

However, if your data processing or monitoring extends to other EU member states, you’ll probably be required to appoint an EU representative. There are two exemptions:

Your EU representative can be any natural or legal person who’s based in an EU member state within which you collect personal data.

If you only collect information from data subjects in, say, France, your EU representative must be based in France. However, if you collect personal data from the entirety of the EU, you can appoint a representative in any EU member state.

When you have multiple countries to choose from, it’s best to select the one in which you collect the most data or conduct the most extensive monitoring.

The documentation of processing activities is a new legal requirement under the EU GDPR (General Data Protection Regulation).

Documenting your processing activities can also support good data governance, and help you to demonstrate your compliance with other aspects of the GDPR.

In this post we have listed all of the documentation, policies and procedures you must have if you want to be fully GDPR compliant.

A privacy notice is one of several documents required for GDPR compliance.

But whereas many of these documents are strictly internal, a privacy notice is provided to customers and other interested parties, explaining how the organisation processes their personal data.

There are two reasons for doing this. First, it prevents any confusion about the way personal data is being used and ensures a level of trust between the organisation and the individual.

Second, it gives individuals more control when an organisation collects their personal data. If there’s something they aren’t happy with, they can query it via a DSAR (data subject access request) and ask the organisation to suspend that processing activity.

Article 30 of the GDPR explains that a compliant document should include the following details:

Article 15 states that data controllers must confirm to data subjects whether their personal data is being processed, and, where it is, provide them with a copy of that personal data (providing it does not adversely affect the rights and freedoms of others).

They must also state:

It’s therefore essential to establish a procedure for responding to DSARs.

Your DSAR procedure should ensure you are able to meet the following requirements:

And Recital 63 recommends that, where possible, “the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to his or her personal data”.

A request might refer to specific personal details or processes for which the organisation processes that information, in which case you only need to provide relevant information.

However, individuals may ask to see a full list of the personal data that the organisation stores on them.

This will undoubtedly be burdensome, because it’s not merely a case of pulling up everything you store on that person.

If you did that, you’d end up with large volumes of information that aren’t considered personal data – such as internal memos about the data subject’s files – which don’t need to be shared.

Your first tasks, therefore, are to determine what information related to the individual is considered personal data under the definition of the GDPR, and whether it’s part of the data that they requested.

This information must be provided alongside other supplementary material, such as the relevant details provided in the organisation’s privacy notice.

Although the GDPR promotes openness to the public, organisations can and, where relevant, should redact anything that’s not within the scope of the DSAR.

For example, you might have documents that include that individual’s personal data alongside the personal details of other people.

In these circumstances, you are required to redact all personal data that isn’t about the person making the request, because otherwise, you’d be committing a data breach.

Likewise, you might have records where the individual’s personal data is stored alongside sensitive company data. You are within your rights to redact that information.

Are you following the correct steps when responding to a data subject access request?

Individuals don’t need to state why they are submitting a DSAR. The only questions an organisation may ask when a DSAR is submitted concern verifying the individual’s identity or to help them locate the requested information.

There is no formal process for submitting a DSAR. That means requests don’t need to be submitted in writing – or in any documented way. For example, an individual can make a request while speaking with a member of staff.

It’s also worth noting that individuals aren’t required to use the technical term for a request (‘DSAR’ or ‘data subject access request’).

They can, for instance, simply say that they’d like to see a copy of the information the organisation stores on them.

That said, requests are most likely to be submitted in writing, as it’s the most convenient method.

It gives individuals and organisations a record of the request, the date that it was made and other relevant information, such as the specific personal information that they want a copy of and the format that it should be delivered via.

Yes, individuals can authorise someone else to make a request on their behalf. This is most likely to happen when:

Organisations must, of course, be satisfied that the person making the request really is doing so on behalf of the data subject.

As such, they are entitled to request supporting evidence, such as written authorisation from the data subject or a more general power of attorney.

There is a subject access request time limit. DSARs must be fulfilled “without undue delay”, and at the latest within one month of receipt.

Where requests are complex or numerous, organisations are permitted to extend the deadline to three months. However, they must still respond to the request within a month and explain why the extension is necessary.

An organisation’s Data Protection Officer (DPO) will generally be responsible for fulfilling a DSAR, provided the organisation has appointed one.

If you don’t have a DPO, the duty should fall to someone in your workforce with data protection knowledge.

In either case, the expert probably won’t do the physical work involved in completing the request, such as combing through documents and redacting information.

Still, they will oversee the process and ensure that it is being completed in line with the GDPR’s requirements.

Under the GDPR’s predecessor, the DPA (Data Protection Act) 1998, organisations could charge a fee for fulfilling a DSAR, but that’s no longer the case in most instances.

Indeed, as the UK’s data protection supervisory authority, the ICO (Information Commissioner’s Office), explains, there are only two instances when organisations may now only request payment for a DSAR.

These are when a request is manifestly unfounded (i.e. when the individual clearly has no intent to exercise their right of access, such as when the request is an excuse to make unsubstantiated accusations against the organisation) or excessive (i.e. when the request overlaps with a recently submitted DSAR).

Organisations should base the fee they charge on the administrative costs involved. That’s to say; they shouldn’t be profiting from requests.

It’s worth adding that organisations are within their rights to reject manifestly unfounded or excessive requests outright instead of charging a fee for them. This might be the case when they simply don’t have the time or resources to fulfil the request.

DSARs might sound a lot like freedom of information (FOI) requests, but in practice, they are a lot different.

Whereas DSARs grant EU residents access to copies of their personal data, FOI requests are specific to the UK and relate to recorded information held in the public sector.

This generally refers to government departments, local councils and regulators, such as the Financial Conduct Authority.

Additionally, personal data is not covered by the FOI Act, so there are no restrictions on who can make a request.

Like many aspects of the GDPR, access requests have a formal name that organisations must be aware of for compliance purposes, but that doesn’t mean individuals need to know the terminology.

As the ICO (Information Commissioner’s Office), the UK’s data protection supervisory authority, notes, there’s no specific process for making a request, so someone could simply say “I’d like to see what data you have on me”, and that would be considered a legitimate request.

As such, it’s essential that anyone in your organisation who may receive such a request knows what to look out for and who to pass the message on to.

In many organisations, the DPO will responsible for handling DSARs. However, if you aren’t required to appoint one, you’ll need to find an alternative approach.

Since time is of the essence when responding to a DSAR, it’s a good idea to ensure you have an established DSAR process beforehand, so that you can deal with such requests quickly.

There are many steps you can take to help your organisation manage DSARs. Your first task is to create a flowchart to make sure you respond promptly, thoroughly and in line with the GDPR’s requirements.

There are also ways you can make your organisation more resilient to the challenges that come with responding to DSARs. For example, you should implement measures addressing:

A data protection policy is an internal document that serves as the core of an organisation’s GDPR compliance practices.

It explains the GDPR’s requirements to employees, and states the organisation’s commitment to compliance.

The data protection policy doesn’t need to provide specific details on how the organisation will meet the Regulation’s data protection principles, as these will be covered in the organisation’s procedures.

Instead, a policy only needs to outline how the GDPR relates to the organisation. Take data minimisation as an example.

Whereas your procedures should state exactly how you will ensure this principle will be met (for example, you might require that any prospective data collection activities be accompanied by a document explaining why processing is necessary), your policy need only state that the organisation will address that principle.

Data protection policies serve three goals. First, they provide the groundwork from which an organisation can achieve GDPR compliance.

The Regulation as it’s written is too complex to be used as a basis for an implementation project. Imagine starting on page one and planning your compliance practices as you go; it would be a mess.

Instead, you should use the policy as a cheat sheet, breaking the GDPR’s requirements into manageable chunks that apply to your organisation.

That brings us to the second goal: to make the GDPR understandable to your staff. Remember, most employees who handle personal data aren’t data experts and won’t have pored over the Regulation’s principles to understand why these rules are in place.

A data protection policy is the ideal place to address that, explaining in simple terms how the GDPR applies to them and what their obligations are.

Finally, data protection policies prove that organisations are committed to preventing data protection breaches.

Article 24 of the GDPR specifies that organisations create a policy in order to “demonstrate that [data] processing is performed in accordance with this Regulation”.

Being able to demonstrate compliance is essential when it comes to regulatory investigations.

If a customer complains that an organisation has misused their data or hasn’t facilitated one or more of their rights as a data subject, the organisation will be subject to an investigation from their supervisory authority.

A data protection policy will be the first piece of evidence the regulator looks for to see whether the organisation takes the GDPR seriously.

From there, the supervisory authority may determine whether the organisation processes personal data lawfully, and if it didn’t, whether the violation was due to a mistake or widespread neglect of the Regulation’s requirements.

The answer to this will determine what disciplinary action is levied. A one-time mistake might be met with a slap on the wrist and a reminder to be more thorough in the future, but a systemic failure will almost certainly lead to a significant fine.

You can include as much or as little information in your GDPR data protection policy as you like, but we recommend that you cover:

A data retention policy is a set of guidelines that helps organisations keep track of how long information must be kept and how to dispose of the information when it’s no longer needed.

The policy should also outline the purpose for processing the personal data. This ensures that you have documented proof that justifies your data retention and disposal periods.

If you cast your mind back to the panic that preceded the GDPR taking effect, you’ll have a perfectly good understanding of why data retention periods are essential.

Organisations that hadn’t interacted with us in years came out of the woodwork to ask for our consent to keep hold of our data.

It showed just how often our records sit on organisation’s databases long after we’ve finished using their services.

The organisation doesn’t want to get rid of the information, because it costs practically nothing to store customer details, but keeping it unnecessarily exposes it to security threats.

It only takes one piece of bad luck for an organisation’s systems to be breached, whether it’s a cyber attack or an internal error.

So, to limit the damage that data breaches can cause, regulators mandated that EU-based organisations must retain personal data only if there’s a legitimate reason for keeping it.

Despite the apparent strictness of the GDPR’s data retention periods, there are no rules on storage limitation.

Organisations can instead set their own deadlines based on whatever grounds they see fit. The only requirement is that the organisation must document and justify why it has set the timeframe it has.

The decision should be based on two key factors: the purpose for processing the data, and any regulatory or legal requirements for retaining it.

Data should not be held for longer than is needed and shouldn’t be kept ‘just in case’ you have a need for it in the future.

As long as one of your purposes still applies, you can continue to store the data.

You should also consider your legal and regulatory requirements to retain data. For example, when the data is subject to tax and audits, or to comply with defined standards, there will be data retention guidelines you must follow.

You can plan how your data will be used and if it will be needed for future use by creating a data flow map. This process is also helpful when it comes to locating data and removing it once your retention period expires.

There are two ways you can avoid data retention deadlines. The first is by anonymising data; this means that the information cannot be connected to an identifiable data subject.

If your data is anonymised, the GDPR allows you to keep it for as long as you want.

You should be careful when doing this, however. If the information can be used alongside other information the organisation holds to identify an individual, then it is not adequately anonymised.

You can also circumvent data retention deadlines if the information is being kept for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes.

You have two options when the deadline for data retention expires: delete it or anonymise it.

If you opt to delete the data, you must ensure all copies have been discarded. To do this, you will need to find out where the data is stored. Is it a digital file, hard copy or both?

It’s easy to erase hard copy data, but digital data often leaves a trace and copies may reside in forgotten file servers and databases.

To comply with the GDPR, you will need to put the data ‘beyond use’. All copies of the data should be removed from live and back-up systems.

Your data retention policy should be part of your overall information security documentation process.

The first step is to gain a full picture of exactly what data you’re processing, what it’s being used for and which regulations apply to your business.

These regulations include, but aren’t necessarily limited to, the GDPR. For example, if you process individuals’ debit or credit card information, you may be subject to the PCI DSS (Payment Card Industry Data Security Standard).

Similarly, if you intend to comply with ISO 27001, the international standard that describes best practice for information security, you must take note of its requirements.

These compliance requirements will dictate what information must be included in your policy and the rules it should follow.

A simple data retention policy will address:

Going through your data retention policy regularly allows you to clean house and remove duplicated and outdated files to avoid confusion and expedite any necessary searches.

The ICO (Information Commissioner’s Office) defines a personal data breach as any event that results in “the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data”.

This includes incidents that involve:

Organisations must create a procedure that helps them respond in the event of a personal data breach.

This requirements for this are outlined in Article 33 and Article 34 of the GDPR.

To comply with the EU GDPR (General Data Protection Regulation), organisations need to map their data flows to assess privacy risks.

Conducting a data flow map forms part of your Article 30 documentation. They are also an essential first step in completing a DPIA (data protection impact assessment).

Article 32 of the GDPR sets out the technical and organisational measures that organisations should implement to protect the personal data that they store.

The Regulation doesn’t go into specific detail about what these processes should look like, because best practices – particularly when it comes to technology – change rapidly and what is considered appropriate now might not be in a few years.

However, what is absolute is that any measures you implement should focus on the ‘security of processing’, which is Article 32’s sub-header.

That means looking at the ways you store and protect personal data, and particularly at preventing data breaches as well as physical or technical incidents.

There are many other factors that go into GDPR compliance – such as your level of transparency with data subjects and your purpose(s) for processing their information – but these concerns can all be put aside for the moment.

To comply with Article 32, you need to identify and mitigate risks that are presented by data processing, “in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed”.

So how can you do that? Let’s take a look.

Every organisation operates uniquely and has its own risks, so there is no single set of data protection practices that work for everyone.

That’s why the GDPR requires you to implement defences that are appropriate to your circumstances and the risks that you face.

This could include:

To help you stay on top of your Article 32 obligations, the UK’s data protection authority, the ICO (Information Commissioner’s Office), has created a compliance checklist.

Transfers of personal data are defined as restricted if:

To comply with the GDPR, you must consider the following factors:

The GDPR advises organisations to pseudonymise and/or encrypt all personal data.

This won’t stop malicious actors accessing the information altogether, but it will make it much harder for them.

Pseudonymisation masks data by replacing identifying information with artificial identifiers.

Although it is central to protecting data – being mentioned 15 times in the GDPR – and can help protect the privacy and security of personal data, pseudonymisation has its limits, which is why the GDPR also mentions encryption.

Encryption also obscures information by replacing identifiers with something else.

But whereas pseudonymisation allows anyone with access to the data to view part of the data set, encryption allows only approved users to access the full data set.

Pseudonymisation and encryption can be used simultaneously or separately, and although neither requires technical knowledge to implement, the difficulty for organisations is in putting in place suitable security policies and procedures and making staff aware of their obligations.

In July 2020, the ECJ (European Court of Justice) declared that the EU–US Privacy Shield – which organisations had used to make transatlantic personal data transfers – was no longer valid.

The decision came in the wake of complaints from the Austrian privacy activist Max Schrems, who argued that the US government’s mass surveillance practices contradict the protections that the Privacy Shield was supposed to provide.

The 5,000 or so organisations that currently use the framework will now have to rely on SCCs (standard contractual clauses), which are legal contracts that outline the terms and conditions for data transfers.

Schrems also challenged the validity of these, and although the ECJ chose not to abolish them, it did restrict their applicability.

Organisations and regulators must conduct case-by-case analyses of SCCs to determine whether protections concerning government access to data meet EU standards.

This will be a difficult task for all organisations, because to avoid a GDPR violation, you will need expert guidance.

The first thing you should do is work out the extent to which you’re already complying with the GDPR.

You’re probably meeting some of the Regulation’s requirements already, albeit in an unfocused way, so the scale of the task won’t be quite as big as you might have feared.

There will, of course, be many areas where you aren’t compliant. You can determine these by carrying out a gap analysis. This process identifies where your existing processes fall short of the Regulation’s requirements and helps you understand what you need to do to bring them up to standard.

The GDPR requires you to implement “appropriate technical and organisational measures” to ensure the security and privacy of the personal data your organisation processes.

To determine what’s appropriate, you should conduct a risk assessment. Only by evaluating the threats you face and your ability to deal with them can you establish a level of security that can adequately protect your organisation’s information assets in line with the GDPR – while keeping your expenditure within budget.

The GDPR requires every employee with permanent or regular access to personal data to receive appropriate data protection training.

Beyond this requirement, it’s important to recognise that information security is a responsibility for every employee, regardless of their level of access to personal data.

As well as ensuring that all your staff have a good understanding of the GDPR and information security, you’ll benefit from having a few individuals with more in-depth knowledge.

Some organisations will be required to appoint a DPO (Data Protection Officer), who provides an independent assessment of the organisation’s GDPR compliance activities. Organisations should also encourage managers and those closely involved with data processing to take advanced GDPR training courses.

GDPR compliance is too complex to maintain without a formal structure – especially as the Regulation places such a strong emphasis on documentation. Article 30, for example, requires data controllers to keep written records of data processing activities, including:

It’s also a good idea to keep written records of the lawful basis for processing and data processor agreements.

DPIAs (data protection impact assessments) are a form of risk assessment that identify any compliance issues that might arise as a result of data processing.

They are a useful accountability tool when it comes to GDPR compliance, as the results help you demonstrate that you have taken the appropriate technical and organisational measures required by the Regulation.

It’s particularly important to carry out a DPIA when introducing new processes, systems or technologies for processing personal data.

Article 15 of the GDPR grants data subjects the right to access their personal data from data controllers so that they can understand – and check the lawfulness of – how it is processed.

A request to access personal data is known as a DSAR (data subject access request), sometimes referred to as a SAR.

Access requests are not new, but the GDPR introduced changes that make responding to them more challenging.

For example, organisations may no longer charge a fee, except in certain circumstances, and now have less time to respond – one calendar month rather than 40 days.

DSARs do not have to be made in writing, and can be made to any member of staff, so it’s essential to ensure that everyone in your organisation can recognise a DSAR when they receive one. You should also have a proper procedure in place that every staff member can follow.

GDPR compliance is ongoing, not a one-off task. Merely having the right procedures in place does not mean you are – and will remain – compliant.

You need to regularly monitor and audit your compliance. This means documenting your processes and procedures, and regularly checking them to ensure they’re still fit for purpose, in line with the Regulation’s accountability principle.

An organisation must always document the reason it’s processing personal data. The GDPR outlines six lawful bases that will be appropriate in different circumstances:

Before the GDPR, consent was considered the easiest way to process personal data lawfully, but the Regulation has not only toughened consent requirements but also made it impossible for organisations to use consent to collect employees’ personal data.

That’s because it states that consent can’t be freely given if there’s an imbalance of power, which would be the case between an employee and employer.

HR departments must therefore seek an alternative legal basis, the most appropriate generally being contractual necessity, a legal obligation or legitimate interests.

They may be colleagues, but when it comes to their personal data, you must treat everyone in your organisation as data subjects in the same way as you would with customers or clients.

That means making them aware of their rights concerning the way your organisation processes personal information. There are eight data subject rights:

The right of access is by far the most commonly accessed, because employees tend to review the way an organisation processes their data before lodging a complaint.

Your data protection policy must state that employees are welcome to submit a DSAR (data subject access request) and explain how they can do this.

There shouldn’t be a formal process; any written or verbal DSAR will do, even if it’s as simple as an employee saying, ‘I’d like to see what data you’re keeping on me’.

As such, everyone in the HR department should be trained to recognise when a request has been made and the process they should follow to ensure they get the requisite information and respond within the one-month deadline.

HR departments receive vast amounts of personal data whenever they post a job opening. CVs or applications will contain names, addresses, email addresses and employment history.

As with employee data, you must explain both your lawful basis for processing and how applicants can exercise their data subject rights. You could put this on the application form or link to it on your job posting.

Although the documentation process should be relatively straightforward – it’s generally accepted that you need to provide personal details when applying for a job – you should pay attention to data retention.

The GDPR states that organisations can only keep personal data for as long as it’s necessary for the purpose that it was collected. UK employers are legally required to hold on to job applications for six months, in case a candidate lodges a discrimination case.

However, you might want to retain data for longer than this – for example, if an applicant is unsuccessful on this occasion but might be suitable for future roles. This is an example of legitimate interests, and your data retention policy should state this if there’s a chance that you might want to hold on to applications.

There’s a good chance your organisation already has an acceptable use policy. They clearly explain that employees are supposed to be spending their time in the office working, giving employers reasonable grounds to discipline or punish those who don’t spend enough time doing their job.

But those who ignore this policy are not only slacking off but also potentially jeopardising the organisation’s security.

Many of the disreputable websites that organisations ban are renowned sources of malware and viruses, which can cripple networks or, in the case of keyloggers, surreptitiously siphon sensitive information.

Employees should also be instructed not to download files from untrustworthy sites or their personal email accounts. The organisation’s spam filters and anti-malware technology don’t extend to personal emails, so it only takes one employee clicking a phishing email to infect the whole organisation.

You must therefore make it clear that acceptable use policies are as much about data protection as they are about ensuring a productive workforce.

Although organisations might be tempted to implement monitoring tools to make sure employees follow acceptable use policies, they should be very careful about how they do this.

Employers are entitled to keep an eye on what their staff do during office hours, but both CCTV footage and browser histories are considered personal data under the GDPR, so organisations need a lawful basis before processing it.

They must also be as deliberate and as unobtrusive as possible in their monitoring. Under no circumstances are employers justified in using exhaustive or automated monitoring methods (such as spyware) to look through an employee’s browser history and workplace communications on the off-chance that they’ll find evidence of misuse.

Employers should also refrain from methods that leave no trace of their monitoring, such as physically sitting at the employee’s computer and looking through their private communications.

Let’s start with the basics. The GDPR is concerned only with personal data – i.e. information that relates to a natural person, as opposed to company details. It’s only when personal data is breached that you need to consider your GDPR compliance requirements.

But ‘breach’ here doesn’t simply refer to cyber attacks. Article 4 of the Regulation defines a personal data breach as any event leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.

As this definition suggests, data breaches aren’t always a result of cyber criminals hacking into an organisation’s systems. Breaches are just as likely to occur when an employee:

Incidents that render organisations unable to access systems containing personal data are also considered data breaches, such ransomware attacks or damaged hardware, because the information is no longer accessible.

Data breaches only need to be reported if they “pose a risk to the rights and freedoms of natural living persons”.

This generally refers to the possibility of affected individuals facing economic or social damage (such as discrimination), reputational damage or financial losses.

Most data breaches fit into this category, but those that don’t include information that are linked to a specific individual are unlikely to pose a risk.

Whether you are required to report a data breach or not, the GDPR mandates that you keep a record of it.

Whether it’s due to misunderstanding the GDPR’s compliance or an abundance of caution, many organisations overlook the difference between recordable and reportable data breaches.

This is a trend that John Potts, Head of DPO, DSAR & Breach Support at GRCI Law, has noted since the GDPR took effect on 25 May 2018.

Speaking to IT Governance, he explained that organisations often report every incident they experience, because they “want to inform the ICO before someone else does, so they can get their side of the story in first.”

Potts acknowledges that it’s best to err on the side of caution if you’re unsure whether a data breach needs to be reported, but urges organisations to take the opportunity to consider this rather than going straight into reporting mode. The Information Commissioner’s Office help line is always on hand to offer advice.

Potts added that organisations should be concerned not only about over-reporting incidents but also what is initially reported.

“In my experience, the ICO appreciates that sometimes all the details of the breach may not be known at the initial stage of reporting. It is more important that the rights of the data subject are protected as soon as possible rather than an organisation try to get their mitigation across to the ICO when they may not have a full picture,” he said.

“This desire to ‘fill in the form’ can lead to a knee-jerk reaction, meaning that the ICO and the organisation can go off on unnecessary avenues of investigations,” he added.

Data breach notifications need to be sent to your supervisory authority. For organisations in the UK, this is the ICO.

Your report must contain:

The GDPR acknowledges that it may be difficult to produce this much information within 72 hours, but the important thing is to demonstrate that you’ve made progress.

You don’t need to be obsessed over an exact 72-hour deadline. It is far more important that the risks to the data subjects are addressed.

The timings of breaches are not an exact science; if you find yourself approaching the 72-hour deadline, contact the ICO with the specific not speculative details that you have.

A swift response that’s documented clearly but sent a few hours late is better than a shoddy response that was rushed in order to meet the disclosure deadline, Potts advises.

The emphasis is on protection of the rights and freedoms of the data subjects. Any breach that is likely to attract media interest should be reported to the ICO at the very earliest opportunity.

Potts concluded by reminding organisations that, although not covered specifically by the GDPR, in the event of a reportable breach they may have a legislative duty to inform other statutory bodies such as the CQC or if they are OES (operators of essential services) or an RSDPs (relevant digital service providers); under the Network and Information Systems Regulations 2018, they will need to report the breach to relevant regulatory body.

It’s worth adding that your investigation can – and probably should – continue beyond the notification deadline.

More information will come to light as you analyse what went wrong and speak to those involved, and you can provide those details to the ICO where necessary.

Once you’ve informed the ICO of the incident, you’ll receive an automatic email to confirm receipt of your disclosure.

The incident will then go into a list of active cases that the ICO will look into to in due course. You will generally hear back quite quickly if the investigators are happy with your actions.

If the ICO suspects a GDPR violation, however, it may begin a formal investigation. These can take several months to complete, thanks to a backlog in cases and the back-and-forth nature of providing documentation and talking to relevant employees. In the event that the breach constitutes a criminal offence, they may instigate a criminal investigation.

That said, the ICO are likely to prioritise the case if the incident involves a serious breach affecting a lot of data subjects or is likely to attract media attention.

We’ve seen this already with July 2019’s ruling on Marriott International’s massive data breach. The breach was disclosed in November 2018, and the ICO came back with a verdict just over seven months later, announcing its intention to fine the hotel chain £99 million.

Failing to report an incident is a violation of the GDPR and is punishable by a fine.

That doesn’t mean you should expect a barrage of financial penalties, though. The ICO has repeatedly said that fines will be a last resort and only issued for egregious or repeat offences.

That’s not to say failure to notify won’t come with any form of penalty.

The ICO can discipline organisations in other ways, such as enforcement actions and audits.

If this happens, your compliance measures will be scrutinised, weaknesses will be flagged and you’ll be required to make the appropriate changes.

Some organisations have criticised this approach, saying that the data breach should be punishment enough.

However, Information Commissioner Elizabeth Denham insists that the ICO’s response measures aren’t punishments.

The biggest blunders in data privacy (and the cause of many data breaches) comes from a basic lack of understanding of the GDPR’s requirements.

So what should you do?

Achieving GDPR Compliance shouldn’t feel like a struggle. This is a basic checklist you can use to harden your GDPR compliancy.

If your organisation is determining the purpose of the storage or processing of personal information, it is considered a controller. If your organisation stores or processes personal data on behalf of another organisation, it is considered a processor. It is possible for your organisation to have both roles. Use the filter below to view only the relevant checklist items for your organisation.

This list is far from a legal exhaustive document, it merely tries to help you overcome the struggle.

You should start to fill out the Questionnaire at the start of any major project involving the use of personal data, or if you are making a significant change to an existing process. The final outcomes should be integrated back into your project plan.

Submitting controller details

Step 1: Identify the need for a DPIA

Step 2: Describe the processing

Step 3: Consultation process

Step 4: Assess necessity and proportionality

Step 5: Identify and assess risks

Step 6: Identify measures to reduce risk

Step 7: Sign off and record outcomes

ACCOUNT_JOB_COMPANY (the “Company”) respects the privacy of its online visitors and customers of its products and services (including, but not limited to QiCYCLE) and complies with applicable laws for the protection of your privacy, including, without limitation, the European Union General Data Protection Regulation ("GDPR") and the Swiss and EU Privacy Shield Frameworks.

1. Definitions

Wherever we talk about Personal Data below ("Personal Data"), we mean any information that can either itself identify you as an individual ("Personally Identifying Information") or that can be connected to you indirectly by linking it to Personally Identifying Information, for example:

(i) your account registration information on our website and in our App;

(ii) when you request any support from us or report any problem to us;

(iii) information provided from using certain services or features;

(iv) information from completion of survey or questionnaire;

(v) technical information, including the Internet protocol (IP) address used

(vi) and your log-in information, browser, time zone setting, browser plug-in types and versions, operating system and platform;

(vii) details of any transactions, purchases and payments you made;

(viii) your general interaction with the website, including the full Uniform Resource Locators (URLs), clickstream to, through and from our site, products you viewed or searched for, page response times, download errors, length of visits to certain pages, page interaction information;

(ix) information received from third parties, such as business partners, sub-contractors, payment and delivery services, referral by other users.

The Company also processes anonymous data, aggregated or not, to analyze and produce statistics related to the habits, usage patterns, and demographics of customers as a group or as individuals. Such anonymous data does not allow the identification of the customers to which it relates. the Company may share anonymous data, aggregated or not, with third parties. Please be aware that the Company may choose to permit third parties to offer subscription and/or registration-based services through the Company’s site. The Company shall not be responsible for any actions or policies of such third parties and you should check the applicable privacy policy of such party when providing personally identifiable information.

By using the Company’s website, you signify your assent to the Company’s privacy policy. If you do not agree to this policy, please do not use the Company’s website(s).

2. Why the Company Collects and Processes Data

The Company collects and processes Personal Data for the following reasons:

(a) performing our agreement with you to provide content and services, including providing, improving and developing our services;

(b) researching, designing and launching new features or products;

(c) providing you with alerts, updates, materials or information about our services or other types of information that you requested or signed up to;

(d) collecting overdue amounts;

(e) responding or taking part in legal proceedings, including seeking professional advice, or for the purposes of the legitimate and legal interests of the Company or a third party (e.g. the interests of our other customers);

(f) compliance with legal obligations that we are subject to;

(g) communicating with you and responding to your questions or requests;

(i) purposes directly related or incidental to the above; or

(j) where you have given consent to it.

These reasons for collecting and processing Personal Data determine and limit what Personal Data we collect and how we use it (section 3. below), how long we store it (section 4. below), who has access to it (section 5. below) and what rights and other control mechanisms are available to you as a user (section 6. below).

3. What Data We Collect and Process

3.1 Basic Account Data

When setting up an Account, the Company will collect your email address and country of residence. You are also required to choose a user name and a password. The provision of this information is necessary to register a User Account. You are responsible for keeping this password confidential. We ask you not to share a password with anyone.

During setup of your account, the account is automatically assigned a number (the "ID") that is later used to reference your user account without directly exposing Personally Identifying Information about you.

3.2 Transaction and Payment Data

In order to make a transaction online, you may need to provide payment data to the Company to enable the transaction. If you pay by credit card, you need to provide typical credit card information (name, address, credit card number, expiration date and security code) to the Company, which the Company will process and transmit to the payment service provider of your choice to enable the transaction and perform anti-fraud checks. Likewise, the Company will receive data from your payment service provider for the same reasons.

3.3 Other Data You Explicitly Submit

We will collect and process Personal Data whenever you explicitly provide it to us or send it as part of communication with others, e.g. in forums, chats, or when you provide feedback or other user generated content. This data includes:

(a) Information that you post, comment or follow in any of our Content and Services;

(b) Information sent through chat;

(c) Information you provide when you request information or support from us or purchase Content and Services from us, including information necessary to process your orders with the relevant payment merchant or, in case of physical goods, shipping providers;

(d) Information you provide to us when participating in competitions, contests and tournaments or responding to surveys, e.g. your contact details.

3.4 Your Use of the Websites

We collect a variety of information through your general interaction with the websites, Content and Services offered by us. Personal Data we collect may include, but is not limited to, browser and device information, data collected through automated electronic interactions and application usage data. Likewise, we will track your process across your websites and applications to verify that you are not a bot and to optimize our services.

3.5 Your Use of Services and other Subscriptions

In order to provide you with services, we need to collect, store and use various information about your activity in our Content and Services. "Content-Related Information" includes your ID, as well as information about your preferences, progress, time spent, as well as information about the device you are using, including what operating system you are using, device settings, unique device identifiers, and crash data.

3.6 Tracking Data and Cookies

We use "Cookies", which are text files placed on your computer, to help us analyze how users use our services, and similar technologies (e.g. web beacons, pixels, ad tags and device identifiers) to recognize you and/or your device(s) on, off and across different devices and our services, as well as to improve the services we are offering, to improve marketing, analytics or website functionality. The use of Cookies is standard on the internet. Although most web browsers automatically accept cookies, the decision of whether to accept or not is yours. You may adjust your browser settings to prevent the reception of cookies, or to provide notification whenever a cookie is sent to you. You may refuse the use of cookies by selecting the appropriate settings on your browser. However, please note that if you do this, you may not be able to access the full functionality of our websites. When you visit any of our services, our servers log your global IP address, which is a number that is automatically assigned to the network your computer is part of.

3.7 Third Party Services

This website uses GoogleLogin,Facebook Login ("Third Party Service"). Third Party Service uses "cookies", which are text files placed on visitors' computers, to help the website operators analyze how visitors use the site. The information generated by the cookie about the visitors' use of the website will generally be transmitted to and stored by Third Party Service on servers in the [United States]. Please be aware that Company cannot or does not control the use of cookies or the resulting information by the Third Party Service.

On behalf of the website operator, Third Party Service will use this information for the purpose of evaluating the website / location / credentials for its users, in order to compile reports on website activity, and to provide other services relating to website activity and internet usage for website operators.

Third Party Service will not associate the IP address transferred any other data held by the Company. You may refuse the use of cookies by selecting the appropriate settings on your browser. However, please note that in this case you may not be able to use the full functionality of this website.

3.8 Content Recommendations

We may process information collected under this section 3 so that content, products and services shown on the pages and in update messages displayed when launching the service can be tailored to meet your needs and populated with relevant recommendations and offers. This is done to improve your customer experience.

Subject to your separate consent or where explicitly permitted under applicable laws on email marketing, the Company may send you marketing messages about products and services offered by the Company to your email address. In such a case we may also use your collected information to customise such marketing messages as well as collect information on whether you opened such messages and which links in their text you followed.

You can opt out or withdraw your consent to receive marketing emails at any time by either withdrawing the consent on the same page where you previously provided it or clicking the "unsubscribe" link provided in every marketing email. Notwithstanding any opt out of promotional or marketing emails by you, we reserve the right to contact you regarding account status, changes to the user agreement and other matters relevant to the underlying service and/or the information collected.

3.9 Information Required to Detect Violations

We collect certain data that is required for our detection, investigation and prevention of fraud, cheating and other violations of the applicable laws ("Violations"). This data is used only for the purposes of detection, investigation, prevention and, where applicable, acting on of such Violations and stored only for the minimum amount of time needed for this purpose. If the data indicates that a Violation has occurred, we will further store the data for the establishment, exercise or defense of legal claims during the applicable statute of limitations or until a legal case related to it has been resolved. Please note that the specific data stored for this purpose may not be disclosed to you if the disclosure will compromise the mechanism through which we detect, investigate and prevent such Violations.

4. How We Store Data

4.1 Period of Storage

We will store your information as long as necessary to fulfil the purposes for which the information is collected and processed or — where the applicable law provides for longer storage and retention period — for the storage and retention period required by law. In particular, if you terminate your User Account, your Personal Data will be marked for deletion except to the degree legal requirements or other prevailing legitimate purposes dictate a longer storage. All your data and credits will be lost after deletion.

4.2 Deletion of Data

In cases where Personal Data cannot be completely deleted in order to ensure the consistency of the system, the user experience or the community, your information will be permanently anonymized. Please note that the Company is required to retain certain transactional data under statutory commercial and tax law for a period of up to ten (10) years.

If you withdraw your consent on which a processing of your Personal Data, we will delete your Personal Data without undue delay to the extent that the collection and processing of the Personal Data was based on the withdrawn consent.

If you exercise a right to object to the processing of your Personal Data, we will review your objection and delete your Personal Data that we processed for the purpose to which you objected without undue delay, unless another legal basis for processing and retaining this data exists or unless applicable law requires us to retain the data.

4.3 Location of Storage

The data that we collect from you may be transferred to, and stored at Hong Kong, or a destination outside of your jurisdiction. It may also be processed by third parties who operate outside of your jurisdiction. By submitting your personal data you agree to this transfer, storing or processing of data outside of your jurisdiction. We will take all steps reasonably necessary to ensure that your data is treated securely in accordance with this privacy policy.

5. Who Has Access to Data

5.1 The Company and its subsidiaries may share your Personal Data with each other and use it to the degree necessary to achieve the purposes listed in section 2 above. This includes our overseas offices, affiliates, business partners and counterparts (on a need-to-know basis only). In the event of a reorganization, sale or merger we may transfer Personal Data to the relevant or proposed transferees of our operations (or a substantial part thereof) in any part of the world.

5.2 We may also share your Personal Data with our third party providers that provide customer support services in connection with goods, Content and Services distributed via us. Your Personal Data will be used in accordance with this Privacy Policy and only as far as this is necessary for performing customer support services.

5.3 We may also share your information with our personnel, agents, advisers, auditors, contractors, financial institutions, and service providers in connection with our operations or services (for example staff engaged in the fulfilment of your order, the processing of your payment and the provision of support services); persons under a duty of confidentiality to us; or persons to whom we are required to make disclosure under applicable laws and regulations in any part of the world.

5.4 In accordance with internet standards, we may also share certain information (including your IP address and the identification of content you wish to access) with our third party network providers that provide content delivery network services and server services in connection with us. Our content delivery network providers enable the delivery of digital content you have requested, by using a system of distributed servers that deliver the content to you, based on your geographic location.

5.5 The Company may allow you to link your User Account to an account offered by a third party. If you consent to link the accounts, the Company may collect and combine information you allowed the Company to receive from a third party with information of your User Account to the degree allowed by your consent at the time. If the linking of the accounts requires the transmission of information about your person from the Company to a third party, you will be informed about it before the linking takes place and you will be given the opportunity to consent to the linking and the transmission of your information. The third party’s use of your information will be subject to the third party’s privacy policy, which we encourage you to review.

5.6 The Company may release Personal Data to comply with court orders or laws and regulations that require us to disclose such information.

5.7 We make certain data related to your User Account available to other users. This information can be accessed by anyone by querying your ID. At a minimum, the public persona name you have chosen to represent you are accessible this way. The accessibility of any additional info about you can be controlled through your user profile page; data publicly available on your profile page can be accessed automatically. While we do not knowingly share Personally Identifying Information about you such as your real name or your email address, any information you share about yourself on your public profile can be accessed, including information that may make you identifiable.

5.8 The community includes message boards, forums and/or chat areas, where users can exchange ideas and communicate with each other. When posting a message to a board, forum or chat area, please be aware that the information is being made publicly available online; therefore, you are doing so at your own risk; and that such information can be collected, correlated and used by third parties and may result in unsolicitated messages from other posters or third parties and these activities are beyond our control. If your Personal Data is posted on one of our community forums against your will, please use the reporting function and the help site to request its removal.

6. Your Rights and Control Mechanisms

You have the right to:

(a) check whether we hold personal data about you;

(b) access any personal data we hold about you;

(c) require us to correct any inaccuracy or error in any personal data we hold about you;

(d) request for the deletion of your personal data through the deletion of user account.

The data protection laws of the European Economic Area and other territories grant their citizens certain rights in relation to their Personal Data. While other jurisdictions may provide fewer statutory rights to their citizens, we make the tools designed to exercise such rights available to our customers worldwide.

As a resident of the European Economic Area you have the following rights in relation to your Personal Data:

6.1 Right of Access

You have the right to access your Personal Data that we hold about you, i.e. the right to require free of charge (i) information whether your Personal Data is retained, (ii) access to and/or (iii) duplicates of the Personal Data retained. You can use the right to access to your Personal Data through the Privacy Dashboard. If the request affects the rights and freedoms of others or is manifestly unfounded or excessive, we reserve the right to charge a reasonable fee (taking into account the administrative costs of providing the information or communication or taking the action requested) or refuse to act on the request.

6.2 Right to Rectification

If we process your Personal Data, we shall endeavor to ensure by implementing suitable measures that your Personal Data is accurate and up-to-date for the purposes for which it was collected. If your Personal Data is inaccurate or incomplete, you can change the information you provided via the Privacy Dashboard.

6.3. Right to Erasure

You have the right to obtain deletion by us of Personal Data concerning you by deleting your User Account via the support page.

As a result of deleting your User Account, you will lose access to services, including the User Account, Subscriptions and service-related information linked to the User Account and the possibility to access other services you are using the User Account for.

We allow you to restore your User Account during a grace period of 30 (thirty) days from the moment you request deletion of your User Account. This functionality allows you not to lose your account by mistake, because of your loss of your account credentials or due to hacking. During the suspension period, we will be able to finalize financial and other activities that you may have initiated before sending the User Account deletion request. After the grace period, Personal Data associated with your account will be deleted subject to section 4. above.

In some cases, deletion of your User Account, and therefore Personal Data deletion, is complicated. In some cases, considering the complexity and number of the requests, the period for Personal Data erasure may be extended, but for no longer than two further months.

6.4 Right to Object

When our processing of your Personal Data is based on legitimate interests according to Article 6(1)(f) of the GDPR / section 2.c) of this Privacy Policy, you have the right to object to this processing. If you object we will no longer process your Personal Data unless there are compelling and prevailing legitimate grounds for the processing as described in Article 21 of the GDPR; in particular if the data is necessary for the establishment, exercise or defense of legal claims.

You also have the right to lodge a complaint at a supervisory authority.

7. Children

The minimum age to create a User Account is 13. the Company will not knowingly collect Personal Data from children under this age. Insofar as certain countries apply a higher age of consent for the collection of Personal Data, the Company requires parental consent before a User Account can be created and Personal Data associated with it collected. The Company encourages parents to instruct their children to never give out personal information when online.

8. Contact Info

You can contact the Company’s Data Protection Officer at the address below.

While we review any request sent by mail, please be aware that to combat fraud, harassment and identity theft, the only way to access, rectify or delete your data is through logging in with your User Account at [email protected].

ACCOUNT_JOB_ADDRESS_MULTI_LINE

Attention: Privacy Officer

9. Revision Date

This privacy policy was last updated on 24 April 2021 ("Revision Date"). If you were a user before the Revision Date, it replaces the existing Privacy Policy. The Company reserves the right to change this policy at any time by notifying the users of the existence of a new privacy statement. This policy is not intended to and does not create any contractual or legal rights in or behalf of any party.

Goal of the data protection policy

The goal of the data protection policy is to depict the legal data protection aspects in one summarising document. It can also be used as the basis for statutory data protection inspections, e.g. by the customer within the scope of commissioned processing. This is not only to ensure compliance with the European General Data Protection Regulation (GDPR) and Data protection Act (DPA) 2018 but also to provide proof of compliance.

Preamble

Brief description of the company and motivation to comply with data protection.

Security policy and responsibilities in the company

Legal framework in the company

Documentation

Existing technical and organisational measures (TOM)

Appropriate technical and organisational measures that must be implemented and substantiated, taking into account, inter alia, the purpose of the processing, the state of the technology and the implementation costs. The description of the implemented TOM can, for example, be based on the structure of ISO/IEC 27002, taking into account ISO/IEC 29151 (guidelines for the protection of personal data). The respective chapters should be substantiated by referencing the existing guidelines.

Examples of such guidelines include:

The following are categories of information relating to an individual, whether it relates to his or her private, professional or public life. Categories are not exclusive. Information may transcend multiple categories.