Encrypting is easy. The key is the work

The wrong question

“Do you encrypt the data?” is a question that always gets a yes, and therefore tells you nothing. Disk encryption is standard, traffic across the internet is encrypted, and every major cloud service encrypts what you put in it without being asked.

The question that does tell you something is: where is the key that undoes it, and who can reach that. Because encrypted data whose key sits next to the safe is not protected. It is only harder to read.

That difference is exactly where an audit lands. Not on whether there is a lock, but on who holds the key.

The three places a key can sit

In practice you meet three models, and the difference between them is not technical but governance.

• The provider manages the key. This is the default in cloud services. It works, it is well protected, and you do not have to think about it. The flip side: you cannot demonstrate that the provider themselves cannot reach it, because that is a property of their system rather than of your policy.
• You supply the key to the provider. Azure and AWS both allow this: you create the key yourself and hand it over for use. You keep sight of the lifecycle and you can revoke it. The key still sits in their environment.
• The key sits in your own hardware. A hardware security module stores keys so they never leave the device. Operations happen inside it; what comes out is the result, not the key. Thales is one of the vendors supplying this, and it is the model regulators point to when the requirement is that a key demonstrably sits outside the provider.

The third model costs more and takes more work than the first two. We propose it when there is a reason, not because it is impressive.

What an audit actually asks

In an audit, a DORA review or a NIS2 conversation the algorithm rarely comes up. Four things do, and all four are administrative.

• Where the key sits. Not “in the cloud”, but in which system, under whose control and in which country.
• Who can reach it. By name, not only by role, with a list that matches who actually works there now.
• When it was last rotated. A key that has sat there for eight years is a finding, even if nothing ever happened to it.
• What happens if it is gone. If nobody can answer that, the backup of that data is theoretical.

Those four questions can be answered without expensive hardware. They cannot be answered without record keeping, and that is where it goes wrong in practice.

The key and the backup

There is one mistake we meet more often than all the others combined: the backup is encrypted with a key that only exists inside the environment you are trying to restore.

That works fine until the day you lose that environment. Then you have copies nobody can open, and you find out at the worst possible moment. Immutable backups do not solve this; they protect against modification and deletion, not against losing the key.

So we do not only test whether a backup comes back, but whether it comes back into an environment that has been rebuilt from nothing. That is a different kind of test, and it produces surprises more often.

What we do here

We do not build encryption and we do not write key management software. What we do:

• Map where the keys are. On a takeover this is almost always the first surprise: there are more than anybody thought, and some sit in a place nobody planned.
• Limit and record access. Per person, with multi-factor authentication, and with a trail that can be read afterwards.
• Schedule rotation. A key, like a certificate, has an end date. We monitor those and flag them well in advance.
• Test recovery without the existing environment. The test that counts is the one where you pretend nothing is left.

How that fits into wider security sits under cybersecurity; how we agree and demonstrate recovery times under data and business continuity.

When hardware makes sense

Hardware key storage makes sense when at least one of these three is true.

• There is a requirement, from regulation or from a client, that keys demonstrably sit outside your cloud provider’s environment.
• You process card data or something else for which a standard asks for it explicitly.
• You must be able to show that nobody — including you — can read out a key, only use it.

If none of the three applies, key management at your cloud provider with good record keeping is the sensible choice, and we say so. Buying something you have no requirement for is money that does not go towards the next gap.