What About Data Privacy

1. 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.
   
   
2. 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.
   
   
3. 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.
   
   
   
4. 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.
   
   
5. 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.
   
   
   
   
6. 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.
   
   
7. 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.
   
   
8. 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.
   
   
   

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