Skip to main content
Governance Authority
Category: Privacy and Cybersecurity

Encryption

Also known as: Data encryption, Cryptographic encryption
Simply put

Encryption is a process that converts readable data into a scrambled form so that only someone with the correct key can read it. It helps protect information from being viewed, stolen, or altered by unauthorized parties. In a governance and compliance context, encryption is commonly used as a control to safeguard sensitive or regulated data.

Formal definition

Encryption is the cryptographic transformation of plaintext data into ciphertext to conceal its original meaning and prevent it from being known or used by unauthorized parties. Only holders of the appropriate key can reverse the transformation (decrypt) to recover the original data. As a security control, encryption supports data confidentiality and integrity objectives; the strength and adequacy of a given implementation depend on the algorithms, key management practices, and applicable regulatory or framework requirements, which vary by jurisdiction, sector, and entity. This entry describes the concept generally and does not prescribe any specific technical standard as mandatory.

Why it matters

Encryption is one of the most widely relied-upon technical controls for protecting sensitive and regulated data. By converting readable information into ciphertext that only a holder of the correct key can reverse, it directly supports confidentiality objectives and can help preserve the integrity of data against unauthorized alteration. For governance, risk, and compliance professionals, encryption is often central to how an organization demonstrates that it has taken reasonable steps to safeguard information it holds, whether that data is at rest in storage systems or in transit across networks.

Because many data protection regimes and security frameworks treat the protection of sensitive data as a core expectation, encryption frequently appears as a candidate control in risk assessments and control frameworks. Its presence or absence can influence the residual risk associated with a data asset, and the adequacy of a given implementation depends on factors such as the algorithms used and how keys are managed rather than on the mere fact that encryption is deployed. Whether encryption is legally required, expected as good practice, or left to management's judgment varies by jurisdiction, sector, and entity type, so professionals should confirm the specific obligations that apply to their organization.

Encryption is not a complete solution on its own. It reduces certain risks but shifts attention to key management, access governance, and the operating effectiveness of the surrounding controls. Treating encryption as a single checkbox rather than as a control whose design and operation must be tested can create a false sense of assurance. This entry is educational and general in nature and does not constitute legal, audit, or compliance advice.

Who it's relevant to

Chief Information Security Officers and security teams
Security functions generally own the design, deployment, and operation of encryption as a technical control, including algorithm selection and key management. They are typically responsible for ensuring that implementations align with the organization's data protection objectives and any applicable requirements.
Chief Compliance and Risk Officers
Compliance and risk functions often assess whether encryption controls address the obligations and risks associated with sensitive or regulated data. They generally evaluate how encryption affects residual risk and whether the control satisfies expectations that vary by jurisdiction, sector, and framework, without assuming any single standard is mandatory.
Internal auditors and assurance functions
Assurance functions typically test both the design and the operating effectiveness of encryption controls, examining not only whether encryption is present but whether it functions as intended over time and whether supporting practices such as key management are sound.
General counsel and legal teams
Legal advisors generally assess whether encryption is a legal requirement or an expected practice for particular data in a given jurisdiction and sector, and how it factors into the organization's demonstration of reasonable safeguards. The applicable obligations depend on the facts and the relevant law.
Boards and relevant committees
Boards and committees such as audit or risk committees typically exercise oversight of the organization's approach to protecting sensitive data, including whether management has implemented appropriate controls. Oversight is distinct from the operational responsibility for deploying and maintaining encryption, which sits with management.

Inside Encryption

Encryption at rest
The protection of stored data, such as data held in databases, file systems, backups, and archives, by rendering it unreadable without the appropriate cryptographic keys. It is typically part of a broader data protection control set owned by IT or information security functions, rather than a governance body.
Encryption in transit
The protection of data as it moves across networks, commonly implemented through transport-layer protocols. It addresses interception risks and is generally distinct from at-rest controls, though both are often required together to protect a data flow end to end.
Key management
The generation, storage, rotation, distribution, and revocation of cryptographic keys. Key management is frequently the point at which control operating effectiveness fails even where the underlying algorithm is sound, and it is often subject to segregation-of-duties considerations.
Algorithms and standards
The cryptographic methods and configurations applied. Some regimes and non-binding technical standards specify acceptable approaches, while others take a principles-based stance requiring 'appropriate' measures without naming a specific algorithm; the applicable expectation varies by jurisdiction, sector, and entity type.
Control design versus operating effectiveness
Encryption as a control has both a design dimension (whether the control, if operating as intended, would mitigate the relevant risk) and an operating-effectiveness dimension (whether it actually functions consistently over the period assessed). Assurance functions typically evaluate both separately.
Governance and accountability context
Encryption is an operational and technical control owned by management and its security functions. The board or a relevant committee generally exercises oversight of the associated information-security and data-protection risk rather than performing the control itself.

Common questions

Answers to the questions practitioners most commonly ask about Encryption.

