Encryption is one of the most frequently cited security safeguards in data protection law. It appears in statutes, regulatory guidance, sectoral standards, and almost every compliance template used today. Yet, in practice, encryption is often reduced to a binary question- “Is the data encrypted?”, asked during ROPA preparation, DPIAs, or audits, without sufficient understanding of what the answer actually signifies.
This article is written from the perspective of a data protection lawyer to explain what encryption actually is, how it is used, what global data protection laws say about it, and highlight a critical gap in current practice: the difference between asking questions and understanding answers. The article argues that meaningful data protection requires not only asking about encryption, but knowing why the question is asked and how to assess the response.
Why This Article Is Being Written
Many data protection professionals with legal backgrounds ask about encryption because they are expected to ask.
The question “Is the data encrypted?” appears in ROPA templates, DPIA questionnaires, vendor due-diligence forms, and compliance tools such as OneTrust. In several organisations, the answer is recorded based on stakeholder confirmation, without further inquiry. In some cases, evidence is not required at all during ROPA preparation. Where evidence is required, uncertainty often arises as to how that evidence should be understood or evaluated.
This creates a gap between documented compliance and actual data protection. Encryption is one of the most important safeguards recognised under data protection law. Treating it as a formality weakens oversight and creates a false sense of assurance.
This article is therefore written to bring clarity to what encryption means in data protection practice, and how lawyers can assess it meaningfully without becoming technical specialists.
What Is Encryption
Encryption is a way of protecting data by converting it into a form that cannot be read by anyone who is not authorised to access it.
In practical terms, encryption ensures that even if personal data is accessed without permission, it remains unreadable unless the person accessing it has the correct key.
If personal data is accessed by an unauthorised party but remains unreadable, the legal assessment of risk, harm, and regulatory response may be very different from a situation where the same data is exposed in plain form.
This is why encryption becomes most relevant not during system design meetings, but during incidents breaches, unauthorised access, or security failures.
What Is Decryption and Why It Matters Legally
Decryption is the process by which encrypted data is converted back into readable form using a key. For lawyers, the critical questions are not technical ones:
- Who holds the decryption keys?
- Who can access them in practice?
- Under what authority is decryption permitted?
Encryption loses much of its legal value if decryption is loosely controlled. Regulators often examine whether encryption meaningfully prevented access to readable data, not merely whether encryption was implemented in theory.
Scenario 1: When Encryption Exists Only on Paper
During a breach assessment for a technology-driven organisation, the initial response was reassuring: “Yes, the data was encrypted.” This was recorded as a positive factor.
A follow-up question was then asked: “Who could decrypt the data?” It emerged that the encryption keys were accessible to several application administrators and were stored within the same environment as the encrypted database. While encryption existed, decryption access was not meaningfully restricted.
From a data protection standpoint, this changed the entire analysis. The issue was no longer whether encryption was implemented, but whether it actually prevented unauthorised access to intelligible personal data. In this context, encryption provided limited practical protection.
This scenario is not unusual. It illustrates a basic truth: encryption without controlled decryption is often treated as ineffective protection.
Types of Encryption That Matter in Practice
Lawyers do not need to understand cryptography. They do need to understand where encryption applies.
- Encryption at rest protects data stored in databases, servers, devices, or cloud storage. If stored data is accessed but remains encrypted, regulators generally assess the risk differently than if the same data were stored in plain form.
- Encryption in transit protects data while it moves between systems or networks. Unencrypted transmission is commonly viewed as a serious weakness, particularly where personal data is shared with third parties or across networks.
- End-to-end encryption ensures that data can be decrypted only by the intended recipient. From a legal perspective, this raises questions of control and responsibility, especially where service providers themselves cannot decrypt the data.
Across all types, the legal question remains the same: who can decrypt the data, and when?
Simple Encryption Concepts Lawyers Should Know
- Symmetric Encryption: The same key encrypts and decrypts data. Legal implication: Whoever controls the key controls access.If the key is compromised, the data may be compromised. This is commonly used for stored data.
- Asymmetric Encryption: Uses a pair of keys one public (to encrypt) and one private (to decrypt). Legal implication: Useful where multiple parties or external relations are involved, and control over decryption must be precisely governed. This approach is often used in communications and authentication systems.
Encryption Standards and Obsolete Methods
- Most lawyers are not expected to assess algorithmic strength, but awareness of commonly used standards helps in reviewing documentation.
- Standards such as AES (Advanced Encryption Standard), RSA, and ECC (Elliptic Curve Cryptography) are widely accepted.
- Older methods like DES or RC4 are no longer considered secure.
From a data protection perspective, reliance on obsolete encryption may be treated as failure to implement reasonable security safeguards.
In practice, outdated encryption is often assessed as equivalent to no encryption where risks were foreseeable.
Heard of “AES-256” or “RSA-2048”?
These are not different encryption “types”, but different strengths and implementations of the same method.
AES (Advanced Encryption Standard):
AES exists in three recognised key lengths- AES-128, AES-192, and AES-256. All three are considered secure. The difference lies in strength and longevity. Commonly used to encrypt data at rest.
- AES-128 is commonly used where data sensitivity is lower or operational speed is prioritised.
- AES-256 is preferred where sensitive personal data is processed, data is retained long-term, or regulatory scrutiny is higher. This is why, in data protection documentation, AES-256 is most frequently recorded for data at rest.
RSA (Rivest–Shamir–Adleman):
RSA is used primarily for secure communication and key exchange, not for encrypting large datasets. Commonly used key lengths include- RSA-2048, RSA-3072, RSA-4096. Typically used for data in transit.
- RSA-2048 is widely accepted as secure and is the most common implementation today.
- RSA-4096 is used where higher assurance or longer-term confidentiality is required.
For data protection purposes, RSA-2048 is generally considered proportionate and defensible, unless specific sectoral or risk factors demand otherwise.
ECC (Elliptic Curve Cryptography):
ECC does not follow the same numbering logic as AES or RSA. Instead, it uses smaller key sizes to achieve equivalent or higher security.
ECC is increasingly used in:
- modern cloud systems,
- mobile applications,
- environments where performance and strong security must coexist.
For lawyers, the key point is not the mathematics, but the implication. ECC usually indicates modern, efficient encryption practices, often replacing RSA in newer systems.
Scenario 2:
During a DPIA discussion, Privacy professional with legal background ask: “What encryption is used for this processing activity?”
The system owner responds: “AES-256 and RSA-2048.”
Privacy professional asked one clarifying question: “Can you confirm where each is applied?”
The response clarifies that:
- AES-256 is used to encrypt customer data stored in the database, and
- RSA-2048 is used to secure data transmission between the application and external service providers.
This scenario reflects the central point of this article: encryption terminology only becomes useful when its purpose and context are understood. In compliance documentation, encryption is often recorded using shorthand references such as AES-256 or RSA-2048. These terms are frequently noted in ROPA, DPIAs, and audit responses, but their significance is not always understood.
What Global Data Protection and Related Frameworks Say About Encryption
European Union: GDPR (General Data Protection Regulation):
Article 32(1)(a) requires implementation of appropriate technical and organisational measures. It explicitly mentions “the pseudonymisation and encryption of personal data” as an example of such measures.
In addition, GDPR breach rules allow an organisation to avoid notifying data subjects if appropriate safeguards (such as encryption) render the personal data unintelligible to anyone not authorised to access it.
India: DPDP Act, 2023 and DPDP Rules, 2025
India’s Digital Personal Data Protection Act, 2023 takes a technology-neutral approach and requires Data Fiduciaries to implement reasonable security safeguards to prevent personal data breaches.
Importantly, the Digital Personal Data Protection Rules, 2025 (notified on 14 November 2025) give operational effect to the Act and require data fiduciaries to adopt appropriate technical and organisational measures, including encryption, to ensure confidentiality, integrity, and protection against unauthorised access.
Encryption is now a recognised safeguard under Indian law’s operational rules, not merely an interpretive expectation,
Its adequacy will be evaluated on effectiveness, governance, and context.
United States: HIPAA and CCPA/CPRA
- HIPAA (Health Insurance Portability and Accountability Act) treats encryption of electronic protected health information (ePHI) as an addressable safeguard- requiring implementation or documented justification for alternative measures.
- CCPA/CPRA (California) limits statutory damages where personal information is encrypted or redacted following a breach.
These provisions show that even in the absence of a national privacy law, encryption is deeply tied to regulatory and liability outcomes.
PCI DSS: Payment Card Industry Data Security Standard
Though not a law, the Payment Card Industry Data Security Standard applies contractually to entities that store, process, or transmit payment card data. Encryption and strong cryptography are mandatory for cardholder data in transit and at rest. Failure to comply can result in contractual penalties and increased legal risk.
Other Jurisdictions
Many other regimes, including Brazil, Singapore, and South Africa, use terms such as “appropriate” or “reasonable” safeguards. Regulators in these jurisdictions treat encryption as an expected technical control in higher-risk scenarios.
Where Data Protection Practice Often Breaks Down
Despite this legal clarity, encryption is often assessed superficially. Professionals may:
- treat encryption as a yes/no question,
- assume encryption automatically reduces liability,
- fail to distinguish between encryption at rest and in transit,
- rely solely on stakeholder assurances.
Scenario 3: Template-Driven Compliance
In a large organisation, the ROPA indicated that encryption was in place across several processing activities, based on confirmations from system owners. No evidence was requested.
Months later, a security incident occurred during data transmission between two internal systems. While the databases were encrypted at rest, the data had been transmitted without encryption.
Post-incident review revealed that the ROPA entry had created an assumption of uniform encryption, when in fact encryption was partial. The issue was not lack of effort, but reliance on templatised questions without understanding their purpose.
This illustrates how compliance documentation can appear complete while masking real gaps in protection.
Why Asking Questions Is Not the Goal
Asking about encryption is necessary. But asking without understanding is meaningless.
The purpose of encryption-related questions is not to complete a document. It is to assess whether personal data is actually protected in a way that would withstand regulatory scrutiny.
What Better Practice Looks Like
A non-technical lawyer does not need to become an engineer. But they should be able to ask and understand the following:
- Is data encrypted at rest and in transit?
- Who controls the encryption keys?
- Who can decrypt the data in practice?
- Is encryption applied consistently across systems and vendors?
- Would the data be intelligible if accessed unlawfully?
These are legal questions. Their answers determine risk, liability, and accountability. Cross-questioning asking why, how, and under what conditions is not technical overreach. It is legal diligence.
Conclusion
Encryption is not a technical distraction in data protection law. It is one of the clearest examples of how legal responsibility and system design intersect.
This article was written to move data protection practice away from mechanical questioning and towards informed judgment. Because compliance does not fail due to lack of questions it fails when questions are asked without understanding what they are meant to test.
Encryption does not merely protect data. It shapes legal outcomes