Tech companies building cloud-native applications face a set of unique and rising data protection challenges. At Bearer, we had the chance to speak with 100+ data security and privacy professionals including Chief Information Security Officers, Directors of Security Engineering, Application Security Engineers, Data Protection Officers, Privacy Engineers, and many more. Here are the top concerns that keep them up at night.
Data security & privacy is bigger than ever
First, the threat of data breaches has become more real than ever. Particularly for companies processing high volumes of sensitive data like personal, health, or financial information. No company is immune—from tech giants like Zoom, Twitch, eBay, and Facebook to startups. The resulting financial penalties and reputational damages can cripple any business permanently; as of 2020, the average cost of a data breach was $3.86 million (source: IBM).
At the same time, privacy laws have been flourishing everywhere: GDPR in Europe, CCPA in California, LGPR in Brazil, PIPEDA in Canada, PIPL in China, and many more. Data regulations have existed for some time, like HIPAA for health information or PCI-DSS for card payment data, but they applied to a limited number of companies. Privacy laws like GDPR compel almost every company to comply with high data protection standards.
Furthermore, data protection has evolved to become a real competitive advantage for businesses. It's no longer rare to see consumer companies like Apple market their commitment to privacy in order to attract consumers. In B2B, strong data security practices have become a must-have to comply with customers' requirements and win deals from competitors. You got it: data security and privacy have become a must to grow a tech business.
Engineering teams are increasingly complex
The problem is that product and engineering teams at tech companies can grow incredibly fast. It's very common to see startups scale from a dozen developers to hundreds in a few years to support their growth. Data security and privacy may be relatively easy to deal with when you have a team of 10 developers working on one product only, but it can quickly transform into a nightmare when you need to monitor the work of 10 feature teams releasing code several times a day.
As if that wasn't enough, the software architecture of modern applications has also grown more complex. The increasing use of microservices and integrations with third parties has multiplied the average number of engineering assets and data flows by tenfold. Security engineering teams must ensure that data security policies are implemented effectively across the software built by the organization, yet they struggle to keep up with the pace of product and engineering teams.
Problem #1: Mapping data flows at scale is a headache
The first requirement of any data security policy is to identify and catalog assets. At the product scope, we are talking about applications, internal services, databases, third-party APIs, message buses, data types, among others. Most teams start with a spreadsheet and an informal documentation process. Engineering owners are responsible for manually updating the spreadsheet whenever significant code changes happen. While efficient in early-stage companies, this approach doesn't scale; spreadsheets are quickly incomplete, out-of-date, and thus unusable by security teams.
More mature tech companies look for automation and often end up exploring data cataloging tools. Those plug onto production databases and automatically build an inventory of databases and data stored. While very powerful, they are very admin-intensive and require vast resources to set up and maintain. Plus, their scope is limited to databases. This means security teams can't actually monitor data flow to internal or third-party services. In short, not a good fit for fast-growing companies building modern cloud applications.
As a result, some security engineering teams end up building their own data discovery tool. They may require teams to add parameters to engineering components directly in the code and then use Static Code Analysis to retrieve them and build their data inventory. Some even go so far as to block a release if those requirements aren’t met. It works great, even though it requires significant engineering bandwidth to build and maintain.
Problem #2: Communication with product builders is broken
Collaboration between engineering and security teams is key to data risk assessment. Security teams need to document information such as data category, data sensitivity, data subjects, security controls, retention periods, and more. And engineers building the product are their best source of truth to get it. Unfortunately, communication there is inefficient.
First, identifying the right code owner often proves to be very time-consuming in large distributed engineering teams. Spreadsheets and data cataloging tools don't provide context about who builds what. Security teams should rely on GitHub or GitLab to automatically retrieve this information; go to where the developers are already.
Second, collecting knowledge through manual questionnaires can be quite unpopular with developers. Worst-case scenario: security teams rely on Governance, Risk, Compliance (GRC) software surveys which are unintelligible to engineers and a nightmare to fill. Best-case scenario: they built light-touch & developer-friendly questionnaires, embedded right into their tools and workflows. It’s the classic DevSecOps conundrum of balancing development speed with security requirements.
Finally, engineering teams get nothing in return for their input. They spend time to help build a software engineering inventory, and they never see the resulting benefits of it. Instead, they can be sold on the idea that it could be used as documentation to onboard new hires, learn about internal data security policies, track implementation progress, and foster a sense of ownership.
Problem #3: Data risk assessment is disconnected from software development
Most tech organizations assess risks in two situations: before building a product during the scoping phase, and then on a periodic basis (every quarter, semester, or year). Significant code changes that may have introduced new risks can go unnoticed for months. The product moves fast in tech companies; changes happen every day.
Proactive security teams audit code changes as they happen without disrupting feature velocity. Think of data risk assessment with a DevSecOps approach. Whenever significant changes are detected, like a new service processing sensitive data, the security team receives a notification and can trigger a risk assessment workflow. Some even go as far as to build custom code audit rules to automatically surface gaps with their data security policy.
Bringing data security to the speed of DevOps
In the end, it's a matter of integrating risk assessment into the software development lifecycle. So security teams can effortlessly identify, prioritize and mitigate risks, with respect to their very specific data security and privacy policies. That's what we have been building Bearer for, inspired by the practices of the very innovative security engineering teams we talked to.
