The General Data Protection Regulation (GDPR) is a set of rules to improve the protection of data about European citizens. Quote from this link:

The EU General Data Protection Regulation (GDPR) is the most important change in data privacy regulation in 20 years.

Refer to GDPR Key Changes for a summary of what it is all about, especially the Data Subject Rights, such as:

  • Breach Notification.
  • Right to Access.
  • Right to be Forgotten.
  • Data Portability.
  • Privacy by Design.
  • ...

Some GDPR facts:

  • GDPR will be enforced as of 25 May 2018 (that's pretty close).
  • Quote from GDPR Key Changes (about Territorial Scope):

    ... will apply to the processing of personal data by controllers and processors in the EU, regardless of whether the processing takes place in the EU or not. The GDPR will also apply to the processing of personal data of data subjects in the EU by a controller or processor not established in the EU, where the activities relate to: offering goods or services to EU citizens (irrespective of whether payment is required) and the monitoring of behaviour that takes place within the EU. Non-Eu businesses processing the data of EU citizens will also have to appoint a representative in the EU.

For anybody who is old enough to remember the Y2K-hype back in the 90s (i.e. the impact of it on IT systems): IMHO addressing all those Y2K issues was a piece of cake as compared to the challenge ahead with this GDPR thing.

Question(s): What is the impact of GDPR on DevOps, more specifically I wonder about:

  1. What kind of changes will be needed in the DevOps to make them GDPR-compliant?
  2. How can DevOps-practises help (facilitate, simplify, etc) a company to become GDPR-compliant, similar to how SCM tools helped in the 90s to become Y2K compliant?
  • Could you explain how a typical DevOps toolchain looks like according to you?
    – 030
    Commented Oct 8, 2017 at 12:40
  • @030 please check my updated question (the link I added to clarify it).
    – Pierre.Vriens
    Commented Oct 8, 2017 at 12:47
  • Thank you. Now it is clear to me what you mean with the typical devops toolchain. I have added the components that are depicted in the image to prevent that the information is lost if the link will be deprecated.
    – 030
    Commented Oct 8, 2017 at 12:59
  • I see that the toolchain tag already contains this information. The tag is clear enough.
    – 030
    Commented Oct 8, 2017 at 13:33

2 Answers 2


"Enforcing" means lawyers going after possible culprits. Frankly, in my opinion (and those of some folks around me which are more a mix between IT-guy and lawyer), nobody knows how that will work out exactly.

Those iLawyers expect a lot of very interesting court cases in the first months to tests out the water, and see what precedence cases are going to come up. There will probably be plenty of law firms fishing for nice fat fish to fry.

For me personally, I don't really see that much impact specifically regarding DevOps. The applications themselves need to be adapted as necessary, obviously. Also, the actual data storage, be it RDBMS, elastic search indexes or whatever, will have to be looked at.

Aside from that, one benefit of DevOps, specifically if you work with some kind of container system and infrastructure-as-code is that you should generally know exactly where your data, log files etc. is stored, and what kind of them you have; much more so than in classical servers, where your data and especially logs might be strewn all over the place. It should also be very easy to regularly roll your data as applicable, i.e., get lost of old stuff.

So it can help to, for example, take your catalogue of i-a-c files and walk through them diligently - you can then be pretty sure to have found everything you need to be aware of.


With DevOps being a marriage between Dev and Ops (and even SecOps), I see different relationships with each one of them.

From the Dev aspect DevOps can help with GDPR compliance just like it can help with any other type of compliance required from software products: via (good) compliance QA testing.

As long as the compliance requirements are well defined it is possible to devise corresponding QA testing to verify those requirements. Simply by incorporating those QA verifications inside the products' DevOps chain - in the CI/CD pipelines, for example, the products' compliance can be measured and controlled.

From the Ops (and SecOps) prospective things are a bit different (I'm less familiar with these), but I presume GDPR will impose additional requirements which I suspect would translate into additional operating policies.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.