Ultimate Startup Guide to Becoming GDPR Compliant for Companies That Aren’t Huge And Don’t Have $30,000 to Drop On GDPR Compliance Services

Octavian Naicu
20 min readMay 18, 2018

--

We’re big fans of BareMetrics so when it’s founder, Josh Pigford, tweeted about the need for an “Ultimate Startup Guide to Becoming GDPR Compliant for Companies That Aren’t Huge And Don’t have $30,000 to Drop On GDPR Compliance Services” we knew we’ll be taking on the challenge.

At Pipe, the company I started 2 years ago, we process thousands of videos per day with pretty much all of them containing personal data in the form of people talking so we were gearing up for GDPR for some time.

We wrote this article about the process to document our thinking, findings, and insights. It’ll come in handy when we’ll review our GDPR compliance or if UK’s Information Commissioner ever comes knocking. Hopefully it will also be useful to you as you go through your GDPR compliance process.

Keep in mind we’re not lawyers, so we’d advise taking legal advice where required. We’d also recommend that you give the legislation a read yourself, it’s available at https://gdpr-info.eu/ and it’s quite an easy read.

Short Intro to GDPR

Let me say it from the get-go: GDPR is awesome as it establishes the individual’s right to the protection of his or her personal data as a fundamental right (but not an absolute one). At the same time GDPR forces organizations to treat personal data with the same importance and rigorosity they treat taxes and VAT.

The EU General Data Protection Regulation (GDPR) is a new regulation approved by the EU Parliament in April 2016 after 4 years of negotiations and debate and it will be enforceable starting with the 25 May 2018.

The current legislation, the 95/46/EC directive from 1995, stops being active on the same day. GDPR builds on top of this current directive which was written in the dial-up era.

Because GDPR is a regulation and not a directive GDPR applies in ALL 28 EU member countries. For you as a company that’s great news because you only have to comply with one law across the whole of EU.

GDPR will be enforced by the local authorities entrusted with information rights in the 28 member countries like the ICO in UK or the ANSPDCP in Romania.

Most of the work you’ll have to do to comply with GDPR revolves around the 6 principles it establishes and around the 8 rights it gives individuals over their data, so let’s quickly overview them.

The 6 principles your organization has to comply with when dealing with personal data:

  1. data must be processed lawfully, fairly, transparently
  2. purpose limitation: It needs to be collected for specified, explicit and legitimate purposes
  3. data minimisation: data needs to be adequate, relevant and limited to what’s necessary
  4. accuracy: data must be correct and up to date
  5. storage limitation: data must be kept in a form that permits the identification of the data subject for no longer than is necessary
  6. integrity and confidentiality: data must be processed securely

The 8 rights individuals have over their data, rights you have to comply with. Under the GDPR all individuals have the right to:

  1. Be informed about what personal data you’re collecting
  2. Access their personal data
  3. Edit the data including data collected from a third party like Google or Facebook
  4. Request it’s deletion in case the personal data has been collected on the basis of consent or based on the legitimate interests of the controller
  5. Restrict processing in some rare corner cases detailed in Art. 18
  6. Object to processing in some common cases (when legitimate interests or public interest are used as a lawful basis and when data is processed for direct marketing or scientific/historical research)
  7. Download the personal data (provided by the individual) concerning him or her in a common format (csv, json,xml) when processing is based on consent or needed for the performance of a contract
  8. To not to be subject to a decision based solely on automated processing

These rights are not absolute though, meaning you can not walk in the bank from which you have just taken a loan and ask them to delete all your information under your new found right to be forgotten. You can not GDPR your way out of a bad loan!

Only some of the above rights are new, most of them were also present in the previous legislation. If all of them are new to you… then… the scaremongering fines of up to 4% of revenue worked.

Neglecting these 8 rights and 6 principles attracts the highest fines. Your organization might be fined a maximum of 2% for not respecting your obligations as a controller or processor but you’ll be fined up to of 4% for blatant infringements on the individual’s rights.

Does my company/startup/organization have to comply with GDPR?

The regulation is pretty clear, you do if you’re in one of these 2 cases:

1. Your company is established within the EU

