GDPR for InfoSec Developers

[Illsteward]

Good day everyone,

I wonder if anyone of the residing experts would have some cues for me. I work in a small-ish (fewer than 50 employees) company that develops reservation software. This means that our product by definition processes personal data. I am currently the only InfoSec developer in house, so I have been tasked with preparing analysis and compliance statements regarding the software.

However, it seems as this scenario is hardly ever covered in any recommendations. We neither collect, nor store the data by ourselves, our clients do. In some cases, the data gets stored in our hosting provider DB, but still some large clients give us separate virtual machines to install the application to. This of course means that the install platforms and available security measures vary drastically, as well as the notion of "available privacy" - from almost paranoidly protected VMs with hosts of VPN, firewalls and security measures around them to almost publicly open servers on networks where public WiFis are able to see share servers.
While this situation is a nightmare from a standpoing of keeping the application itself consistent, now with GDPR loaming around, it can become a minefield, once we will have to abide to it. Anyone found themselves in similar situation, or have any ideas where to look?

Thanks a lot for any suggestions or pointers towards some "best practices".

[kratzy11]

First step should be - independent of GDPR - Make sure the PII is protected by encryption, tokenization, access controls etc. This applies for any PII that you handle, store, process.

Have you any idea how many of your "dataholders" are EU citizens vs non-EU citizens? I think the start for any GDPR analysis needs to start with how relevant GDPR is for your company/application. If you may have some EU data, but it is the exception, GDPR becomes much less of a headache than if you have significant presence in the EU. 

Next step would be a type of data mapping exercise to determine where such EU data may be stored (specific clients, in house or not etc.).

[MattyHiway]

The company I just joined offers tools that can help you build a Vendor Risk Management program...because after you take the INTERNAL steps that your other responder mentioned, you must think about the seemingly untrackable EXTERNAL ecosystems where your data might end up. Take a look at this doc, https://securityscorecard.com/blog/the-countdown-to-eu-gdpr-are-organizations-ready and if you'd like, reach out to me on LinkedIn https://www.linkedin.com/in/matthew-ancelin-cissp-cnse-3a566b11

[vds]

By what I read it sounds like you are actually part of data processing (Art. 4). In order to find out the safest way would be to talk to an expert. A consultant will ask you the right questions and clarify all your doubts. Before that it would be useful to ask if your customers already defined policies for GDPR compliance.

[Illsteward]

---

@kratzy11 wrote:

First step should be - independent of GDPR - Make sure the PII is protected by encryption, tokenization, access controls etc. This applies for any PII that you handle, store, process.

Have you any idea how many of your "dataholders" are EU citizens vs non-EU citizens? I think the start for any GDPR analysis needs to start with how relevant GDPR is for your company/application. If you may have some EU data, but it is the exception, GDPR becomes much less of a headache than if you have significant presence in the EU. 

Next step would be a type of data mapping exercise to determine where such EU data may be stored (specific clients, in house or not etc.).

---

Thanks. We already do some protection, however I have recently conducted and written an analysis that showed some seriously insecured points in our software, so we are working towards it. Also, most of our customers are EU-based, as well as the "dataholders", so GDPR is kinda important for us, and we get asked a lot by them...

[Illsteward]

Thanks. I will try to reach out my country's PII bureau and ask them about any contact persons that might be of help. I was already considering that route, but I wasn't sure whether GDPR applies to us at all (a lot of my colleagues still think it doesn't, sadly)

[mwapemble]

Hi,

There are a few things you need to consider.

Firstly, if you are hosting (or managing the hosting of, say on AWS) any instances of your application, then you will be acting as a data processor. You will need to consider your direct legal obligations under GDPR (start at Article 28) and ensure that the contracts between you and the data controllers meet the requirements of controller / processor contracts. And, of course, then abide by those contractual terms.

As a developer, even if you are not a data processor, you will still need to consider "Data Protection by design and default", Article 25, and possibly appropriate certification (once relevant schemes exist) of your application and SDLC. This will require DP to be a core part of the initial stages of the application development / improvement programme, with input to core decisions taken about (changes in) data collection, storage and subsequent processing.

You will also need to consider keeping appropriate records of decisions made about data processing (business or technical justifications for collection, retention policies, security etc), so that you can provide your customers (or yourself as a data processor) with the appropriate records to meet the Accountability requirements, Art 5(2).