Why Privacy by Design Matters in the SDLC

Digital transformation is driving more and more data to be used and shared across systems to develop new innovations and improve customer experiences. At the same time, privacy continues to be a growing concern. Regulations such as GDPR in the EU and the California Consumer Privacy Act (CCPA) are designed to protect consumers’ privacy, and more legislation will surely follow. Data privacy is related to security, but deserves—no, requires—its own explicit focus and consideration across the SDLC.

Privacy by Design and its Seven Foundational Principles

The concern for data privacy isn’t new. Way back in the very early days of the internet, in 1995, Ann Cavoukian, who was working at the Ontario Office of the Information and Privacy Commissioner, developed the concept of “Privacy by Design,” which calls for privacy to be taken into account throughout the entire engineering process. A formal Privacy by Design framework was published in 2009—it states:

“Privacy must be incorporated into networked data systems and technologies by default. Privacy must become integral to organizational priorities, project objectives, design processes and planning operations. Privacy must be embedded into every standard, protocol and process that touches our lives.”

The framework, which has been adopted by numerous government and industry standards bodies around the globe and was incorporated into GDPR, has seven foundational principles:

Sponsorships Available

Sponsorships Available

Sponsorships Available

1. Proactive not Reactive; Preventative not Remedial: Don’t wait for privacy risks to materialize but aim to prevent them from occurring in the first place.
2. Privacy as the Default: No individual should be required to take action to protect their privacy; it should be built into the system.
3. Privacy Embedded into Design: Privacy is an essential component of the core functionality and should not be bolted on after the fact.
4. Full Functionality—Positive-Sum, not Zero-Sum: Avoids the “pretense of false dichotomies,” such as a privacy/security trade-off; you must accommodate all legitimate interests.
5. End-to-End Security—Lifecycle Protection: Privacy extends securely across the entire lifecycle of the data from collection to retention to destruction at the end of the process.
6. Visibility and Transparency: You need to ensure that all the component parts and operations are visible and transparent to both providers and users.
7. Respect for User Privacy: The interests of the users are the top priority and you must offer measures such as strong privacy defaults, appropriate notice and user-friendly options.

Privacy by Design as Part of Security as Code

Many organizations in the throes of digital transformation are moving to a DevOps model, adopting practices that integrate software development and IT operations to shorten the SDLC, perhaps even enable continuous integration and continuous delivery (CI/CD). A key DevOps practice is Infrastructure as Code, and infrastructure automation tools are an important component of the DevOps toolchain.

Companies that are serious about security—and let’s face it, that should include every one—implement secure DevOps, or DevSecOps, which integrates security throughout the entire software development pipeline. DevSecOps employs Security as Code, which adds security checks, tests and gates throughout the software development process. And like with Infrastructure as Code, Security as Code relies on automated vulnerability testing to avoid adding delays to the process.

While the foundational principles of Privacy by Design are about design, hence the name, it’s critical that those privacy considerations are incorporated across the entire development, testing and deployment process. This means adding privacy checks, tests and gates throughout the SDLC. It also means embedding privacy into your Security as Code practices.

Privacy by Design Across the Microservices Ecosystem

Along with DevSecOps, organizations are employing a microservices architecture—a development approach that uses smaller, “as a service” pieces of functionality—to facilitate digital transformation and shorten release cycles. There’s a large marketplace of third-party services and APIs, which means companies can quickly implement a piece of functionality without having to create it from scratch, further speeding the development process. But when you buy a piece of functionality, you can’t ensure, let alone mandate, that Privacy by Design was baked into it by that third-party.

You could, of course, forego any third-party components and build everything yourself, but that would lengthen the SDLC and likely require you to expand your development team, both of which reduce the very agility you need for successful digital transformation. Instead, you need to have comprehensive, continuous and accurate visibility into where security, compliance and privacy risks lie and how they could affect the business. If you can’t control whether privacy is embedded into a given microservice—or any other component or tool used across the SDLC—you can evaluate, prioritize and manage any privacy risk from the outset, before it even enters your development process.

Privacy Concerns Are Here to Stay

Digital privacy is and will continue to be a hot-button topic. For every new innovation, there are potential privacy implications with very real consequences in the courts of law and public opinion. Embedding privacy throughout the entire SDLC, such as with a Privacy by Design approach, isn’t just the right thing to do, it makes good business sense.