If someone steals our encrypted data, can they read it? Usually not, if they took a disk or a backup. Usually yes, if they took a login or the key. Four questions decide which, including what a quantum computer changes. Als iemand onze versleutelde data steelt, kan hij die dan lezen? Meestal niet als hij een schijf of back-up meenam. Meestal wel als hij een inlog of de sleutel meenam. Vier vragen bepalen welke van de twee, inclusief wat een quantumcomputer verandert.
Encryption at rest scrambles data where it is stored: on the disk, in the database, in the backup. Most cloud storage now does this by default. Amazon S3 encrypts every new upload since January 2023, and Microsoft Azure Storage encryption cannot be switched off. But the system unlocks the data for every user and application that logs in. A stolen laptop that was switched off, or a disk taken from a data centre, yields nothing readable. A phished account, a leaked access key or ransomware running on the server reads everything in plain text.
Business impact: "encrypted at rest" in a supplier questionnaire answers the stolen-disk question, not the stolen-login question. What protects the running system is who can log in and whether anyone notices unusual reading.
Versleuteling van opgeslagen data maakt gegevens onleesbaar waar ze staan: op de schijf, in de database, in de back-up. De meeste cloudopslag doet dit inmiddels standaard. Amazon S3 versleutelt sinds januari 2023 elke nieuwe upload, en de versleuteling van Microsoft Azure Storage kunt u niet uitzetten. Maar het systeem ontsleutelt de data voor elke gebruiker en applicatie die inlogt. Een gestolen laptop die uit stond, of een schijf uit een datacenter, levert niets leesbaars op. Een gephisht account, een uitgelekte toegangssleutel of ransomware op de server leest alles gewoon.
Bedrijfsimpact: "versleuteld opgeslagen" in een leveranciersvragenlijst beantwoordt de vraag over een gestolen schijf, niet die over een gestolen inlog. Wat het draaiende systeem beschermt, is wie kan inloggen en of iemand opmerkt dat er ongebruikelijk veel wordt gelezen.
AI does not break the encryption itself. It makes the easy route faster: convincing phishing for exactly the login the system decrypts for.AI breekt de versleuteling zelf niet. Het maakt de makkelijke route sneller: overtuigende phishing voor precies de inlog waarvoor het systeem ontsleutelt.
An AI assistant with broad read rights sees the decrypted data like any other user. Encryption at rest does nothing to limit what it can find and summarise.Een AI-assistent met ruime leesrechten ziet de ontsleutelde data zoals elke andere gebruiker. Versleuteling van opgeslagen data beperkt niet wat hij kan vinden en samenvatten.
AI-based detection can flag one account suddenly reading far more than usual, which is what theft through a valid login looks like.Detectie met AI kan signaleren dat één account ineens veel meer leest dan normaal, en zo ziet diefstal via een geldige inlog eruit.
Encryption does not remove the secret; it moves it into the key. A key stored next to the data, in the same backup, a configuration file or a script, is a safe with the key taped to the door. Cloud providers manage keys for you by default. That is convenient, but anyone with enough admin rights in your cloud account can then use the key. For the most sensitive data, consider a key you manage in a KMS or HSM, with different people managing keys and data.
Business impact: a stolen backup with its key is simply a readable backup. The GDPR relief for encrypted data only helps if the data stays unintelligible to the thief, so not if the key went too. The reverse also bites: lose the key and you lose the data yourself. The key backup deserves the same care as the data backup.
Versleuteling haalt het geheim niet weg; het verplaatst het naar de sleutel. Een sleutel die naast de data staat, in dezelfde back-up, een configuratiebestand of een script, is een kluis met de sleutel op de deur geplakt. Cloudleveranciers beheren de sleutels standaard voor u. Dat is handig, maar dan kan iedereen met genoeg beheerrechten in uw cloudaccount de sleutel gebruiken. Overweeg voor de gevoeligste data een sleutel die u zelf beheert in een KMS of HSM, met verschillende mensen voor het beheer van sleutels en van data.
Bedrijfsimpact: een gestolen back-up met de sleutel erbij is gewoon een leesbare back-up. De verlichting die de AVG biedt voor versleutelde data helpt alleen als de data onleesbaar blijft voor de dief, dus niet als de sleutel ook weg is. Omgekeerd geldt het ook: raakt u de sleutel kwijt, dan bent u de data zelf kwijt. De back-up van de sleutel verdient dezelfde zorg als die van de data.
Attackers use AI tools to search stolen code, file shares and chat history for keys and passwords in minutes. A key left in a script is found first.Aanvallers doorzoeken met AI in minuten gestolen code, bestandsshares en chatgeschiedenis op sleutels en wachtwoorden. Een sleutel in een script wordt als eerste gevonden.
Developers paste code with a key into an AI coding assistant or chatbot, and the key now sits in a system you do not control.Ontwikkelaars plakken code met een sleutel erin in een AI-codeassistent of chatbot, en de sleutel staat dan in een systeem dat u niet beheert.
Secret-scanning tools, increasingly AI-assisted, block keys from entering code and alert when a key is used from an unusual place.Tools die naar geheimen scannen, steeds vaker met AI, houden sleutels uit de code en waarschuwen als een sleutel vanaf een ongebruikelijke plek wordt gebruikt.
Encryption at rest is a setting of the place where data is stored, not a property of the data. The database is encrypted. The nightly export to a file share, the spreadsheet on a USB stick, the old laptop without disk encryption and the test system loaded with real data may not be. Once data is copied, the copy gets whatever protection the new place has.
Business impact: the report says "all systems encrypted", and the incident happens on the copy that was not a system. Because that copy was readable, the encryption relief does not apply, and when the risk is high you inform the people affected. Checking coverage per storage location, including laptops and removable media, closes the gap.
Versleuteling van opgeslagen data is een instelling van de plek waar data staat, geen eigenschap van de data zelf. De database is versleuteld. De nachtelijke export naar een bestandsshare, het spreadsheet op een usb-stick, de oude laptop zonder schijfversleuteling en het testsysteem met echte data misschien niet. Zodra data wordt gekopieerd, krijgt de kopie de bescherming van de nieuwe plek.
Bedrijfsimpact: het rapport zegt "alle systemen versleuteld", en het incident gebeurt op de kopie die geen systeem was. Omdat die kopie leesbaar was, geldt de verlichting voor versleutelde data niet, en bij een hoog risico informeert u de betrokkenen. Controleer de dekking per opslagplek, inclusief laptops en usb-sticks; dat dicht het gat.
Once inside, attackers let AI sift a file share in minutes for the one readable export among thousands of encrypted files.Eenmaal binnen laten aanvallers AI in minuten een bestandsshare doorzoeken naar die ene leesbare export tussen duizenden versleutelde bestanden.
Staff upload an export to a public AI chatbot to analyse it, creating one more readable copy outside every control you have.Medewerkers uploaden een export naar een publieke AI-chatbot om die te analyseren, en zo ontstaat nog een leesbare kopie buiten al uw maatregelen.
Data-discovery tools recognise sensitive content across drives, mailboxes and cloud storage, and report which locations are not encrypted.Datadiscoverytools herkennen gevoelige inhoud op schijven, in mailboxen en in cloudopslag, en melden welke plekken niet zijn versleuteld.
Stored data is almost always encrypted with AES, and 256-bit AES is the cloud default. NIST expects even 128-bit AES to remain secure for decades, quantum computers included. What a large enough quantum computer would break is public-key encryption such as RSA and ECC. For stored data that matters in two places: traffic that was recorded on the way to storage (harvest now, decrypt later), and files or backups encrypted to someone's public key, such as encrypted email archives.
Business impact: for secrets that must stay secret for ten years or more, the quantum risk sits in the network and in public-key encrypted archives, not in the database disk. Knowing where public-key encryption protects your data is the first step. The quantum briefing covers the suggested timelines.
Opgeslagen data wordt vrijwel altijd versleuteld met AES, en 256-bits AES is de standaard in de cloud. Het NIST verwacht dat zelfs 128-bits AES nog decennia veilig blijft, ook tegen quantumcomputers. Wat een voldoende krachtige quantumcomputer wel zou breken, is versleuteling met publieke sleutels, zoals RSA en ECC. Voor opgeslagen data speelt dat op twee plekken: verkeer dat onderweg naar de opslag is opgenomen (nu buitmaken, later ontsleutelen), en bestanden of back-ups die met iemands publieke sleutel zijn versleuteld, zoals versleutelde e-mailarchieven.
Bedrijfsimpact: voor geheimen die tien jaar of langer geheim moeten blijven, zit het quantumrisico in het netwerk en in archieven met publieke-sleutelversleuteling, niet in de databaseschijf. Weten waar publieke-sleutelversleuteling uw data beschermt, is de eerste stap. De quantumbriefing behandelt de voorgestelde tijdlijnen.
AI does not make breaking AES practical. The quantum threat is separate, and aimed at public-key encryption.AI maakt het breken van AES niet haalbaar. De quantumdreiging staat daar los van, en richt zich op publieke-sleutelversleuteling.
AI-generated code can still pick outdated algorithms or hard-code keys. It works, passes a demo, and quietly weakens what is stored.Door AI geschreven code kan nog steeds verouderde algoritmen kiezen of sleutels in de code zetten. Het werkt, slaagt in de demo, en verzwakt stilletjes wat wordt opgeslagen.
Tools can scan code, configurations and certificates to list where RSA and ECC protect your data, the inventory that every quantum plan starts with.Tools kunnen code, configuraties en certificaten scannen om te laten zien waar RSA en ECC uw data beschermen: het overzicht waarmee elk quantumplan begint.
| Control | Addresses | In one line |
|---|---|---|
| Access first | Login (01) | MFA, least privilege and alerts on bulk reading. These protect the running system; encryption at rest does not. |
| Field-level encryption | Login (01) | For the few most sensitive fields, encrypt inside the application, so a database administrator sees only scrambled values. |
| Keys apart from data | Keys (02) | No keys in backups, scripts or config files. Keys live in a KMS or vault, and every use is logged. |
| Your own key for crown jewels | Keys (02) | Consider customer-managed keys for the datasets that would hurt most. Provider-managed keys are fine for the rest. |
| Separate key admins | Keys (02) | The people who manage keys are not the people who can read the data. |
| Tested key recovery | Keys (02) | A key backup kept apart from the data backup, and a restore that is actually tested. |
| Coverage check | Copies (03) | Once a year, per storage location: encrypted or not. Include laptops, removable media, exports and test systems. |
| Crypto inventory | Quantum (04) | A list of where public-key encryption protects stored or transported data. The start of any quantum plan. |
| Maatregel | Pakt aan | In één zin |
|---|---|---|
| Eerst toegang | Inlog (01) | MFA, minimale rechten en meldingen bij massaal lezen. Die beschermen het draaiende systeem; versleuteling van opgeslagen data doet dat niet. |
| Versleuteling per veld | Inlog (01) | Versleutel de paar gevoeligste velden in de applicatie zelf, zodat een databasebeheerder alleen onleesbare waarden ziet. |
| Sleutels apart van data | Sleutels (02) | Geen sleutels in back-ups, scripts of configuratiebestanden. Sleutels staan in een KMS of kluis, en elk gebruik wordt gelogd. |
| Eigen sleutel voor kroonjuwelen | Sleutels (02) | Overweeg zelfbeheerde sleutels voor de datasets die het meeste pijn doen. Sleutels van de leverancier volstaan voor de rest. |
| Aparte sleutelbeheerders | Sleutels (02) | Wie de sleutels beheert, is niet wie de data kan lezen. |
| Getest sleutelherstel | Sleutels (02) | Een back-up van de sleutel, apart van de data-back-up, en een herstel dat echt is getest. |
| Dekkingscontrole | Kopieën (03) | Eén keer per jaar, per opslagplek: versleuteld of niet. Inclusief laptops, usb-sticks, exports en testsystemen. |
| Crypto-overzicht | Quantum (04) | Een lijst van waar publieke-sleutelversleuteling opgeslagen of verzonden data beschermt. Het begin van elk quantumplan. |
Breaking the encryption is unlikely. Walking around it, through a login, a key left next to the data or an unencrypted copy, is not.De versleuteling breken is onwaarschijnlijk. Eromheen lopen, via een inlog, een sleutel naast de data of een onversleutelde kopie, is dat niet.
Readable stolen data can mean notifying the regulator and, when the risk is high, the people affected. A lost key without a backup means the data is gone for you too.Leesbare gestolen data kan betekenen: melden bij de toezichthouder en, bij een hoog risico, bij de betrokkenen. Een verloren sleutel zonder back-up betekent dat de data ook voor u weg is.
With keys apart from the data, coverage checked and access tightened, stolen media stay unreadable and a stolen login reaches less.Met sleutels apart van de data, gecontroleerde dekking en strakkere toegang blijven gestolen media onleesbaar en bereikt een gestolen inlog minder.
The CISO owns the encryption and key policy. The data owners decide which datasets deserve their own keys.De CISO is eigenaar van het versleutelings- en sleutelbeleid. De data-eigenaren bepalen welke datasets een eigen sleutel verdienen.
% of storage locations with encryption confirmed · crown-jewel datasets on keys you manage · people who can both manage keys and read data · date of the last tested key restore.% opslagplekken waarvan versleuteling is bevestigd · kroonjuwelen op sleutels die u zelf beheert · mensen die zowel sleutels beheren als data kunnen lezen · datum van het laatst geteste sleutelherstel.
“Encrypted data becomes readable when a login, a key stored with the data, or an unencrypted copy is compromised, which can become a notifiable breach.”“Versleutelde data wordt leesbaar als een inlog, een sleutel die bij de data staat of een onversleutelde kopie wordt buitgemaakt, wat een meldplichtig datalek kan worden.”
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| GDPR | Encryption is named among the appropriate security measures (Art. 32(1)(a)). Whether you use it depends on the risk. | A supplier that processes your personal data needs a processing agreement (Art. 28). Ask where the keys are and who at the supplier can use them. | Notify the Autoriteit Persoonsgegevens within 72 hours (Art. 33); inform the people affected when the risk is high (Art. 34). That second duty can fall away if the data was unintelligible to the thief, for example encrypted with the key still safe (Art. 34(3)(a)). |
| NIS2 | NIS2 requires policies and procedures on cryptography and, where appropriate, encryption (Art. 21(2)(h)). In the Netherlands this runs through the Cyberbeveiligingswet, in force since 15 August 2026. | Ask for their encryption policy and who holds the keys. "Encrypted at rest" alone answers only the stolen-disk question. | A theft of readable data can count as a significant incident if it meets the thresholds. Early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. |
| DORA | The RTS on ICT risk require a policy for encrypting data at rest and in transit, key management over the whole key lifecycle, and updating cryptography as cryptanalysis develops (Art. 6–7). | Every ICT third party holding your data belongs in the register. Ask where its keys live and whether you can revoke them. | Classify promptly. Initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours of the initial notification, final report within one month. |
| SOC 2 | Criterion CC6.1 covers protecting information assets. Its points of focus include encrypting data at rest where the risk calls for it and protecting encryption keys. | Check that key protection is tested, not only "encryption enabled". Check whether the cloud provider underneath is carved out of the report. | A compromised key or an unencrypted copy of in-scope data will likely appear as an exception in the next report. |
| ISAE 3402 | The focus is financial reporting. Encryption only appears where it protects data that feeds the financial process. | The report rarely tells you who holds the keys. Ask for it in the contract instead. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| AVG | Versleuteling wordt genoemd als passende beveiligingsmaatregel (art. 32 lid 1 onder a). Of u het inzet, hangt af van het risico. | Een leverancier die uw persoonsgegevens verwerkt, heeft een verwerkersovereenkomst nodig (art. 28). Vraag waar de sleutels staan en wie bij de leverancier ze kan gebruiken. | Meld het binnen 72 uur bij de Autoriteit Persoonsgegevens (art. 33); informeer de betrokkenen als het risico hoog is (art. 34). Die tweede plicht kan vervallen als de data onbegrijpelijk was voor de dief, bijvoorbeeld versleuteld met de sleutel nog veilig (art. 34 lid 3 onder a). |
| NIS2 | NIS2 vraagt beleid en procedures voor cryptografie en, waar passend, versleuteling (art. 21 lid 2 onder h). In Nederland loopt dit via de Cyberbeveiligingswet, van kracht sinds 15 augustus 2026. | Vraag naar hun versleutelingsbeleid en wie de sleutels heeft. "Versleuteld opgeslagen" beantwoordt alleen de vraag over een gestolen schijf. | Diefstal van leesbare data kan als significant incident gelden als het de drempels haalt. Vroegtijdige waarschuwing binnen 24 uur na ontdekking, incidentmelding binnen 72 uur, eindverslag binnen een maand. |
| DORA | De RTS over ICT-risico vragen beleid voor versleuteling van opgeslagen en verzonden data, sleutelbeheer over de hele levenscyclus van sleutels, en het bijwerken van cryptografie naarmate de cryptoanalyse zich ontwikkelt (art. 6–7). | Elke ICT-derde die uw data bewaart, hoort in het register. Vraag waar zijn sleutels staan en of u ze kunt intrekken. | Classificeer snel. Eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na ontdekking), tussenrapport binnen 72 uur na de eerste melding, eindrapport binnen een maand. |
| SOC 2 | Criterium CC6.1 gaat over het beschermen van informatieassets. De aandachtspunten omvatten versleuteling van opgeslagen data waar het risico daarom vraagt, en bescherming van sleutels. | Controleer of sleutelbescherming wordt getest, niet alleen "versleuteling aan". Controleer of de onderliggende cloudleverancier buiten het rapport is gelaten. | Een gecompromitteerde sleutel of een onversleutelde kopie van data binnen scope komt waarschijnlijk als afwijking in het volgende rapport. |
| ISAE 3402 | De focus ligt op de financiële verslaggeving. Versleuteling komt alleen aan bod waar het data beschermt die het financiële proces voedt. | Het rapport vertelt zelden wie de sleutels heeft. Vraag daar in het contract naar. | ISAE 3402 schept geen meldplicht aan de auditors van gebruikers. Verwacht een afwijking in het volgende rapport en vraag in het contract om tussentijdse melding. |
Checked against: GDPR Art. 28, 32–34, NIS2 Art. 21 and 23, DORA Art. 19 and RTS (EU) 2024/1774 Art. 6–7, NCSC-NL (Aug 2026), NIST PQC FAQ, NIST IR 8547 (draft, Nov 2024), AICPA Trust Services Criteria CC6.1 (2017, points of focus 2020), AWS S3 and Azure Storage documentation (2026) · September 2026.
Gecontroleerd tegen: AVG art. 28, 32–34, NIS2 art. 21 en 23, DORA art. 19 en RTS (EU) 2024/1774 art. 6–7, NCSC-NL (aug 2026), NIST PQC FAQ, NIST IR 8547 (concept, nov 2024), AICPA Trust Services Criteria CC6.1 (2017, aandachtspunten 2020), documentatie van AWS S3 en Azure Storage (2026) · september 2026.