<p>"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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <em>exactly</em> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-10-07T18:34:20.417Z
2017-10-07T18:34:20.417Z
AnoE
<p>With DevOps being a marriage between Dev and Ops (and even <a href="https://devops.stackexchange.com/questions/686/what-is-secops/694#694">SecOps</a>), I see different relationships with each one of them.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-10-08T15:39:45.617Z
2017-10-09T01:10:20.550Z
2017-10-09T01:10:20.550Z
Dan Cornilescu
<p>The <a href="http://www.eugdpr.org" rel="nofollow noreferrer">General Data Protection Regulation (GDPR)</a> is a set of rules to improve the protection of data about European citizens. Quote from this link:</p>

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

<p>Refer to <a href="http://www.eugdpr.org/key-changes.html" rel="nofollow noreferrer">GDPR Key Changes</a> for a summary of what it is all about, especially the <em>Data Subject Rights</em>, such as:</p>

<ul>
<li>Breach Notification.</li>
<li>Right to Access.</li>
<li>Right to be Forgotten.</li>
<li>Data Portability.</li>
<li>Privacy by Design.</li>
<li>...</li>
</ul>

<p>Some GDPR facts:</p>

<ul>
<li>GDPR will be <strong><em>enforced</em></strong> as of 25 May 2018 (that's pretty close).</li>
<li><p>Quote from <a href="http://www.eugdpr.org/key-changes.html" rel="nofollow noreferrer">GDPR Key Changes</a> (about <em>Territorial Scope</em>):</p>

<blockquote>
  <p>... 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. </p>
</blockquote></li>
</ul>

<p>For anybody who is old enough to remember the <em>Y2K</em>-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.</p>

<p><strong>Question(s)</strong>: What is the impact of GDPR on DevOps, more specifically I wonder about:</p>

<ol>
<li>What kind of changes will be needed in the DevOps <a href="/questions/tagged/toolchain" class="post-tag" title="show questions tagged &#39;toolchain&#39;" rel="tag">toolchain</a> to make them GDPR-compliant?</li>
<li>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?</li>
</ol>

CC BY-SA 3.0
2017-10-08T12:40:09.063Z
Could you explain how a `typical DevOps toolchain` looks like according to you?
030
CC BY-SA 3.0
2017-10-08T12:47:53.637Z
@030 please check my updated question (the link I added to clarify it).
Pierre.Vriens
CC BY-SA 3.0
2017-10-08T12:59:09.140Z
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
CC BY-SA 3.0
2017-10-08T13:33:43.847Z
I see that the toolchain tag already contains this information. The tag is clear enough.
030
<toolchain><data-protection><gdpr>
What's the impact of the General Data Protection Regulation (GDPR) on DevOps?
Pierre.Vriens
# What's the impact of the General Data Protection Regulation (GDPR) on DevOps?

(Asked by: username_0 on 2017-10-07)

The [General Data Protection Regulation (GDPR)](http://www.eugdpr.org) 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](http://www.eugdpr.org/key-changes.html) 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](http://www.eugdpr.org/key-changes.html) (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 [toolchain](/questions/tagged/toolchain "show questions tagged 'toolchain'") 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?

**Tags:** toolchain, data-protection, gdpr

> **Comments:**
> **username_1**: Could you explain how a `typical DevOps toolchain` looks like according to you?  
> **username_0**: @username_1 please check my updated question (the link I added to clarify it).  
> **username_1**: 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.  
> **username_1**: I see that the toolchain tag already contains this information. The tag is clear enough.  

---

## 2 answers

### Answer by username_2 on 2017-10-07. Score: 3

"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.


---

### Answer by username_3 on 2017-10-08. Score: 0

With DevOps being a marriage between Dev and Ops (and even [SecOps](https://devops.stackexchange.com/questions/686/what-is-secops/694#694)), 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.


---

