Home News Privacy by Design – Broadening the Scope Beyond the SDLC

Privacy by Design – Broadening the Scope Beyond the SDLC

435
0
SHARE
privacy
SHARE

By Robert Pellerin

We all want our personal data to be private and unseen by other eyes, right? Of course. It is also critically important that we build a culture within our organizations to protect client and customer data.

While Privacy by Design (PbD) has been around since the 1990s and many organizations have adopted its principles, the “newness” of the EU’s new General Data Protection Regulation (GDPR) and other privacy regulations may promote an internal focus on the Software Development Life Cycle or SDLC to those new to PbD. In this article I’ll explain what PbD is and offer a perspective for implementation scope that sometimes gets overlooked in the focus on “coding and development” – PbD isn’t just about the SDLC.  PbD is a good idea and a good practice in all aspects of a business.

When considering data privacy and protecting personal data, processes should be embedded / built-in across all aspects of the business and not geared only toward complying with regulations. We all need to check our boxes, but by building in data privacy concepts through employee security awareness training and client and customer data privacy concept discussions and training, we can begin to build this into culture, providing benefits that are deeper than doing something because the Chief Information Security Officer (CISO) or Chief Privacy Officer (CPO) said so.

What is Privacy by Design?

It is a concept for being proactive about data privacy and embedding the processes and controls necessary to protect personal data “end-to-end” or throughout the lifecycle of a product or service.  While Privacy by Design has recently again come to the forefront due to GDPR it should be a commonsense principle. Privacy by Design came from Dr, Ann Cavoukian who while she was the Information ad Privacy Commissioner of Ontario, Canada created the 7 foundational principles for Privacy by Design:

#1 – Proactive not reactive; preventative not remedial

A well designed PbD practice will anticipate and prevent invasive events before they happen.

#2 – Privacy as the default setting

Privacy by default means that a data subject should not need to do anything in order to keep their personal data private as settings should be configured (for example) such that protection is “on” unless the data subject requests or makes a change.

#3 – Privacy embedded into design

Embed privacy settings into the design and architecture of information technology systems and business practices instead of implementing them after the fact as an add-on.

 #4 – Full functionality – positive-sum, not zero-sum

There should be no trade-offs, for example, privacy vs. security or security vs advanced functionality.

#5 – End-to-end security – full lifecycle protection

Continuous protection of privacy across all aspects of the business and from the first-time data is collected until it is erased or destroyed.

#6 – Visibility and transparency – keep it open

From technologies to business practices, everything is operating according to transparently stated policies and practices and are independently verified.

#7 – Respect for user privacy – keep it user-centric

Interfaces should err on the side of human-centric and not be overly complex so as to cause ambiguity leading to decisions on the part of users that erode privacy.

PbD is Foundational

Principle # 3 is “Privacy Embedded into Design”:

Embed privacy settings into the design and architecture of information technology systems and business practices instead of implementing them after the fact as an add-on

In other words don’t build it and then go back and sprinkle some privacy on it, build in privacy foundationally like the frame of a house.  You wouldn’t put up the sheetrock, run the wires for electricity, paint and then go back and put in the 2 X 6s to make it strong.

PbD Across the Entire Organization

Once we gain an understanding of the 7 principles it isn’t a stretch to realize that they should apply to anywhere in a business that collects, stores, processes, views, or utilizes personal data in any way. Determine what is being done right now to meet the principles that apply.  Then determine what if any risks to privacy (and security for that matter) are revealed due to a lack of formal adherence to the principles. If the risks are real and can be rated based on probability X business impact, they should be added to your Risk Register.

The PdB program can be set up to ensure that what the business is producing considers privacy at each phase and not just in the SDLC (developing software), but also for artifacts produced such as marketing materials and sales presentations, and in the utilization of tools like CRM, ERP and HR.  PbD should be an over-arching practice based on the 7 principles and woven into business practices until they become normal (cultural).

Beyond the SDLC

In building a new technology module to service your customers, the tech-development lifecycle is a key area, and it may be the best place to start.  However, Marketing, Sales, Human Resources, Finance (Accounting, AP, AR) and IT all can and should operate with PbD in mind.

PbD Principle #1 would apply to the following example:

Anticipate, identify and prevent privacy invasive events before they occur

Marketing attends a conference and has agreed to give a presentation or keynote.  Several of the slides have sample screenshots that contain actual personal data from your customer database. Without a process to clear communications through the offices of the CSO or CPO, that presentation could go out containing the actual customer personal data.  A mistake for sure, but a totally avoidable one.  Having good policies in place that prohibit the sharing of personal data only go so far for a person being driven to make her quarterly goals for qualified leads as the policies are not always top of mind.

A defined process that requires approval before artifacts are made public is a good start.  Using a set of Standard Operating Procedures or SoPs that document the activities necessary to execute on PbD is a practical method to use, and the SoPs can be linked to policy.

Assessment Tools – PIA / DPIA

There are key differences between a Privacy Impact Assessment (PIA) and the Data Protection Impact Assessment (DPIA).  A PIA is more in line with what we’ve been addressing in this article, typically conducted for new business processes, during consideration of an acquisition, and when a new product is being launched prior to going to production.  A DPIA, which is required by GDPR and is an essential part of an organization’s accountability obligations under GDPR, is more concerned with data processing activities that could put the rights of Data Subjects at risk.

Adopting a practice of conducting a PIA for any new product, service business process, organizational change or an artifact that will go public is one way to ensure that security and privacy are embedded and that no new risks to personal data will be created.  While not the only reason to do a PIA / DPIA, a key is that GDPR (and soon other regulations) require that an organization demonstrate Privacy by Design.  The artifacts from a well-orchestrated PIA / DPIA can assist as a compliance tool to show that PbD is taken seriously.

Regulatory Considerations

GDPR

As for GDPR, even if you are a U.S. company that does not sell to the EU and have no offices in the EU, the regulation will apply to you if you have collected, stored and /or processed personal data of an EU resident.  In other words, EU privacy laws are exterritorial, that is, regardless of where a service is provided from, it applies if EU residents are involved.

To ensure that privacy is embedded in the collection, use, and disclosure of personal data, organizations should also consider appointing privacy champions to business teams.  Privacy champions can assist with the facilitation of PbD, by considering data minimization and purpose limitation in the development of new products and services.

To conclude, any organization that is collecting, storing or processing personal data takes on a basic responsibility and requirement that if that data is personal data, the organization should practice Privacy by Design (PbD) principles and Privacy by Design should be included in any business process, product or service that must touch personal data.

Robert Pellerin is an IT, security and compliance manager and practitioner with over 25 years’ experience, with proficiency in data center, cloud and hybrid models. He has managed IT infrastructure and InfoSec for large corporations and startups. He currently holds CISSP and CISM certifications.

 

SHARE

Sign Up Now & Get Free CISO MAG issue

* indicates required

LEAVE A REPLY

Please enter your comment!
Please enter your name here