If you’re established in the EU and process personal data, you have to comply with the GDPR. It does not matter where the persons whose personal data you’re processing are located. If you’re on the Moon and you’re dealing with an EU company, your data will be protected by the GDPR.

The common misconception that you only have to apply GDPR in relation to individuals in the EU. This rule applies only to non EU companies and only if they have to comply with GDPR at all which gets us to our 2nd case.

2. Your company is not established in the EU but you are targeting & offering goods or services to individuals located in the EU or monitoring their behavior in the EU

In this case, the regulation provides more detail and makes it clear that the mere existence of a company website accessible from the EU does not make for sufficient reasons to require GDPR compliance. But if your website is avb. in French or Spanish and customers can purchase in EUR then your company has to respect GDPR since you’re actively targeting EU individuals or companies. An even stronger indication would be if you ship products to EU.

Now it’s rather hard for the EU Courts to go after US companies without a presence in the EU but your EU business clients might care a lot if you’re compliant since they’re immediately facing those huge fines.

Basically, if your company is not in the EU and you want to sell products and services to individuals or companies in the EU you’ll have to respect EU’s GDPR regulation.

What does processing mean anyway?

Art. 4 of the GDPR describes “processing” as “any operation or set of operations which is performed on personal data or on sets of personal data” including:

  • accessing
  • collecting
  • organizing & structuring
  • storing
  • altering
  • retrieval
  • disclosing
  • deleting

What does qualify as personal data under the GDPR?

The GDPR defines personal data as “any information relating to an identified or identifiable natural person”.

That means:

  • Emails, names, phone numbers
  • Profile photos & avatars
  • Audio and video recordings
  • Twitter, Facebook, LinkedIn IDs and profile URLs
  • IPs (IPv4 and especially IPv6)
  • Biometric data like fingerprints (stored by some mobile devices), DNA or a person’s face (iPhone X has a pretty good idea how you look)
  • User agents, device names (like webcam names) or device ids like MAC addresses
  • Passport and Social security numbers
  • Driver’s license or ID photos
  • Geolocation info
  • Posts on social media
  • Bank account & credit card information, PayPal id
  • SSH public keys

You can process personal data that the user has explicitly provided, but also data that you have collected from either 3rd parties like Facebook or Google or based on their activities on the site (what they’ve been looking at, what they’ve purchased, etc.).

If you’re not really sure if something is personal data you would be wise to consider it personal data. Keep in mind that the 28 local authorities entrusted with enforcing the GDPR will be inclined to consider as much data as possible personal data because they lose jurisdiction when something is not personal data.

The GDPR also defines 7 categories of sensitive personal data:

  1. Racial or ethnic origin
  2. Political opinions
  3. Religious or philosophical beliefs
  4. Trade union membership
  5. Genetic data & biometric data processed for the purpose of uniquely identifying a person
  6. Data concerning health
  7. Sex life and sexual orientation (dating sites beware!)

Sensitive data as defined by the 7 categories above, children’s data and criminal record information have special rules for processing under the GDPR. We highly recommend you consult the full text of the GDPR and legal counsel if you process such data.

Step 1: Identify the personal data you’re processing

The most important step and one that all companies looking to be GDPR compliant will go through is to identify what kind of personal data they’re currently collecting, storing (including data they’ve collected in the past and not using) and further processing.

We for example process several types of personal data for our purposes:

  1. Personal data related to trial accounts: We directly collect the names and emails of all our trials through our sign up form. Some of them are now active clients, others have stopped paying for and using the service while the bulk of the data is represented by expired trial accounts.
  2. Website visitors: Our Apache web server automatically logs the IP, page, GET parameters and user agent in local access and error log files
  3. Current & Previous Employees: We collected the names, emails, salaries, addresses, social security numbers and other personal data of current (and previous) employees
  4. Candidates: We collected the names, emails and other personal data of all the candidates that applied for our job openings through job listing sites.
  5. Contractors: We collected the names, emails and other personal data of all our contractors’ legal representatives. They’re physically printed in the contracts in a neatly arranged cabinet in our office.

Under the GDPR we are Data Controllers in relation to the above data because we determine the purposes for processing personal data.

