Architecture

Keys instead of personal data

We are working on a booking and data exchange system that stores only keys. Only those with a right to it can turn a key back into real personal data.

By Bas Leijder HavenstroomManaging director21 October 2026 · 4 min readLees in het Nederlands

Many old, rusty keys hanging on hooks against a wall — Photo: Iolandino Baiano on Unsplash

We are working on a concept for a booking system, and more broadly for data exchange between companies, that no longer passes real personal data around. The systems hold only keys. Only certain people, systems or companies can turn a key into the real name, address or phone number. If something leaks, what ends up in the open is a list of keys instead of a list of people.

Why we are working on this

Today administrators everywhere had to patch PHP, because two flaws let an attacker run code with the rights of the web server. Erik wrote about it in PHP2Shell: patching fast takes preparation. Once someone gets in that way, they can reach everything the web server can reach, and that usually includes the database.

The leak is also often at a different company from the one the customer bought from. The logistics company CEVA Logistics was hacked at the end of July and shipping data was stolen. Customers of the Dutch web shop bol, De Bijenkorf, ING, Ajax and Ace & Tate were notified, and Valve warned European Steam users. At bol it covered name, address, contact details, the products ordered and tracking links. Twelve companies reported the breach to the Dutch Data Protection Authority.

Those customers never agreed anything with CEVA themselves. Their data was there because a parcel had to be delivered.

How it works

The idea is simple. When a booking comes in, the guest's name, phone number and email address go to a separate vault. The booking system and every party involved get a key: a random code that says nothing about the guest.

If someone really needs to speak to the guest or deliver something, they ask the vault to turn the key into the detail. The vault checks who is asking, which detail they need and whether they need it now. A hotel gets the phone number around the stay, a courier gets the address on the day of delivery. Every lookup is logged.

We have already built this for one detail. For an online travel agency, hotels get an Amsterdam 020 number instead of the guest's mobile number. A hotel only gets the real number after verifying with the booking number and postcode. I described how that works in keeping guests' mobile numbers out of hotel systems. The new concept extends that to all personal data and to every party in the chain.

What it solves and what it does not

If a partner is hacked, the attacker finds keys. Without the vault they cannot do anything with them. The same goes for an application server with a flaw like PHP2Shell: the database holds no names or phone numbers.

The vault itself does become the target. You have to protect it better than the rest, with little access, little code and strict logging. Still, that is one system to get right, instead of the systems of every partner you send data to.

The GDPR still applies. The European Data Protection Board wrote in its guidelines on pseudonymisation that such data remains personal data, as long as someone can link it to a person with additional information. It also wrote that pseudonymisation can reduce risks. So do have your own situation checked.

And not every process can do without real data. A courier needs to see an address in the end, and a hotel needs to be able to call a guest. The concept decides who sees it and when; it does not make the data go away.

What we are still working out

We are still working out how to arrange rights between companies. A partner needs to see something for a while, and that right has to expire again. How do you record that without every partner building its own integration?

Availability matters too. If the vault is down, nobody sees the data. That is safe, but a hotel that cannot reach a guest gains nothing from it.

Whether this works for every sector, I do not know yet. For bookings, and for companies that share customer data with suppliers, such as a web shop with a delivery service, it fits well. My advice is to check now, for every detail you share with a partner, whether they always need it or only at a certain moment. What else well-known breaches teach us is in lessons from well-known hacks.

Want to know more

Would you like to know more about the concept, or do you have a process it might fit? Ask your question in the chat on this page, or leave your details through the contact form. We will get back to you.

Sources

Frequently asked questions

What is the difference between a key and personal data?

A key is a random code that stands in for a name, address or phone number. Without access to the vault that holds the real data, the code says nothing about the person.

Does a system with only keys still fall under the GDPR?

Yes. According to the European Data Protection Board, pseudonymised data remains personal data as long as someone can link it to a person with additional information. Pseudonymisation can reduce the risks, though.

Who can turn a key into real data?

Only the people, systems or companies with a right to it, for the detail they need and at the moment they need it. Every lookup is logged.

About the author

Bas Leijder Havenstroom

Managing director

Together with Erik Schoorl, Bas founded ESBL, one of the two companies behind Brainpower Group. He is managing director of ESBL B.V. and the first point of contact for clients.