They say your data is encrypted. Who can still read it?

What does "encrypted at rest" actually protect?

You will meet this phrase on every supplier's security page. It means the data is unreadable while it sits on the disk, and readable the moment something logs in. Call it storage encryption.

Storage encryption is built to be invisible. That is the selling point rather than an accident. The database unlocks the data when it reads and locks it when it writes, automatically, for every query that arrives with a valid login. Search, sorting, filtering and reports all work exactly as before.

Now read that again, thinking about an attacker.

Think of it as locking the warehouse at night. It stops someone coming through the wall. It does nothing about someone walking in the front door with a staff pass, because the door is built to open for staff passes.

The encryption is never broken. It does exactly what it was built to do, for someone it was never meant to serve.

The threat it was built for is real enough. A drive gets thrown away. A backup tape goes missing in the post. A laptop is stolen. In all of those the data is useless without the key. But those situations used to be a real share of data loss, and today they are a rounding error.

How does data really leave an organisation?

Five patterns cover most reported breaches. Walk each one against storage encryption, and the answer comes out the same every time.

A valid login in the wrong hands. A password is reused, phished, or left in a code repository. A session is stolen. An access key pasted into a chat two years ago still works. The attacker now queries the system as a real user, and every answer comes back readable — because as far as the database is concerned, they are a real user.

The machine account nobody remembers creating. The reporting job. The sync integration. The migration script that was meant to be temporary. These get broad read access early, when the system is small and the grant looks harmless, and they are almost never narrowed later. Most have no owner and no expiry date. A machine account reading everything at three in the morning looks exactly like a machine account doing its job.

The copy made for a good reason. Backups. The analytics warehouse. The test environment refreshed from live data last quarter, just to have something realistic. The spreadsheet somebody exported for a board meeting. Each copy takes the data and leaves the controls behind. A restored backup is a working database, and a working database unlocks the data when it reads.

The system at the edge. The specialist scheduling tool. The payroll bridge. The third-party portal that needed "just read access" to keep two systems in step. Often the least defended part of the chain, holding the most sensitive extract, sitting outside whatever security review covered the main system.

The person who is allowed. An administrator. A support engineer. A contractor whose access outlived the contract. Nobody breaks in at all. Someone with legitimate access reads or exports more than their job needs, and every technical control agrees this is permitted.

One row is a yes for storage encryption. It is the row that almost never happens.

Does a big cloud provider change the answer?

Teams relax when the platform is run by a company with a large security department. The first half of that reasoning is usually true. The conclusion fails, for a structural reason.

Every major platform publishes the same division of labour. The provider secures the infrastructure: the buildings, the hardware, the network. They are very good at it. You secure what runs on it and who can reach it: logins, access scope, which machine account may read which records.

Every breach pattern above sits on your side of that line. The provider's skill is aimed almost entirely at the one threat that has already stopped happening. The green tick in the console means storage encryption, and the database still returns readable data to valid queries. It has to, or the product would stop working.

What is field-level encryption?

Field-level encryption moves the boundary. Instead of the storage layer protecting files underneath the database, the application locks each value before it is ever sent to the database, and unlocks it after it comes back. The database stores, indexes, copies and backs up unreadable data. It never holds the key.

This is a different property rather than a stronger version of the same one. Storage encryption answers: where is the data kept? Field-level encryption answers: who can read it back? It answers that by making the database permanently unable to do so.

Can you still search it?

Partly. A value can be locked in two ways. Lock it differently each time and the database cannot search it at all — maximum protection, used for things like a message or a bank account number, where nothing needs to match. Lock it the same way each time and exact-match lookup still works, which an email address needs, because the login has to find it.

The second mode has a cost worth stating plainly: repeated values show up as repeats. An observer can see that two records share a value, and count how often each one appears, without ever learning what it is.

Some columns also have to stay readable, or the system stops working: record identifiers, the status a workflow filters on, dates used to expire old records. These are the skeleton, chosen on purpose rather than left over. They are also not harmless — they carry shape: who relates to whom, how often, and when. The right approach is to keep them few, name them, and avoid pretending the boundary sits somewhere it does not.

Why do so few suppliers do this?

Rarely ignorance. The work is genuinely expensive, in ways that touch every part of a product — while the alternative takes one afternoon and produces the same green tick on the same compliance questionnaire.

You lose the database. A locked column cannot be sorted, grouped, searched by range or matched with a wildcard. To the database it is a bag of bytes. Exact matching can be brought back. Sorting cannot. Every search box and every report has to be rethought, and the work moves inside the application.

Every new field becomes a decision, with consequences for search, reporting and what an attacker learns. There is no safe default. Teams that add fields quickly find this irritating, which is rather the point: it turns an invisible risk into a visible one, while it can still be changed.

And mistakes stay quiet. If something is missed, nothing breaks and no test turns red. The data is simply written in readable form and looks completely normal, until the day somebody reads the storage directly. The safe path has to be the only path.

None of this is intellectually hard. All of it costs time, and none of it appears in a sales demo. That is the whole explanation for why the checkbox usually wins.

What we have built

An article like this would be worth very little as an argument for something we had yet to do. So here is where we stand, described as things you can test us on.

• Our database administrators cannot read your records. The key is unavailable at that layer.
• A restored backup is unreadable. It holds locked values, not a working copy of your data.
• Your data is separated at the database level, rather than sharing tables and relying on a filter in every query. One missed filter cannot become a cross-customer disclosure.
• Key custody can move without re-encrypting anything, which is what makes country-specific or independent custody practical to offer.
• Our AI search holds no readable text. The index stores no document content and no personal data. It returns references, and the application then fetches and unlocks the records for someone whose access has already been checked.
• Every field is classified when it is created — readable on purpose, locked and searchable, or locked and unsearchable. The classification lives on the field itself, so it cannot drift away from it.