But we also process personal data for our customers:

  1. Video files: Each of the videos recorded through our platform contains the video data itself, an audio track, a snapshot of the video, and, sometimes, a geolocation tag (present in mobile videos),
  2. Metadata: For each of the videos we also save the names of the devices used, the IP, user agent and referer URL

Under the GDPR we are Data Processors in relation to the above data because we’re processing personal data on our customers’ behalf (on behalf of a controller who determines the purpose).

A word on processing data related to payments

If you’re using Stripe or Braintree for payments, you have a direct relationship with your clients so the email, name, address and other payment information they use when paying, pass directly on to you as a data controller. You’ll have to check with your accountant and local laws for how long you have to keep such data.

If you’re using Avangate or Paddle, they act as a reseller for your products and services. They invoice the customer and you invoice Paddle and Avangate. You’ll receive the data for order fulfillment and support either as a data processor, controller or joint controller.

Step 2: Identify the lawful basis and purpose for which it’s processed

Lawful basis

Under the GDPR, as per the 1st principle, all the above data must be lawfully processed meaning you either:

  1. have the individual’s consent to process the data through a big check mark when signing up
  2. need it for the performance of a contract for example when you need the shipping address to ship an item bought online
  3. need it for compliance with a legal obligation, for example, our company is obliged by law to keep records & resumes of all our current and former employees and billing records
  4. need it in order to protect the vital interests of the data subject or of another natural person
  5. need it for the performance of a task carried out in the public interest or in the exercise of official authority
  6. processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party

Different lawful basis and purposes

For each personal data you process (and purpose) you might rely on a different lawful basis.

We, for example, collect the name and email during sign up for the performance of a contract but we’ll be relying on consent for emailing them product updates and we are considering using legitimate interest for collecting user agents and device names as controllers from our client’s users as we need them to troubleshoot issues and thus improve our platform for our clients and their users.

Purpose

For each piece of data that you collect you also need to justify why you need it. Even if you rely on consent for collecting hordes of data you’re still liable for collecting data that you do not need, and that gets us to Step 3.

Step 3: Consider whether you really need all the data that you’re collecting and for how long.

If you don’t need it stop collecting it and delete the existing data.

Data minimisation and storage limitation

Under the GDPR companies are required to process only the data they need (data minimisation) and keep it for no longer than is necessary for the purposes for which the personal data are processed (storage limitation).

For example a few months ago we updated our video recording platform to collect device information at certain interaction points to try and identify/replicate a frequent bug. 6 months later, with the issue fixed, we do not need that information anymore so we’ll stop collecting it and delete the collected one.

Step 4: Thoroughly research where it’s stored

This is where you have to be careful as electronic data might be stored in:

  • a production database (remote or local)
  • a development database (remote, local or on a dev’s computer)
  • backups of the above databases
  • entire backups of your website or server
  • MySql binary and general logs store all SQL queries
  • web server logs will contain any data sent through GET
  • web server logs will contain the IP of each of your website visitors’ devices, the URL they visited and the user agent
  • development logs where you dump debug data
  • in your caching layer (Memcached, Redis, Cloudflare)
  • on your website hosting account
  • on any of the CDN’s edge servers
  • storage systems like Amazon S3
  • in Dropbox/Box accounts
  • downloaded or saved to your employee’s devices and laptops
  • feature requests or bugs reported added to the issue tracking system
  • tech support platforms like Groove or Zendesk or CRMs

You’ll need to know where personal data is stored because, when requested you have to be able to comply with the individual’s’ rights under the GDPR including the rights to access it, edit it and delete it.

Step 5: Update and simplify your privacy policy

Yay!

Individuals that sign up for your service or buy from you or get hired by you have the right to be informed upfront about how you’re processing their data so make sure you’re transparent about it in a revised, simple privacy policy.

Art. 13 of the GDPR lists all the bits of info your Privacy Policy needs to contain when collecting data directly from the person. Things like your company’s name and address, the legal basis (consent, needed for a contract, legitimate interests, etc…), purpose of processing, any recipients, the retention period for the data, the rights of the users in relation to personal data and more.

