GDPR AND APPLICATION SECURITY: SOME PRACTICAL GUIDANCE
GDPR: THE SOFTWARE DEVELOPERS PERSPECTIVE
Europe’s new General Data Protection Regulation (GDPR) became legally enforceable on the 25th May. The underlying driving force behind the regulation is the empowerment of data subjects within the EU in regard to their personal data. Underpinning this is the concept of “Privacy by Design”.
PRIVACY BY DESIGN
The principle behind privacy by design is to bake in data protection and security from the inception of the application project and throughout its lifecycle. This is primarily achieved through Privacy Impact Assessments (PIAs). This approach identifies potential problems early on in the design and development process when they are simpler and cheaper to rectify.
PRIVACY IMPACT ASSESSMENTS
There are 8 key GDPR principles to consider when undertaking an application PIA:
- Processing personal data fairly and lawfully
- Do we have legitimate grounds for collection of user personal data that will not have an unjustified negative impact?
- Have we given appropriate privacy notices?
- Processing personal data for specified purposes
- Do we have a justifiable rationale for personal user data collection?
- have we provided appropriate privacy notices including detailing uses that differ from the original purpose?
- The amount of personal data we may hold
- Have we minimized our data collection to only that which we need for the purpose required?
- Keeping personal data accurate and up to date
- Have we taken reasonable steps to ensure data accuracy?
- Have we provided a mechanism by which the user may edit and update incorrect information?
- Retaining personal data
- Do we have data policy retention and deletion policies and procedures in place that are in accordance with the purpose of collection?
- The rights of individuals – Have we put mechanisms in place to:
- Be given a copy of the information comprising the data.
- Object to data processing.
- Prevent processing for direct marketing.
- Object to automated decisions (eg profiling).
- Have inaccurate personal data rectified, blocked, erased or destroyed.
- Claim compensation for damages caused by a breach of the Act
- Information security
- Have we designed and organised our security to fit the nature of the personal data with consideration as to the harm it would cause if breached?
- Clearly identified personnel responsible for data security?
- Ensured physical, technical security and robust policies and procedures are in place with adequately trained personnel?
- Prepared for swift and effective data breach response?
- Sending personal data outside the European Economic Area
- Have we ensured an adequate level of protection for user data transferred outside of the The EEA?
Although the above may – at first blush – appear daunting, there is an overarching narrative that can be encapsulated within the following questions:
- What is the data we are collecting?
- How are we collecting it?
- Why are we collecting it?
- What are we doing with it?
- Are the data subjects expecting this?
With these questions in the back our minds during the application PIA, mapped against the 8 key GDPR principles, it becomes possible to template a framework.
Further, as many applications we develop have commonalities, we are able to create architectural risk patterns that can be applied to other applications we develop in question and answer checklist format over and again.
The key to simplification is to break down the application into individual components – for example the registration form – and then ask ourselves the above pertinent questions in relation to GDPR requirements.
This approach allows us to be proactive in ensuring GDPR application security and data protection requirements are in place and embedded from the beginning of the development process. This avoids the “bolt-on” mentality which often leads to complex and expensive changes at the end of the development cycle.
Also, breaking down our applications into manageable individual components and approaching GDPR requirements in a standardized and systemized question and answer format that is repeatable, documented and thoroughly tested, gives us a simplified, manageable, scalable framework – assuring ourselves, our users and regulatory authorities, that our applications are in compliance with GDPR.
Did you like this article?
- Schedule a meeting with Continuum Security at Def Con 201826 July 2018Our CTO Paul Santapau will be in attendance at the upcoming Def Con conference in Las Vegas August 9th-12th. Please do let us know if you would like to schedule a meeting with Paul to discuss all things DevSecOps and our IriusRisk threat modeling platform – including new features and future development. If you’re […]READ MORE
- Build GDPR Compliance into Your Applications with IriusRisk24 July 2018Back in June I wrote some practical guidance on GDPR and application security and made the following comments: …..as many applications we develop have commonalities, we are able to create architectural risk patterns that can be applied to other applications. The key to simplification is to break down the application into individual architectural patterns – for […]READ MORE
- Why invest in a threat modeling tool?16 July 2018Over on the Leviathan Security blog Crispin Cowan pens his thoughts on the “Calculus of Threat Modelling” within which he makes this comment: There are many threat modeling tools available, but they are really just substitutes for threat modeling best practice, which is for a threat modeling expert to meet with engineers who are experts on the […]READ MORE