Category: Security & Breach Notification
Encryption Rendering Data Unintelligible
Also known as: Encryption, Data encryption, Enciphering
Simply put
Encryption is the process of scrambling data so that it can only be read by someone who holds the correct key to reverse it. Without that key, the data appears as unintelligible ciphertext and generally cannot be understood by unauthorised parties. It is commonly used to protect information both when it is stored and when it is transmitted.
Formal definition
Encryption is a technical security measure that converts plaintext into ciphertext using an algorithm and a key, rendering the data unintelligible to any party lacking the means to decrypt it. In a data protection context it is typically applied to data at rest (for example, on a device or network) and data in transit, and it functions as a control that reduces the risk that data will be intelligible if accessed by unauthorised persons. Its effectiveness is context and implementation dependent, turning on factors such as algorithm strength, key management, and the scope of what is encrypted; encryption should therefore be assessed as one measure within a broader security posture rather than treated as a guarantee of compliance or of data being rendered permanently unintelligible.
Why it matters
Encryption is one of the most widely relied-upon technical security measures in data protection practice. Under the UK GDPR, the ICO specifically references encryption as a measure that can render stored data unintelligible to unauthorised users who lack the key, and it is frequently cited as an example of the kind of technical measure organisations may adopt when implementing appropriate security. Where personal data is protected in a way that makes it unintelligible to unauthorised parties, this can materially reduce the risk to individuals if that data is accessed or exfiltrated, and may be relevant to how an organisation assesses and responds to a personal data breach. However, encryption should be understood as a risk-reduction control rather than a guarantee of compliance.
Who it's relevant to
Data protection officers and compliance leads
DPOs and compliance teams typically consider encryption when evaluating whether technical and organisational security measures are appropriate to the risk. Encryption may also be relevant to breach assessment and notification decisions, since data rendered unintelligible to an unauthorised recipient can affect the level of risk to individuals. Its relevance should always be evaluated case by case rather than assumed.
Security engineers and IT teams
Engineers responsible for implementing encryption must address algorithm selection, coverage of data at rest and in transit, and, in particular, key management. Because the protection encryption provides depends heavily on how it is configured and maintained, implementation choices directly influence how effectively data is rendered unintelligible to unauthorised parties.
Lawyers and advisers
Legal advisers may reference encryption when assessing whether security obligations have been met or when advising on breach response. It is important to characterise encryption accurately as a risk-reducing measure whose effect depends on implementation, rather than as a settled guarantee of compliance, and to distinguish general practice from any specific regulator guidance that applies.
Inside Encryption Rendering Data Unintelligible
Encryption as a technical measure
Encryption is a process that transforms personal data into a form that is unintelligible to anyone who does not hold the relevant decryption key. Under the GDPR it is referenced as an example of a technical measure that can support the security of processing, notably in the context of Article 32 (security of processing), though it is one option among several rather than a mandatory requirement in all cases.
State of the art and risk-based application
The appropriateness of encryption is assessed against the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risks to individuals. Whether encryption renders data sufficiently unintelligible depends on the strength of the algorithm, key length, and key management practices, all of which should be evaluated over time as technology evolves.
Key management
The protective effect of encryption depends heavily on how decryption keys are generated, stored, rotated, and access-controlled. Encrypted data remains intelligible to any party holding the key, so the confidentiality benefit is closely tied to the security of the key lifecycle rather than the encryption operation alone.
Relationship to personal data status
Encrypted personal data generally remains personal data for the party able to reverse the process (typically the controller or a party holding the key), because it can be attributed to an identifiable individual. It should not be assumed that encryption converts data into anonymous data outside the scope of the GDPR; this is a context-specific assessment and can diverge from anonymisation.
Relevance to breach notification
Encryption that renders personal data unintelligible to unauthorised persons is commonly cited as a factor relevant to assessing the risk arising from a personal data breach, which may affect obligations around notifying supervisory authorities and communicating to data subjects. This is a risk-based assessment and does not automatically remove notification obligations in all circumstances.
Common questions
Answers to the questions practitioners most commonly ask about Encryption Rendering Data Unintelligible.
If our data is encrypted, are we exempt from having to notify a personal data breach?
No. Encryption does not create a blanket exemption from breach obligations. Under the GDPR breach notification framework, encryption is treated as a factor that may reduce the risk to affected individuals, and where data is rendered unintelligible to unauthorised parties this can affect whether notification to individuals is required. However, the assessment is context and risk dependent: it turns on factors such as the strength of the encryption, whether the key was also compromised, and the overall circumstances of the incident. You should still assess and document each breach, and notification to the supervisory authority may remain necessary. Verify the specific triggers and timelines against the current official text.
Does encrypting personal data mean it is no longer personal data, so the GDPR stops applying?
Generally no. Encryption is typically regarded as a pseudonymisation or security measure rather than anonymisation. Because encrypted data can normally be restored to intelligible form using the key, it remains capable of being attributed to an individual and is therefore still treated as personal data subject to the GDPR. This differs from genuine anonymisation, where re-identification is no longer reasonably possible. Whether any particular technique amounts to anonymisation is subject to assessment and has been the subject of regulator guidance, so you should not assume encryption removes data from scope.
How should we decide what encryption strength or approach is appropriate?
The GDPR references encryption as an example of an appropriate technical measure but does not mandate a specific algorithm, key length, or product. In most cases the appropriate approach is determined through a risk-based assessment that weighs the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing against the risks to individuals. Many organisations align choices with recognised standards and current guidance from security bodies and supervisory authorities. Because recommended parameters evolve, decisions should be documented and periodically reviewed rather than treated as fixed.
Does it matter whether we encrypt data at rest, in transit, or both?
Both are commonly relevant, and the appropriate combination depends on the risks associated with the processing. Encryption in transit typically addresses interception during transmission, while encryption at rest addresses unauthorised access to stored data. In many cases a layered approach covering both is used, but the specific measures should follow from your risk assessment rather than a one-size-fits-all rule. Document why the chosen measures are appropriate for the particular processing activity.
How does key management affect whether encryption provides protection?
Key management is central to whether encryption actually renders data unintelligible to unauthorised parties. If keys are exposed, poorly protected, or accessible to the same parties who could access the data, the protective value of the encryption may be undermined, including in the context of breach risk assessment. Practical considerations generally include controlling who can access keys, separating keys from the data they protect, and managing key generation, storage, rotation and destruction. These practices should be documented as part of demonstrating appropriate security measures.
Can we rely on encryption when using a processor or transferring data to another party?
Encryption can form part of the security measures agreed with a processor and may also feature among supplementary measures considered for international transfers. However, it does not by itself replace the required contractual and legal instruments, such as the processor arrangements required under the GDPR or an appropriate transfer mechanism. Where keys are held or accessible by the recipient, the protective effect for transfer purposes may be limited. The role of encryption as a supplementary measure is subject to evolving guidance and assessment, so its adequacy for a given transfer should be evaluated case by case and reviewed over time.
Common misconceptions
Encrypting personal data means it is no longer personal data and falls outside the GDPR.
For a party able to decrypt the data, it generally remains personal data and within scope, because it can still be linked to an identifiable individual. Encryption is typically a security and pseudonymisation-adjacent measure rather than anonymisation, and the distinction should be assessed case by case.
If data is encrypted, a breach never needs to be reported.
Encryption may reduce the assessed risk of a breach and can be a relevant factor in notification decisions, but it does not create a blanket exemption. The assessment depends on factors such as the strength of the encryption and whether keys may have been compromised, and obligations should be evaluated on the facts.
Any use of encryption satisfies the GDPR's security requirements.
Encryption is one example of an appropriate technical measure, not a guaranteed compliance step. Its adequacy is judged against the state of the art, the risks involved, and the quality of implementation, including key management. Weak or poorly managed encryption may not provide the intended protection.
Best practices
Treat encryption as one part of a broader, risk-based security programme rather than a standalone compliance measure, and document how it fits the nature and risks of the processing.
Implement robust key management, including controlled access, secure storage, and rotation of decryption keys, since the protective value of encryption depends on the confidentiality of the keys.
Periodically review the strength of algorithms and key parameters against evolving state of the art, and record the rationale for the chosen approach.
Do not assume encrypted personal data is anonymous; assess and document its status separately, recognising it generally remains personal data for parties able to decrypt it.
When responding to a breach, assess the effect of encryption on risk to individuals on the specific facts (including whether keys may be compromised) rather than relying on a blanket assumption that notification is unnecessary.
Verify current obligations and any regulator guidance against the applicable official text, as the treatment of encryption and related security expectations can develop over time and may vary between jurisdictions.