Value by Design: Tips for Integrating Privacy and Security into your DevOps Processes

When you think of an iPhone commercial, what comes to mind?

Apple caught the attention of many privacy and security professionals when it released the iPhone tagline “Privacy. That’s iPhone.” a few years ago.

Image Source	Image Source

The ad campaign demonstrates the general population’s desire for more privacy and better data protection amidst data breaches, “free” platforms, and aggressive targeted marketing. Apple is clearly trying to capitalize on that trend by emphasizing privacy as a key feature. At the latest Apple event in late April, it rolled out more privacy changes such as a feature called App Tracking Transparency (ATT), which was included in the iOS 14.5 update that rolled out in late April.

Whether you’re a life-long iPhone user or an Android diehard, organizations are clearly realizing that their customers value privacy and that privacy can be a critical business differentiator. But how difficult is it to integrate privacy and security into the technology we use every day?

The Impact of Privacy and Security on DevOps

In 2021, most companies agree security and privacy are key concerns for their products. However, implementing privacy and security in a product is still a challenge. The go-to approach of building a product and then bolting on privacy and security features at the end has caused trouble time and time again. Understandably, developers become frustrated when they have a product ready for release but are then required to make last minute security modifications to functioning features. It requires considerably more effort (and budget) to address security concerns after an architecture and application design are already in place, developed, and implemented.

The issues highlighted by this last-minute approach show the value of Security by Design (SbD) and Privacy by Design (PbD). These philosophies push organizations to consider privacy or security at the very beginning of the product development lifecycle. By introducing privacy and security considerations into design workshops and architecture meetings, teams proactively address issues that would eventually become roadblocks at launch. Additionally, this approach often results in improved collaboration across these various teams, enhanced strategies for privacy and security solutions, and minimized risk for development and test environments.

Now, SbD and PbD seem like obvious wins, but in practice they can be difficult to implement, which is why many companies are still trudging the age-old path of bolt-on security/privacy. While public awareness of privacy and security topics increased in the last few years, organizations are having trouble adapting their approaches every time a new regulation is released or an incident takes place. One of the common pitfalls of their strategies? They do not include or prioritize having privacy/security discussions at the early stage of development.

Tips for Implementing Privacy by Design and Security by Design Principles

The costs of privacy penalties and security incidents are too great for organizations to continue to ignore PbD and SbD. In addition, customers are choosing companies that prioritize privacy over those that don’t, according to Cisco’s 2020 Consumer Privacy Survey. The good news? Getting started with these concepts is more manageable than you think:

Organizational shifts begin with minor changes. Rather than trying to move every single application team to these new approaches at once, start with a single product team that already appreciates the value of security and privacy ideologies. It is important that this team is provided with training, helpful resources, and opportunities for collaboration. Use that first effort as a trial, and slowly expand to other teams with lessons learned.

Now more than ever, there are frameworks for common business problems, so organizations do not need to start from scratch when implementing SbD and PbD. While there is value in iteration and customization, most organizations can start by leveraging existing frameworks such as the NIST Privacy Framework and Microsoft’s STRIDE Threat Modeling Framework.

Once these activities have been implemented, the resulting value must be tracked in some capacity to demonstrate the rationale for continued use. For example, noting the decrease in the number of security/privacy-related Jira tickets in the final month before product release will help build the business case for integrating privacy and security early. Quantitative data speaks volumes to developers and business leadership.

PbD and SbD are not a quick and easy lift, but they also need not be overcomplicated. By starting small, following the basics, and focusing on reducing organizational friction, teams can develop secure and private applications that protect user data. When your brand reputation builds due to the absence of security/privacy incidents, your organization will understand why we also call these two philosophies “Value by Design.”

Want more insights into the latest privacy news?

Subscribe to Focal Point's Privacy Pulse below - a once-a-month newsletter with guides, webinars, interesting white papers, and news all focused on data privacy. Thousands of your colleagues and competitors have signed up! You can unsubscribe at any time.