Art. 14 covers the scenario when personal data is not collected directly from the individual like when a MailChimp powered landing page collects names and emails for you as a data processor.

The 2 articles overlap a lot but the ICO has a good comparison table between the 2 cases.

Step 6: Update your sign up form

Stop collecting unneeded personal information

Make sure you do not collect unneeded information. For example, you do need an email to allow a user to sign in later and reset his or her password but do you really need the user’s gender, age or date of birth?

You might need to obtain regular consent

If you’re a SAAS providing services to businesses and individuals you might not need consent for collecting the email and billing details since you need the data for the performance of a contract but for many other purposes, companies should rely on consent to lawfully process data .

Keep in mind consent and performance of a contract are just 2 of the 6 lawful bases for processing data listed in Art. 6 of the GDPR.

Real Life Example

We rely on performance of a contract to collect emails during sign up and immediately send a welcome email + password reset emails but if I were to also add that email to a separate mailing list (think Groove’s Startup Journey or Twilio’s Dev Digest) or send drip emails I would need consent for that since it’s a different purpose and it’s not mandatory for the performance of the contract.

When you’re relying on consent, you, as a data controller, need to:

  • demonstrate that the data subject has given consent
  • collect consent for each purpose individually
  • permit the data subject to withdraw consent at any time for each purpose
  • inform the data subject about the right to withdraw consent

Explicit consent is required for sensitive personal data

As a data controller, you need explicit consent for processing sensitive data. For such data you can’t rely on the performance of a contract or legitimate interest as a lawful basis for processing, you need explicit consent. Consult the updated Guidelines on Consent for how explicit consent can be collected (namely through a written signed statement, by filing an electronic form, sending an email, scanned signed document, electronic signature, telephone conversation and thus audio recordings or two-stage verification).

Step 7: Collect proof of consent for your email list

If you’ve been relying on consent to add names and emails to your email list then you now also need to prove you’ve collected consent. It’s rather accepted that collecting the opt in IP and date + confirmation IP and date is a strong proof of consent (Do you see the irony in gathering more personal data as proof that you’re allowed to process personal data?).

If for your existing list you do not have proof of consent you will need to run several proof of consent gathering campaigns where your email subscribers re-opt-in to being on your email list. You’ve probably received a few such emails recently. All entries which don’t re-opt-in need to be removed from the list by the 25th of May.

You should also consider removing entries from the list as soon as they unsubscribe. Storing personal data has a lot of implications especially if you’re not using it.

Using legitimate interest for sending emails using soft opt-in

Companies can rely on legitimate interest to add people who sign up for their service to an email list if they’re given the chance to opt out (thus the term soft opt-in) and will only receive communciations around your products or services.

This workaround relies on the e-Privacy Directive (more specifically, in the UK, on Article 22.3 of the PECR) but the EU is in the process of replacing it with a new e-Privacy Regulation to sit alongside the GDPR.

ICO’s guidance on the PECR does a great job of explaining the reasoning:

The idea is that if an individual bought something from you recently, gave you their details, and did not opt out of marketing messages, they are probably happy to receive marketing from you about similar products or services even if they haven’t specifically consented. However, you must have given them a clear chance to opt out — both when you first collected their details, and in every message you send.

For more information on relying on legitimate interests for processing personal data for your direct marketing or e-mail marketing activities check out ICO’s GDPR guidance on the topic.

Step 8: Allow active accounts to view, edit, download & delete their personal data

Active accounts’ are the easiest to work with because of the active ongoing relationship with them.

As a controller, in order to comply with the data subject’s rights, for active accounts, make sure that once they’re logged in they can:

  • right view all their personal data (right of access)
  • edit all the personal data that could be inaccurate (right to rectification)
  • download the personal data they provided in a common format like CSV (right to data portability)
  • delete all the personal data that’s not critical to delivering a service (right to erasure).

Deleting critical personal data needed to deliver a service

Since deleting the email makes it impossible to keep an active account/subscription with Netflix & Apple Music (you’d have no way of resetting the password or recovering the account) and since deleting the delivery address makes it impossible for Amazon to ship items to you make it clear that deleting such personal data will attract the inability to provide your services. You can direct such users to the option to cancel their subscription/service or delete their accounts.

