A reminder to question your plaintext data

Every October is Cybersecurity Awareness Month. You're going to see a lot of good advice about passwords, phishing, multi-factor authentication, and many other security measures. This is great information to pay attention to, and while it’s only a month of awareness, we know that cybersecurity is a constant concern for our customers.

At Evervault, we wanted to share just one principle that sits underneath nearly everything we build: sensitive data shouldn't exist in plaintext in your systems. It’s a simple proposition, but it’s counter to how sensitive data has been handled for decades. So every October, we'll resurface this post as a reminder to go looking for plaintext in your own systems, and figure out whether it really needs to be there.

How plaintext became the default

For a long time, handling sensitive data meant keeping it in plaintext and putting security measures around it. The data (card numbers, social security numbers, API credentials, etc.) passes through application code, logs, databases, and countless other avenues. It’s kind of just been a fact of doing business on the internet.

Because plaintext was assumed, industries built an enormous amount of tooling and process to protect it. Access controls, network segmentation, data loss prevention, monitoring, and recurring audits all exist in part to guard that data. Compliance frameworks and regulations largely assume the same thing. The Payment Card Industry Data Security Standard (PCI DSS) and the Health Insurance Portability and Accountability Act (HIPAA) focus heavily on how to protect sensitive data after you have it.

Those controls matter, and we aren’t suggesting that you skip them. But they cover how to protect sensitive data instead of questioning whether it should exist as plaintext in the first place.

Doing a lightweight audit

You might have a process like this in place already, but if not, we’ll run through some things you can do to find and address (sensitive) plaintext data in your own systems. These steps don’t require any special products or tooling, and you can start on them this month.

Find it

Start by mapping where sensitive data lives, not just where it's supposed to live. Production databases and data warehouses are a good starting point, but there are some less obvious places to check:

• Application and infrastructure logs

• Error tracking and observability tools

• Analytics pipelines and event streams

• Backups and database snapshots

• Support tickets, chat transcripts, and internal docs

• Third-party tools, including AI tools if possible

A useful exercise is to follow a single piece of sensitive data through its entire lifecycle. Find out how it gets collected, and then track it through all the systems it touches.

Question it

When you find sensitive data in plaintext, ask whether that system actually needs the raw value. Maybe a support tool has access to an entire social security number when it just needs the last four digits. Or maybe your analytics pipeline needs to connect multiple records to a single person, but it doesn’t need to know that person’s name.

This practice can actually feel a little unintuitive. The assumption is that a piece of data can’t be used if it’s not in its plaintext form (e.g., how do you charge a credit card without the PAN?). The nuance is that eventually, that raw PAN will be used to charge the card, you just don’t need to see or store it in its raw form to help facilitate the payment. There are additional layers to this, like if a network token is used for the transaction, but you get the idea. The point is that Evervault, as well as other solutions, let you work with sensitive data without touching it in plaintext.

Remove it, or encrypt it

Obviously, if you find something you don’t need, stop the collection and delete what you have. This is just good practice, but it's also written into regulations and industry standards. The General Data Protection Regulation (GDPR) requires personal data to be "limited to what is necessary" for the purpose it's processed for. PCI DSS requires you to keep stored account data to a minimum. It also prohibits storing sensitive authentication data, like card verification codes, after authorization, even if it's encrypted.

If you do need the data, see if there’s a way to encrypt it, ideally before it reaches your systems. Evervault has solutions for collecting and encrypting sensitive data so you can safely store it, but there are other options involving external vaults and encryption too.

Why encryption is worth it

Encrypting sensitive data changes the consequences if the data is leaked or stolen. An attacker who gets into a database full of (properly) encrypted values, without the keys, doesn't get anything usable. Regulations like GDPR acknowledge this by having different rules around notifying affected individuals, depending on whether the breached data was properly encrypted.

Compliance scope can also be reduced when you use encryption. For PCI DSS, systems that store, process, or transmit card data are in scope, along with anything connected to them. Reducing where plaintext card data exists reduces the number of systems, people, and processes that have to meet those requirements.

There's also just the benefit of having fewer places to protect or worry about. Every system that doesn’t hold plaintext is one less system that needs its own set of controls.

Where Evervault fits

Evervault encrypts sensitive data before it reaches your systems, and you store the encrypted data while we store the keys. When a third party needs the raw value, Relay decrypts it in transit on the way out. When you need to work with the data, Functions and Enclaves let you run logic on it without it ever being exposed in your environment. We started with card data because it's one of the most regulated and complex types of sensitive data. But the same approach applies to personally identifiable information (PII), banking data, and health data.

See you next October

You don't need to eliminate every instance of plaintext this month to make progress, and not all plaintext data is a risk. Start with just one data type or one system. Find where the sensitive data lives, and then figure out if it needs to be there in its raw form. And if you want to see if Evervault can help you in the process, reach out to us.