Introduction
Calling all developers! ... this stuff is important - please take a few minutes out to read it! :)
At the upcoming C-Sharp Corner Startup Conference in Delhi, I will be leading a session on Technology Law. One of the big trends at the moment is to ensure that we take care of data privacy for our users. This article looks at Data Privacy and protection and gives hints and tips on how developers should be thinking about things from their viewpoint.
Over the past few years there has been increasing awareness of data protection and privacy, with everything from the Sony Playstation breach to the recent Edward Snowden NSA revelations bringing the subject into the public eye. New European Union (EU) legislation is proposing fines to organisations of €100 million or 5% of their annual worldwide turnover, whichever is the greater - that's quite an incentive for companies to start getting their act together. As usual, when trouble hits the fan, expect developers to get it in the ear - this article serves as an introduction to developers about "DATA PROTECTION and PRIVACY legislation" and what it means for them. In India for example, the Adjudicating Officer can impose fines of up to US$700,000 for failure to protect data including sensitive personal information. For unlawful disclosure of information the penalty can even be 3 years of imprisonment.... as developers you will agree that with these punitive remedies, its worth looking at the area and seeing what we need to do so we don't end up being fined, or worse!!
This article is primarily focused on generic requirements by focusing on EU legislation. I mean by this that if you focus on what is covered here, it should be useful in general no matter the location. In the US for example, many organisations have signed up to "Safe Harbour" (which is now deemed unlawful, but is looking to be replace by the so called 'Privacy shield' regulations). An increasing amount of countries are implementing new privacy legislation, and the general principles in this article would apply to most of these. From an Indian point of view, the Information Technology Act 2000 applies, and really, if you abide by the core EU rules, you are doing very well in all territories that you, or your clients operate.
![image]()
Background
My own development background has focused the past 10 years in the Healthcare sector - as you can appreciate, this area is more concerned than most with protection of data and patient/consumer privacy. My interest in data security and need to know more led me to eventually getting certified in this area and I am always amazed at the lack of knowledge of the area - hopefully this will go a small way towards filling the gap at the frontline of data gathering!
I am not going to go into great detail on specifics, if you need this, there are many great resources waiting to be Googl'ed (or Bing'd!). At the end of this article, I give links to the website of all of the useful data protection offices for further detail. The main focus of this article is to discuss each area of the over-arching legislation in relation to how it might affect developers and operations.
![operations]()
The Rules
Data protection in EU countries is based on what's known as a "directive" - in this case, its 95/46/ec. The directive is prescriptive in some areas, and in others leaves things up to the interpretation of the national government. This means that in general, data protection and privacy legislation across the different countries of the EU is more or less the same, with some local differences. It's difficult to get things perfectly right in all jurisdictions, but if you start with the core rules, you are most of the way there.
- Obtain and process information fairly
The first rule states that any data/information you get about someone must be obtained and processed in a fair manner. The highlights of this rule means when you get information, you inform the user who your organisation is, what information you are taking, why you are taking it, and who will get to see it. You must also inform the user of their rights in relation to data privacy. Typically, you will do a lot of the advising in a privacy policy. Despite what our colleagues in marketing might have us believe, it is not ok to tell white lies to users, saying for example that data is being used for say a free prize draw, when in fact the intention is to send promotional emails at every opportunity. There are only three core ways to obtain and use data fairly (a) if you have the express permission of the user (b) if you have the implied permission by virtue of the fact that their data is being shared with you in order to perform a contract already in place with the user, (c) for specific legal/government reasons. From a development point of view, it is important that you record when and how the user gave permission. For example, Date/Time, User demographics, IP address, the context of the permission, and a copy/link to the privacy notice shown to the user to enable them to agree.
- Keep data only for specified, explicit and lawful purposes
This rule says that you can only keep the data you collect, if you use it for the reasons you told and agreed with the user (competition entry versus marketing spam), you inform the user clearly about the information you are gathering, and critically, you need to know exactly what kind of data you are gathering, and where it is stored. For developers, this opens up questions such as defining the type of data gathered, and keeping careful track of where it is stored, who has access, etc.
- Use and disclose only in ways compatible with the purpose
What this means is that how you use the data gathered, must be strictly in accordance with what you told the user it would be used for. This rule reiterates the example of "prize draw versus marketing spam". Disclosure is a big part of this rule. It states that you may not disclose the information received, to another party / organisation, unless you have the *express permission* of the user. There are clever ways marketing types try to get around this, but really, it's best to do the right thing - users are getting quite tired of privacy abuse these days and it does more damage than its worth to share data in an unauthorised manner. For devs, the thing to watch for here is that you lock down data, and only allow access through for example APIs that access control has been implemented.
![purpose]()
- Keep data safe and secure
Oh dear - this is a can of worms! ... this moves beyond the realm of the developer and now involves your IT infrastructure experts. This is a specialised area and you should take advice where necessary. From a developers point of view, you need to ensure data is stored encrypted both at rest (in files, in database, etc.), and in transit (https everywhere!). Depending on the sensitivity of the data, you also need to ensure strong access control is in place, with PKI and two factor authentication where necessary. Careful records should be kept, and regular audits of security need to be carried out, and a 'designated person" needs to be assigned to be responsible for data/information security.
- Keep data accurate, complete and up to date
Mmm, up to now, this data protection stuff seemed reasonable to keep on top of - so here is where we start to go down the rabbit hole.... from a development point of view, how can you help? .... the easiest way is to ensure that all data captured is date-stamped, so that you can set up time based audits of information, that checks when was the last time (a) the data was confirmed with the user for accuracy (a refresh of data every 12 months is generally expected. eg: has the user changed address in the past 12 months? has their marital status changed?) (b) if the data has not been updated that is flagged as a problem and action taken.
![data]()
- Data held must be adequate, relevant and not excessive
More of it .... this is a very fine balance between what the organisation wants to know about a user, and what it absolutely needs to know *at a bare minimum* about a user. This rule must be taken in context with #1 and #2, that is, the data held must not only be the bare minimum you need to know about the user, but the minimum you need to know in the context of the reason you took the data in the first place. This means for example that if we hold a competition, and gather user data in relation to that, unless there is a reason for asking and storing the users age (for example if the price required adult status), then you may not ask the question or store the data. Of course, again, the marketing folk can put in terms and conditions that require the information, and the user can of course choose not to enter, but they are walking on very thin ice. From a development point of view, when building solutions that gather and store data, you should ask what the reason is for the data being gathered and what justification there is for gathering it and using it.
- Only retain data for as long as is absolutely necessary
This one is straightforward, but can be a bit tricky as other rules can be contradictory. This is where you need to take local legal advice if unsure. Let's look at an example - if you apply for a job, and you don't get offered the position - should the potential employer be allowed to keep a copy of your resume? ... you may say now, however, they may argue that you may come back and sue them for some kind of discrimination for not being offered the position so they need to keep it ... fine, but for how long? Under employment and contract legislation, it may be required that all application documentation, plus any notes and supporting decision making documentation and communication be kept for a prescribed period of time. In this case, the employment or contract legislation may trump the data protection and privacy legislation. For a developer, the best thing to do is to keep track of what data you have, where it came from, and link it back to how long it should be kept - this can be facilitated by timestamping and tracking data in and out.
- Give a person a copy of their data on request
So, last but not least, data access requests. This rule simply states that you must give a person a copy of any and all data you hold on them, subject to certain rules and exceptions. Rules/exceptions generally relate to medical and legally sensitive information. This rule may seem simple, but its implications mean that someone (that's you developer person!), must keep track of what data is in the system, who it relates to, where it came from, what it is being used for, etc. etc. so that, when a person/user asks for a copy, you can readily access it and hand it over. Data access relates not only to record based data but also to any video/audio, etc.
![request]()
Wrap-up
The data legislation (very) briefly outlined above is about to change. A process of consultation has been going on for the past while and new updated laws are due to be in place in the next 12/24 months. These rules bring the legislation up to date and into line with modern data handling, and encompassing things like social networks, cloud storage etc. While up to now actions taken by data protection and privacy controllers have been minimal, they are ramping up to take on the new rules and there is a lot of talk of heavy fines coming down the line. It is important that developers are aware of the rules, and take action when designing and building out systems to ensure that the organisation they work for have technologies and systems in place to enable them to adhere to the legislation. Hopefully this article gives you some tips and pointers on how to get started.
Ref: Links to national organisations responsible for data protection,
- Data protection in India - overview
- Austria http://www.dsb.gv.at
- Belgium http://www.privacy.fgov.be/
- Bulgaria http://www.cpdp.bg
- Croatia http://www.azop.hr/cpage.aspx?page=default.aspx&PageID=47
- Cyprus http://www.dataprotection.gov.cy/
- Czech Republic http://www.uoou.cz/
- Denmark http://www.datatilsynet.dk/
- Estonia http://www.dp.gov.ee
- Finland http://www.tietosuoja.fi/
- France http://www.cnil.fr/
- Germany http://www.bfd.bund.de/
- Greece http://www.dpa.gr/
- Hungary http://abiweb.obh.hu/dpc/
- Ireland http://www.dataprotection.ie/
- Italy http://www.garanteprivacy.it/
- Latvia http://www.dvi.gov.lv/
- Lithuania http://www.ada.lt/
- Luxembourg http://www.cnpd.lu/
- Malta http://www.dataprotection.gov.mt/
- Netherlands http://www.cbpweb.nl/
- Poland http://www.giodo.gov.pl/
- Portugal http://www.cnpd.pt/
- Romania http://www.dataprotection.ro
- Slovakia http://www.dataprotection.gov.sk/
- Slovenia http://www.ip-rs.si
- Spain http://www.agpd.es/
- Sweden http://www.datainspektionen.se/
- United Kingdom http://www.ico.org.uk