Deleting vs Anonymising

You should consider automatically deleting such data instead of archiving but anonymising it also works.

For your records & reporting you’ll want to know that an account was active from January to June but you don’t have to know that it was specifically Alexander McQueen’s account so you can easily replace his name (and all the other personal data) in database with “Anonymous Client 1” just like in the BareMetrics’ Live Demo.

You should do this:

  • when a user requests the deletion of personal data
  • automatically after a user’s account expires/is closed/etc.

Step 9: Allow persons who have left your service (trial/disabled/archived accounts) to view, edit, download & delete their personal data.

Previous clients but also trial, disabled or archived accounts also have rights over the personal data you store about them (the rights extend to previous employees, subcontractors and suppliers).

The easiest way to comply with their rights would be to allow them to log in just like active accounts. They’ll be able to easily view, edit & delete their data using the same infrastructure as active accounts.

Another solution would be to add a new GDPR page on your website which by virtue of an email (or some other form of authentication) plows through your database, storage systems, etc. collects all the data and emails it to them. They can email back to update the data or to ask for its deletion. If they do you have maximum 1 month to do it. Consider automating the process if you have lots of such requests (such requests are called data subject access requests under the GDPR). Using the email solves the authentication problem for them since they might not have an active account with you.

Step 10: Review those TOS no one reads (and your own)

It’s time for you to review all those Terms of Service you breezed through when you signed up for AWS, Digital Ocean, MailChimp, and Intercom.

Per Art. 28 of the GDPR the relation between the controller and the processor needs to be governed by a written contract (TOS), including in electronic form, which needs to contain:

  1. the subject-matter and duration of the processing,
  2. the nature and purpose of the processing,
  3. the type of personal data and categories of data subjects and
  4. the obligations and rights of the controller
  5. The 8 clauses mentioned under Art. 28 (3).

As expected all the big cloud providers have already updated or are in the process of updating their TOS (or Data Protection Addendums) to include the info required by the GDPR.

Nevertheless, my recommendation for you as a data controller is to:

  1. review the TOS for the services/vendors you use when processing data,
  2. make sure they include the info above
  3. print the TOS and put them in a dossier. These will come in handy whenever a service changes their TOS or when the ICO comes knocking on your door.

If you’re a data processor in relation to services you provide to data controllers you’ll also need to update your TOS to include the above info.

Step 11: Review data transfers to outside the EU or to international organizations.

A transfer of personal data to outside the EU or an international organization may take place where the Commission has decided that the country, a territory or one or more specified sectors within that third country, or the international organization in question ensures an adequate level of protection.

The European Commission has so far recognised:

  • Andorra,
  • Argentina,
  • Canada (commercial organizations),
  • Faroe Islands,
  • Guernsey,
  • Israel,
  • Isle of Man,
  • Jersey,
  • New Zealand,
  • Switzerland,
  • Uruguay and the
  • US (limited to the Privacy Shield framework)

as providing adequate protection(source).

Adequacy talks are ongoing with Japan and South Korea.

How about all our clients from India and Australia? Are we in breach of the GDPR when we transfer to their servers personal data captured from their users through us as data processors? Luckily, the illuminated minds in the European Commission have considered this situation and have provided derogations for specific situations including one where “the transfer is necessary for the performance of a contract between the data subject and the controller” or if “the data subject has explicitly consented to the proposed transfer”.

Transfers of personal data outside the EU, to any other country that’s not listed above, can also be made if the controller or processor has provided appropriate safeguards.

Also, keep in mind when reading up on GDPR the EU refers to countries outside the EU as ‘third countries’.

What am I facing for non-compliance ?

In short, you’re facing:

  1. Corrective actions from the supervisory authority
  2. Fines from the supervisory authority
  3. Damages in case of a lawsuit.
  4. Reputational damage: damaged brand/bad publicity.

Corrective actions

The 28 local supervisory authorities can impose a temporary or definitive limitation on data processing activities, including a complete ban on data processing, or to order the suspension of data flows to a recipient in a country outside the EU.

Fines

