GDPR AND APPLICATION SECURITY: SOME PRACTICAL GUIDANCE - IriusRisk

IriusRisk

by

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:

  1. 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?
  2. 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?
  3. The amount of personal data we may hold
    • Have we minimized our data collection to only that which we need for the purpose required?
  4. 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?
  5. 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?
  6. 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
  7. 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?
  8. 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.