Comprehensive Software Reviews to make better IT decisions
Avoid the PIA Trap, Integrate PbD Early in Your AppDev Process
Traditionally known as privacy by design (PbD), data protection by design principles are now required under Article 25 of the European Union's General Data Protection Regulation (GDPR).Building privacy controls based on data protection by design into your application development practices can ensure you get positive-sum results, allowing your applications to satisfy many GDPR requirements “by design.”
GDPR Preparations in Full Force
Your organization has likely been running full speed ahead with preparations for the GDPR. A privacy officer or data protection officer is overseeing continued GDPR compliance efforts, focusing heavily on data inventory and mapping, making changes to incident handling and breach notifications, performing data protection impact assessments (DPIA) on high-risk activities, and spreading awareness that the world as we know ended on May 25, 2018 (just kidding… sort of).
Various internal groups are frantically documenting personal data processing activities, making changes to systems to comply with consent and notice requirements, and dreading the weekly legal discussion around lawful basis of processing and whether adequate security measures are in place.
With the frantic push for compliance past GDPR D-Day, organizations are doing what they can to expedite the building or enhancing of a data privacy program. After all, a survey indicates that 55% of organizations in EMEA had either a non-dedicated privacy function or no privacy function at all. The US is not faring any better, with only 44% of US corporate directors having confidence in the comprehensiveness of their company’s data security and privacy program. So with all the focus on data inventory and mapping, DPIAs, and breach notifications, data protection by design may not be at the top of your list.
Better Now Than Later
Moreover, it is important to note that the European Commission Article 29 Working Party’s (Art. 29 WP, now operating as the European Data Protection Board [EDPB] after the GDPR came into effect on May 25, 2018) guidance on the setting of administrative fines specifically calls for principles of data protection by design and by default as key assessment criteria, even ahead of appropriate level of security and relevance of data protection policies.
Combining this data protection by design criteria with the typical application development lifecycle and lengthy privacy impact assessment (PIA) processes could mean months before data protection by design makes it into your application, increasing your application’s exposure to non-compliance under the GDPR. In addition, traditional PIAs are also long and unwieldly; they point out remedial measures as bolt-on quick fixes to address privacy concerns. The result is an application with a patchwork of fixes, potentially reduced capabilities, and an overextended development timeline, resulting in a zero-sum situation.
By taking data protection by design head on, and embracing data protection by default, applications satisfy privacy requirements up-front. Organizations that adopted secure software development lifecycles (SDLC) are familiar with the benefits of integrating security considerations early in their processes. Data protection by design principles can be integrated in similar and innovative ways, addressing many of the GDPR’s privacy requirements upfront.
Part of Your SDLC
Now that you are convinced adopting data protection by design early in your application development cycles can reduce the impact of integrating privacy controls, where should you begin?Depending on your application development model (waterfall or agile), data protection by design steps would either be structured or cyclical. Add privacy assessments at each relevant phase for waterfall development processes, while teams developing under agile methodologies will need upfront training and support to ensure data protection by design is considered throughout the ad-hoc and continuous development efforts.
It is important to note that data protection by design principles should be provided upfront to your developers (designers, coders, testers, release managers, etc.) in the form of training and playbooks, so that any privacy assessments are used as quality assurance for privacy controls rather than gap analysis. Your designers will appreciate building consent checkboxes into their wireframes before starting their designs, your coders would want to consider data minimization when designing their databases, and your testers should integrate privacy checks in their testing methodologies.
- Understand your organization’s GDPR position. Are you building an application used by your organization as a data controller? Is your application a go-to-market solution for a client who is a data controller? Is your application an off-the-shelf product for a solutions provider to use as a data processor? All of these have diverse effects on how data protection by design applies to an application’s design.
- Train your developers and build a data protection by design playbook. Ensure your developers understand the core principles of data protection by design, including what it means to build in data protection by default.Supplement your existing processes with a data protection by design playbook that provides concise and practical guidance to your development teams.
- Formalize a privacy assessment process. Engage your legal or privacy teams as part of your privacy assessment processes. See them as resources that can validate your development team’s data protection by design efforts, and enablers for your application’s GDPR compliance.
With such diverse types of applications and systems, there is no one-size-fits-all methodology for data protection by design in any development process. Your approach to data protection by design principles also depends on the GDPR’s application to your organization.
Understanding your application’s GDPR exposure, providing your development teams with tools to support data protection by design, and adding privacy assessment checkpoints within your SDLC will significantly reduce the impact new privacy regulations will have on your application delivery timeline and help expedite your application’s GDPR compliance.
Want to Know More?
Osano recently released its SaaS privacy solution aimed at simplifying compliance and vendor assessments. The product feels familiar, but Osano’s ethical commitment sets it apart from the crowd.
TrustArc has announced the acquisition of Canadian counterpart, Nymity – a more boutique-style vendor known for its very high standard of privacy research, expertise which manifests in its product offering.
Data governance player Collibra recently announced the acquisition of SQLdep, a leading provider of automated data lineage.
Privacy by Design (PbD) is a General Data Protection Regulation (GDPR) requirement, but effective implementation requires deep insight into the operation and interconnection of various data collection processes. Thus, PbD can be difficult to document and demonstrate. However, Proteus may help.
BigID launches a certification program, aimed to help users, administrators, and organizations demonstrate compliance.
TrustArc’s introduction of Privacy Profile aims to solve an ongoing problem privacy professionals have: identifying all applicable regulations.
Quest Software’s new add-on module, Toad for Oracle Standard Data Protection (SDP), automates the detection and remediation of potential violations of data privacy regulations such as GDPR, HIPAA, and PCI.
Varonis Report Identifies Widespread Shortcomings of Organizational Data Security Despite Increased Pressure of Regulations
Varonis reports that even after GDPR, businesses still are failing to effectively protect sensitive data.
Nymity expands its product offering with the introduction of a new Data Subject Requests product.