That fifth point deserves a sentence of emphasis, because it is where we expect most platforms to leak over the next few years. It is completely normal — and almost always unexamined — for an AI search index to also hold the original text in readable form, in a store nobody ever classified as holding personal data.

What we are still working on

This is built and running, and parts of it are still being extended — an older area of the platform sits outside the boundary, and the classification work continues. We keep a current list of exactly what is finished and what is in progress, and we will hand it to you during an evaluation. A supplier who tells you their protection has no edges has either avoided looking or decided to stay quiet.

What happens to deleted data in your backups?

There is a contradiction at the centre of every retention policy, and most organisations have quietly agreed to avoid looking at it.

You promise that personal data is deleted after a defined period, or on request. You also keep backups, because an organisation that cannot recover from ransomware or human error is negligent in a different direction. Backups are deliberately unchangeable — that is the whole point. So the record you promised to erase is still sitting in last month's snapshot, and the one before that, and in whichever archived copy somebody made for a migration in 2023 and never mentioned.

Deleting it from the live database is straightforward. Deleting it from the backups is either impossible or unwise.

Impossible, because a backup is a consistent picture of one moment, and removing individual records breaks the property that makes it trustworthy. Unwise, because building the ability to rewrite old backups means building a tool that rewrites history — precisely the capability an attacker most wants and an auditor least wants you to have.

The usual answers, and what is wrong with each

• "Backups age out." Deletions spread as old snapshots expire. This is the standard industry answer and it is defensible — though the data genuinely still exists for the length of that window, and the argument collapses for long-term archives and legal holds.
• "We re-apply a deletion log after any restore." Better, and real organisations do this. It is also a promise about a procedure a human has to perform correctly during a disaster, when everyone is exhausted. Controls that only work when people are calm are no controls.
• "Backups are out of scope." They are in scope, and a supplier who says this is telling you they have yet to think about it.

What actually resolves it

One approach dissolves the problem rather than managing it, and it exists only if the data was locked field by field in the first place.

That turns the problem around. Ordinarily, erasure is a search across an unknown number of locations, and you can never prove you found them all. Here it is one act in one place with a provable outcome, and the copies you failed to find stop mattering.

Two conditions have to hold. The keys must stay out of the backup — otherwise you have backed up the lock alongside the key. And how finely the keys are divided decides what you can erase:

We have the hard part already: each customer has their own key for the data itself, which is genuinely uncommon and is the precondition for the middle row. Today our erasure works the ordinary way — against live data, with backup copies ageing out on their own rotation. Moving to the middle row is a defined piece of work rather than a marketing claim, and we will tell you exactly where it stands when you ask.

If you are evaluating a supplier who claims erasure by key destruction today, those two conditions above are exactly what to test them on. Most will have yet to look.

What it fails to protect you from

A security article listing only strengths should be read as marketing. These are the limits, and the first is the most important sentence here.

An access grant that should not exist. Encryption protects data in storage. It offers nothing against an over-broad access grant. If a person is given access to an area they should stay out of, the platform will unlock the data for them, correctly and immediately, because that is what a grant means. No encryption rescues you from an access-control mistake. Only a review of who has access to what, on a schedule, by someone who understands the organisation.

A compromised application. The application holds the keys. It must, or it could show nobody anything. Field-level encryption raises the cost of an attack substantially and removes whole classes of it, while leaving the application itself as important as ever. It moves the target rather than removing it.

Legitimate export. A user who may see a screen may screenshot it, copy from it, or export it. Every reporting feature is a potential exit route with the encryption already removed. Access scope and audit govern this, rather than encryption.

Shape, if not content. The readable columns tell a story: which records relate to which, how many exist, when they were created. In some settings that shape alone is sensitive. Keeping it minimal is real work and is never entirely finished.

Fourteen questions to ask any supplier

If this article is useful for one thing, let it be this. These questions are hard to answer falsely and easy to answer where the work has actually been done. Ask them of every supplier holding data about your people — and ask them of us.

Three commitments follow from publishing a list like that, and they are the ones we would want you to hold us to. Every new field is classified when it is created, never retrofitted later. The unsafe path is closed rather than discouraged, so a missing setting fails loudly in development instead of quietly in production. And limits are published before anyone asks for them — a supplier who cannot tell you what their protection fails to cover has either avoided looking or decided to stay quiet, and both should worry you equally.

If you take one thing from this

The question to ask about any system holding data about people is never is it encrypted. Every system is encrypted. The question is who can read it back, and what it would take for that list to include someone unintended.

If the answer is "the database does that automatically for anything with a valid login", then the protection you bought defends against a threat that has largely stopped happening, and the breach that reaches your customers will proceed exactly as it would have without it.

Field-level encryption is not free, not complete, and no substitute for access control. It is a deliberate decision to make the database permanently unable to read what it holds — and to pay for that in lost search convenience, extra design work, and a slower path from idea to feature. We think that trade is correct, and we think the next several years will make the case more forcefully than any article can.

Where does the evidence come from?

No breach statistics, industry surveys or vendor-sponsored research are cited here, deliberately. Most widely circulated numbers in this field originate in marketing material. Every claim about how these controls behave follows from how they work, and a reader who disagrees can check it against the documentation of any database product rather than taking our word for anything. The description of our own platform was checked against what is actually running.