Does encryption alone make our organization compliant with data protection requirements?
No. Encryption is one technical safeguard among many, not a substitute for a compliance program. While many data protection regimes reference encryption as an example of an appropriate technical measure, and some breach-notification provisions in certain jurisdictions may reduce obligations where affected data was strongly encrypted, requirements typically extend well beyond encryption to include governance, access controls, retention practices, vendor oversight, and documented accountability. Whether encryption satisfies a specific legal obligation depends on the applicable statute, sector, and facts, and should be assessed with qualified legal and compliance advice. Treating encryption as a complete compliance answer is a common misconception.
Is encrypted data automatically secure and no longer at risk?
No. Encryption reduces certain risks but does not eliminate residual risk. Its protective value depends on factors such as the strength of the algorithm, key management practices, whether data is protected at rest and in transit, and whether authorized users or systems can still be compromised. Data is often decrypted in use, and weak key storage, misconfiguration, or credential theft can undermine the control. In risk terms, encryption may lower the inherent risk associated with data exposure, but residual risk remains and should be assessed on its own. Encryption is a control whose operating effectiveness must be evaluated, not assumed.
Who within the organization is accountable for encryption practices?
Accountability is typically distributed across the three lines. Management, often through IT and information security functions (first line), generally owns the design, implementation, and operation of encryption controls and key management. Risk and compliance functions (second line) typically set policy expectations, monitor adherence, and advise on regulatory considerations. Internal audit or equivalent assurance functions (third line) generally provide independent evaluation of control design and operating effectiveness. The board or a relevant committee typically holds oversight responsibility for the adequacy of the control environment but does not perform operational encryption tasks. Specific allocation varies by entity type, size, and structure.
How should encryption be reflected in our risk assessment and control documentation?
Encryption is generally documented as a control mapped to specific risks, such as unauthorized data disclosure. Under frameworks such as COSO or ISO 31000, organizations typically distinguish inherent risk from residual risk after the control is applied, and separately assess control design (whether the control, as designed, would address the risk) from operating effectiveness (whether it functions as intended over time). Documentation commonly records the scope of data covered, protection at rest versus in transit, key management responsibilities, and testing approach. The appropriate level of detail depends on the organization's risk appetite, tolerance, and the sensitivity of the data involved.
What questions should assurance functions ask when evaluating encryption controls?
Assurance functions typically examine both design and operating effectiveness. Relevant lines of inquiry generally include: which data classifications require encryption under policy, whether coverage matches that policy, how encryption keys are generated, stored, rotated, and retired, who holds access to keys, and whether segregation of duties is maintained. Reviewers often test whether controls operate consistently over the period rather than at a single point, and whether exceptions are identified and remediated. The specific scope depends on the audit plan, the entity's risk profile, and applicable regulatory or contractual expectations, and conclusions rest on the professional's own judgment.
How does encryption relate to breach response and notification considerations?
In many jurisdictions, breach-notification regimes may treat strongly encrypted data differently from unencrypted data, sometimes affecting whether or how notification obligations apply, provided decryption keys were not also compromised. However, this varies significantly by jurisdiction, sector, and the specific statute or regulation involved, and no single approach applies universally. Whether an encryption safe-harbor or similar provision is available in a given incident is a fact-specific and legal question that should be assessed with qualified counsel. This entry is educational and does not constitute legal, audit, or compliance advice.

Common misconceptions

Encryption is a legal requirement that applies uniformly across all organizations.
Whether encryption is mandated, and to what standard, depends on the jurisdiction, sector, data type, and applicable regime. Some frameworks are principles-based and call for 'appropriate' technical measures without prescribing encryption specifically, while other rules are more prescriptive. Entries here are educational and not legal, audit, or compliance advice.
If data is encrypted, the associated risk is eliminated.
Encryption typically reduces inherent risk to some level of residual risk rather than removing it entirely. Weak key management, misconfiguration, or gaps in operating effectiveness can leave meaningful exposure, so residual risk should still be assessed against the organization's risk appetite and tolerance.
Deploying encryption is the board's responsibility.
Implementing and operating encryption is generally a management and information-security function activity. The board and its committees typically hold an oversight role over the related risk and control environment, not an operational duty to configure or run the controls.

Best practices

Define clearly which function owns each encryption control, covering data at rest, in transit, and key management, and document the accountability boundary between management as owner and the board or committee as overseer.
Assess and document residual risk after encryption is applied, comparing it against the organization's stated risk appetite and tolerance rather than assuming encryption removes the risk.
Test both control design and operating effectiveness over a defined period, giving particular attention to key management processes where controls commonly fail even when algorithms are sound.
Confirm the applicable legal, regulatory, and framework expectations for the relevant jurisdiction, sector, and data type before treating any specific encryption standard as mandatory, and obtain professional advice on binding requirements.
Apply appropriate segregation of duties over key generation, storage, rotation, and revocation, and maintain records sufficient to support assurance and oversight activities.
Provide governance bodies with concise, accurate reporting on encryption coverage and control status so oversight can focus on risk without overstating the reach or certainty of the protection in place.