In 2011, Gabe Newell described software piracy “as a service problem.” His comment implied that until there was a better experience from a legitimate service, consumers would continue to engage in the illegitimate offerings—no matter how bad it was for the overall economy.

We interviewed over a hundred developers on data security and reflected on our own experiences at Twilio, Klarna, and Dwolla in developing the Basis Theory platform. Like Newell, we found that the service and, more importantly, the experience provided by that service greatly influenced how well (or poorly) developers and organizations protected and used their most valuable data.

We had a hunch that if we could abstract sensitive data and their compliance, security, and operational requirements, we could help developers fast track compliance. Last August, we launched our beta. Since then, the market's response has been incredible.

We’re not only excited to announce the general availability of Basis Theory, but to share with you the insights and decisions that have guided us here today and are helping us think about tomorrow.

So, why is data security a developer service problem?

When talking to developers three trends tend to emerge:

1. Securing sensitive data is hard
2. Using sensitive data is hard
3. Managing sensitive data is hard

Why is securing sensitive data hard?

Observation #1: Compliance competes for resources, priorities, and timelines. Developers are responsible for ensuring systems and data usage meet existing policies and controls. Unfortunately, doing this correctly often comes with a cost that’s not always supported by the appropriate personnel, focus, or deadlines.

Observation #2: Security isn’t static. Encryption libraries offer developers a great, lightweight, near-term solution. However, scaling this approach to encryption while still meeting the emerging security threats often becomes a continuous and resource-intensive challenge for organizations.

Observation #3: Lots of early decisions with little certainty. Developers face many data security decisions even before the first line of code is written. These questions are highly contextual and, with no straightforward answers, can become the source of anxiety and analysis paralysis. To compound matters, wrong answers can create security risks, maintenance costs, and limitations on future solutions.

Why is using sensitive data hard?

Observation #1: Compliance isn’t black and white. Many believe compliance is binary, but policies and controls rarely account for the contextual factors developers face when writing code. Prescriptive requirements suddenly look like well-meaning suggestions, forcing developers to piece together who, what, when, where, why, and how a particular data type can be used.

Observation #2: Securing data locks up its value. Storing data inside encrypted ciphertext or behind firewalls with access policies protects but also marginalizes its value. This duality between security and utility creates constant challenges for developers and organizations alike.

Why is managing sensitive data hard?

Observation #1: Data governance is ambiguous and decentralized. Decentralized and inconsistent implementations of authorization and access controls result in bespoke solutions for the same problem across multiple systems. In addition, understanding and implementing new access policies in these environments generate complexity and cognitive overhead.

Observation #2: Manual security management can be terrifying. Manually managing systems and controls exposes organizations to human error and limits the number of engineers capable of contributing and reviewing changes. This is especially risky for those systems and controls that handle sensitive data—where missteps can result in irreparable damages to an organization.

Observation #3: Auditing of data access is inconsistent when it exists. Auditing individual access across systems requires engineers to spend valuable time scouring logs and policies. In addition, most logging in place is typically capturing system activity, transactions, and errors—not necessarily user or system behavior. This proves challenging for teams trying to satisfy compliance requirements.

Why [not] Basis Theory?

Our interviews and experiences established Basis Theory’s problem-set, but they didn’t set the bar for the user experience we needed to create for developers. To guide future decisions, we began asking a simple question—one that was both aspirational and practical. We came up with:

“Why wouldn’t you secure all data?,” which we later simplified to, “Why not Basis Theory?”

Over the last year, we focused on simplifying and abstracting the challenges we captured from developers.

Making it simpler to secure your sensitive data

Compliant environments. Complexity is accommodating the nuances of every single compliance and security requirement. By extending our PCI Level 1, SOC 2, and HIPAA compliant environment to developers, we abstract the compliance burdens faced when trying to store nearly every sensitive data type. Tenants, which allow developers to segment their data, also inherit these benefits and can be freely spun up in seconds.

Providing static tokens. Original values are encrypted and stored within a developer’s Basis Theory environment. In exchange, we pass back Tokens, or undecipherable aliases that reference the original value, for developers to use within their code. This allows sensitive data to be stored in an encrypted state for as long as possible.

Encryption management. Abstracting the complexities of encrypting, managing, and rotating keys were high on our list, but not just for the developer experience: When coupled with tokens, the approach allows Basis Theory to update encryption algorithms over time without disrupting developers’ systems.

Making it simpler to use your sensitive data

Tokens provide utility and security. Tokens protect data by keeping the original raw values encrypted at rest. In addition, a Token’s attributes—like user-defined metadata, fingerprinting, and custom masking—make them usable and searchable, allowing developers to reveal all or partial raw values, recognize token contents, create associations, and query their parameters in milliseconds.

Tools to interact with your data. Developers already know how to write code to solve problems. Reactors provide a secure, compliant environment to execute code against an organization’s sensitive data—without exposing its systems to the underlying raw value. Similarly, our Proxy solution allows you to use your existing HTTP client to detokenize data in-flight and forward it to the desired destination.

Making it simpler to manage your sensitive data

Granular access controls and permissioning. Assigning classifications and NIST impact levels to your data allows developers to tailor access, visibility, and functionality to the underlying data. Tenants provide an additional control layer, allowing developers to segment data by the environment, customer, use case, or business unit.

Enable automation. 100% of the engineers we interviewed want to automate their jobs' mundane and error-prone responsibilities, so we ensured that engineers could manage their entire experience through our API. As a bonus, we also built a Terraform Provider.

Centralized operations. This one is pretty straightforward. Engineering, security, and support teams can access logs, search their data, debug, and manage user access, all via the Web Portal or the API.

Last thing

We have a long journey to helping all developers secure their data, but you can get started today. Check out our dev docs, visit our GitHub, or take a few seconds to spin up your own PCI-compliant environment by creating a free account (you can get to production without a card on file).

Special thanks to our incredible team and group of investors, Bessemer Venture Partners, Kindred Ventures, Conversion Capital, Offline Ventures, Ludlow Ventures, BoxGroup, and Good Friends!