For flagrant infringements of the following GDPR provisions:

  • the 6 principles for processing, including conditions for consent
  • the 8 data subjects’ rights
  • international transfers
  • obligations under Member State laws
  • non-compliance with an order imposed by supervisory authorities or a failure to comply with a supervisory authority’s investigation

You can be fined a maximum fine of €20,000,000 or in the case of undertakings, up to 4% of global turnover, whichever is higher

Other infringements, like not complying with the obligations of the controller and the processor as set by the GDPR, are subject to administrative fines up to €10,000,000 or, in the case of undertakings, up to 2% of global turnover, whichever is higher.

Final Words

There’s a lot of cultural, business and technological change that needs to happen in your company. The challenge is not to be ready by the 25th of May but to internalize this new way of thinking about the personal data of individuals and forever change the way your company approaches it.

A lot of these requirements were already in the existing Directive from 1995 but for many companies, they’re new because:

  1. The new regulation might apply to businesses outside the EU
  2. The huge maximum fines suddenly put the problem of complying at the top of our priorities.

The 28 data protection agencies around the EU might become very important political instruments as they’ll have the power to fine a company or other public authority for up to 4% of revenue or 20M Euros.

GDPR protects the privacy rights of individuals around the world when they deal with EU companies and it also applies to some non-EU companies targeting individuals in the EU. GDPR might thus become the de facto standard for privacy around the world.

A word on web server logs (Apache, nginx, etc.)

Within the types of personal data you can collect, the IPv4, user agent and visited URLs data found in Apache logs feels very rudimental. There are better ways to track individual members of a family behind a home router, individual employees behind a corporate network or mobile devices on a 3G/4G network. Apache logs can, at most, tell you that someone behind a certain IP searched for product X on your ecommerce site but your ecommerce platform is already tracking that through cookies and profiling the visitor/customer since ages ago.

To be on the safe side you could configure Apache to delete access and error logs after 1 month as any subject access request, including requests to delete personal data, needs to be complied with “without undue delay and in any event within one month of receipt of the request”.

You can, however, keep such data for longer if you can justify the need to keep it (security comes to mind). I wouldn’t worry about having to edit data in Apache logs since the data (IP, visited URLs, user agent) is inherently correct (again, watch those GET parameters).

At the same time I wouldn’t worry about individuals requesting access or deletion of the Apache logs concerning a certain IP as I see no possible solution for the “reasonable measure to verify the identity of a data subject” against an IPv4 IP and, as per the GDPR, providing data to the wrong person could “affect the rights and freedoms of others” in which case you shouldn’t provide the data.

IPv6 is a different beast though.

A word on db backups.

Consider using replication instead of daily/hourly db dumps for backups. Replication ensures that any change made to personal data is immediately found in the (replicated) backup thus you’ll be in full compliance with the right to rectification and the right to erasure when switching to or restoring from the replicated backup.

If you’re using periodic dumps and you have to restore your db from a backup you’ll have to find a way to delete or correct the data that was deleted/edited since the last backup.

I’ve also seen companies move and unify all personal data in a different db, in a different location, with restricted access and a different backup policy.

Keep in mind this guide is targeted towards small companies. I’ve omitted several aspects like assigning a data protection officer, keeping records of processing activities, etc.

Further reading

GDPR — A PRACTICAL GUIDE FOR DEVELOPERS

This blog post is one of the best (and earliest) blog posts covering what a developer can expect to implement technically in a company to help the company comply with all the principles of processing and data subject’s rights under the GDPR. You can find it here.

A Stripe guide to the European privacy and data protection changes

In our work to comply we went through many partners’ and companies efforts to comply. We’ve seen no better and accurate understanding of the GDPR than Stripe’s. They have a great GDPR guide you should read even if you’re not using Stripe.

ICO’s Guide to the General Data Protection Regulation (GDPR)

If you’re in the EU and your country’s data protection agency guidance on GDPR compliance is lacking or nonexistent you can always follow the guidance from UK’s ICO.The GDPR regulation is the same across the EU and UK’s ICO guide is written in English, easy to follow while remaining closely linked to the legislation.

GDPR Hysteria
A great article covering 19 common myths around GDPR. You can find it here and I could not recommend it enough.

--

--