Cryptographic Risk, Governance, Ethics, and Compliance

Introduction

Cryptography is often presented as a technical discipline concerned with encryption algorithms, keys, certificates, and digital signatures. In professional practice, however, cryptography is also a governance issue. An organisation may deploy a mathematically strong algorithm and still suffer a serious security failure because keys are poorly managed, responsibilities are unclear, systems are not audited, privacy obligations are ignored, or cryptographic controls are applied to the wrong data.

Cryptographic risk is therefore the possibility that the design, implementation, operation, or governance of cryptographic controls will fail to protect information or will create legal, ethical, financial, or operational consequences. Effective management requires a combination of technical safeguards, policies, standards, risk assessment, accountability, privacy protection, audit evidence, and continuing review.

This chapter examines the relationship between cryptography and organisational governance. It focuses on ISO/IEC 27001, NIST guidance, PCI DSS, data-protection principles, separation of duties, audit controls, and ethical decision-making. The objective is not merely to identify standards, but to show how a security professional translates them into implementable controls.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain cryptographic risk and distinguish technical risk from governance and compliance risk.
2. Apply a risk-management process to encryption, key management, certificates, and digital signatures.
3. Relate cryptographic controls to ISO/IEC 27001, NIST guidance, PCI DSS, and privacy regulation.
4. Design policies involving ownership, access control, separation of duties, audit logging, and incident response.
5. Evaluate ethical issues involving surveillance, personal data, lawful access, disclosure, and cryptographic backdoors.
6. Analyse a practical cryptographic governance scenario and recommend proportionate controls.

1. Cryptography as an Organisational Control

Cryptographic controls support several security objectives:

• Confidentiality: preventing unauthorised disclosure through encryption.
• Integrity: detecting unauthorised alteration through authenticated hashes, message authentication codes, or digital signatures.
• Authenticity: establishing confidence in the identity of a communicating party or signer.
• Non-repudiation: supporting evidence that a particular key was used to sign data, subject to legal and operational conditions.
• Privacy: reducing unnecessary exposure of personal information through techniques such as encryption, tokenisation, and pseudonymisation.

These objectives are related but not identical. Encryption may provide confidentiality without proving who sent a message. A hash may detect accidental or deliberate modification only when the reference value is protected. A digital signature supports integrity and origin authentication, but it does not automatically guarantee that the signer was authorised or that the underlying business transaction was legitimate.

A cryptographic control is effective only when its complete lifecycle is governed. The lifecycle normally includes:

1. identifying information requiring protection;
2. selecting an appropriate cryptographic mechanism;
3. generating keys securely;
4. distributing and storing keys;
5. controlling use and access;
6. rotating, revoking, archiving, and recovering keys; and
7. securely destroying keys when they are no longer required.

The weakest lifecycle stage can undermine the entire control. For example, strong encryption is of limited value if administrators store the decryption key in the same publicly accessible repository as the encrypted database.

2. Understanding Cryptographic Risk

2.1 Risk concepts

Risk is commonly analysed as the combination of the likelihood of an adverse event and its consequence. A simple qualitative model is:

Likelihood represents the estimated possibility that a threat will exploit a vulnerability. Impact represents the resulting harm, such as financial loss, regulatory penalty, safety consequences, operational interruption, or damage to individuals. This expression is a conceptual risk-rating model rather than a universal physical law. Organisations may use qualitative categories such as low, medium, and high, or a numerical scale defined in their risk methodology.

Cryptographic risk can arise from:

• weak or obsolete algorithms;
• incorrect implementation or configuration;
• inadequate randomness during key generation;
• excessive key lifetime;
• unauthorised key access;
• loss of keys without a recovery plan;
• failure to revoke compromised certificates;
• insecure backups;
• poor certificate inventory;
• unencrypted logs, exports, or temporary files;
• unsupported cryptographic libraries;
• non-compliance with contractual or legal requirements; and
• misuse of cryptography to conceal harmful or unlawful activity.

2.2 Inherent and residual risk

Inherent risk is the exposure before controls are applied. Residual risk is the exposure remaining after controls are implemented. For example, a payment environment may have high inherent risk because cardholder data is attractive to attackers. Encryption, tokenisation, access restrictions, monitoring, and key-management controls may reduce the likelihood and impact, but they do not eliminate risk entirely.

Risk acceptance must be an accountable decision. A system owner should not silently accept a cryptographic weakness simply because remediation is inconvenient. Acceptance should identify the weakness, affected assets, business justification, duration, compensating controls, and approving authority.

2.3 Threat modelling for cryptographic systems

Threat modelling asks what must be protected, from whom, and under what assumptions. Relevant questions include:

• Is the attacker a remote criminal, malicious insider, compromised service provider, or nation-state actor?
• Is the information stored, transmitted, processed, or all three?
• Can the attacker access application memory, backups, endpoints, or key-management systems?
• What happens if a certificate authority is compromised?
• Is the threat accidental disclosure, deliberate manipulation, impersonation, or inability to recover data?

A useful analysis separates the data plane from the key plane. The data plane contains protected information and business applications. The key plane includes key-generation services, hardware security modules, key-management systems, certificate authorities, administrators, and recovery mechanisms. Protecting only the data plane is insufficient if an attacker can control the key plane.

3. Governance and Accountability

Cryptographic governance is the system by which an organisation directs, controls, and reviews its use of cryptography. It connects strategic objectives to policies, standards, procedures, technical controls, and evidence.

A sound governance model assigns responsibilities clearly:

One person may hold more than one role in a small organisation, but incompatible duties should not be combined without compensating controls. Governance is weakened when the same administrator can create a key, approve its use, access plaintext, delete audit logs, and certify that controls operated correctly.

3.1 Policy hierarchy

A practical policy hierarchy contains:

1. Policy: mandatory organisational intent, such as “sensitive information must be protected in storage and transit.”
2. Standard: approved technical requirements, such as permitted protocols, minimum key-management requirements, and certificate validity limits.
3. Procedure: step-by-step instructions for tasks such as key rotation or certificate revocation.
4. Guideline: recommended practices for situations requiring professional judgement.
5. Record or evidence: logs, approvals, inventories, test results, and review reports demonstrating operation.

Policies should define scope, ownership, exceptions, enforcement, review frequency, and consequences of non-compliance. A policy that merely says “use strong encryption” is inadequate unless “strong,” “approved,” and “use” are defined in operational terms.

4. Standards and Professional Frameworks

4.1 ISO/IEC 27001

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system (ISMS). It uses a risk-based management approach rather than prescribing one universal technical architecture.

Cryptographic governance within an ISMS may include:

• information classification;
• documented risk assessment and treatment;
• cryptographic policy;
• access control;
• supplier and cloud-service oversight;
• incident management;
• business continuity;
• asset and configuration management;
• competence and awareness; and
• internal audit and management review.

The standard’s control themes have evolved across editions and associated control catalogues. Organisations should consult the edition and statement of applicability relevant to their certification or implementation. Certification does not mean that every system is secure or that every risk has disappeared. It indicates that an assessed management system meets specified requirements within an agreed scope.

4.2 NIST guidance

NIST publications provide practical guidance and control catalogues used widely in government and industry. The NIST Cybersecurity Framework describes functions such as Govern, Identify, Protect, Detect, Respond, and Recover. Cryptographic activities can appear throughout these functions:

• Govern: establish policy, roles, risk strategy, and oversight.
• Identify: inventory data, keys, certificates, systems, and suppliers.
• Protect: encrypt data, restrict key access, and train personnel.
• Detect: monitor key use, certificate anomalies, and unauthorised configuration changes.
• Respond: revoke certificates, rotate keys, investigate misuse, and notify stakeholders.
• Recover: restore services and data using tested key-recovery procedures.

NIST cryptographic guidance also distinguishes algorithm selection from implementation assurance. A recognised algorithm can be deployed insecurely through bad modes, weak randomness, poor authentication, side-channel exposure, or inadequate key handling. Organisations should use current, authoritative guidance rather than relying on informal lists of “approved algorithms.”

4.3 PCI DSS

The Payment Card Industry Data Security Standard applies to environments that store, process, or transmit payment account data, within the scope defined by the applicable standard and assessment method. Cryptographic governance may involve:

• protecting stored account data when required;
• protecting transmission over open, public networks;
• restricting access to cryptographic keys;
• preventing storage of prohibited authentication data after authorisation;
• maintaining policies and procedures;
• testing security controls; and
• demonstrating evidence to an assessor.

PCI DSS is not a general-purpose privacy law and should not be treated as a complete security framework. It addresses payment-card risks, while an organisation may also have obligations under privacy laws, contracts, sector regulations, and its own risk policy.

4.4 Standards versus laws

Standards are usually voluntary unless adopted by contract, regulation, procurement terms, or organisational policy. Laws and regulations may impose mandatory duties, including lawful processing, security safeguards, breach notification, data-subject rights, retention limits, and restrictions on international transfers. Compliance with a standard does not automatically establish compliance with every applicable law.

5. Privacy and Data-Protection Requirements

Cryptography supports privacy but does not by itself make processing lawful. Data-protection regimes commonly require principles such as lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality, and accountability. Exact obligations vary by jurisdiction; professionals must obtain legal advice when applying a specific statute.

5.1 Encryption, pseudonymisation, and anonymisation

Encryption transforms readable data into ciphertext using a key. If the key remains available to the organisation, the data normally remains personal data.

Pseudonymisation replaces direct identifiers with a substitute value while retaining the possibility of re-identification through additional information. It reduces exposure but does not generally remove privacy obligations.

Anonymisation aims to make identification reasonably impracticable, considering available means, context, and likely technological development. Removing names alone is not necessarily anonymisation; combinations of location, dates, and unique attributes may identify a person.

Privacy engineering should consider encryption at rest and in transit, access minimisation, tokenisation, key separation, secure deletion, retention schedules, and privacy-preserving analytics. The organisation should avoid collecting or retaining data merely because encryption is available.

5.2 Data-subject rights and key management

Key management can affect the ability to respond to access, correction, deletion, or portability requests. If data is encrypted but keys are retained indefinitely, “deletion” may not be achieved by deleting only the ciphertext. Conversely, destroying keys may make data irrecoverable and interfere with legal retention or evidence requirements. Retention and destruction decisions therefore require coordination between security, privacy, legal, records-management, and business teams.

5.3 Cross-border processing and cloud services

Cloud encryption may involve customer-managed keys, provider-managed keys, external key-management services, or confidential-computing mechanisms. Governance questions include where keys are generated, where administrators are located, which jurisdiction can compel access, how subprocessors are controlled, and how services operate during provider failure. Contracts should address notification, access controls, audit rights, deletion, incident support, and return of data and keys.

6. Separation of Duties and Access Control

Separation of duties reduces the likelihood that one person can abuse a sensitive process without detection. In cryptographic operations, examples include:

• one employee requests a production key and another approves it;
• one administrator operates a key-management system while another reviews logs;
• application developers cannot retrieve production decryption keys;
• certificate issuance is separated from certificate approval;
• emergency access requires post-event review;
• key custodians use dual control for high-impact operations.

Dual control requires two or more authorised individuals to participate in a sensitive action. Split knowledge ensures that no single person knows the complete secret, such as by dividing key components among custodians. These mechanisms are useful for high-value keys but introduce availability and recovery risks. The organisation must maintain tested procedures for absence, disaster, succession, and emergency response.

Least privilege should apply to keys as well as ordinary accounts. Access should be limited by role, purpose, environment, time, and operation. A service may need to decrypt a particular data field but should not have permission to export the master key or decrypt unrelated databases.

7. Auditability and Evidence

Audit controls provide confidence that cryptographic policies operate in practice. Useful evidence includes:

• inventories of keys, certificates, algorithms, and owners;
• records of key generation, activation, rotation, suspension, and destruction;
• approvals for exceptions and emergency access;
• access reviews and privileged-session records;
• configuration baselines;
• vulnerability and dependency assessments;
• backup and recovery test results;
• certificate revocation records;
• incident tickets and post-incident reviews; and
• independent audit findings.

Logs should be protected against unauthorised alteration, synchronised to a reliable time source, monitored, and retained according to legal and business requirements. Logging sensitive plaintext or complete secret keys creates additional risk. Auditability must be balanced with data minimisation.

An audit tests more than whether a policy exists. It asks whether controls are suitably designed, implemented, consistently operated, and supported by reliable evidence. Sampling, interviews, configuration inspection, technical testing, and review of exceptions may all be necessary.

8. Ethical Principles in Cryptographic Practice

Security professionals have duties beyond formal compliance. Ethical decision-making should consider autonomy, human dignity, fairness, proportionality, accountability, and the prevention of harm.

8.1 Privacy and surveillance

Encryption may protect citizens, employees, patients, and customers from crime and misuse. At the same time, organisations may seek monitoring capabilities for fraud prevention or investigations. Surveillance should have a defined purpose, lawful basis, necessity, proportionality, transparency where appropriate, access restrictions, and independent oversight.

8.2 Backdoors and exceptional access

A deliberate backdoor or universal decryption mechanism creates a concentrated target and may weaken security for legitimate users. Even if introduced for law-enforcement or business reasons, it may be discovered, misused, compelled by another authority, or accidentally exposed. Ethical analysis should examine who controls the mechanism, how misuse is detected, whether affected people can challenge access, and whether less harmful alternatives exist.

8.3 Responsible disclosure

When a cryptographic weakness is discovered, professionals should preserve evidence, assess urgency, notify the responsible vendor or owner, coordinate remediation, and avoid unnecessary disclosure that increases exploitation risk. Concealing a material vulnerability to protect reputation is unethical when it leaves users exposed.

8.4 Equity and accessibility

Strong controls can impose burdens. Multi-factor authentication, recovery procedures, and encrypted services must be designed so that legitimate users are not unfairly excluded. Security controls should consider disability, language, connectivity, socioeconomic conditions, and the needs of vulnerable populations.

9. Governance Metrics and Continual Improvement

Metrics should support decisions rather than reward superficial activity. Useful indicators include:

• percentage of critical systems with an assigned key owner;
• percentage of certificates renewed before expiry;
• number and age of cryptographic exceptions;
• time to revoke a compromised certificate;
• percentage of privileged key operations independently reviewed;
• percentage of recovery tests completed successfully; and
• number of systems using unsupported algorithms.

A metric must have a defined population, calculation method, frequency, owner, target, and interpretation. For example:

The formula assumes that the organisation has a complete and accurate inventory and has clearly defined the measurement period. A high rate may still hide risk if critical certificates are excluded from the inventory.

Continual improvement follows a cycle: assess, prioritise, implement, verify, learn, and reassess. Significant changes such as cloud migration, new payment services, quantum-resistant planning, mergers, or changes in privacy law should trigger a review of cryptographic governance.

10. Applied Case: Meridian Health Services

The following is an illustrative case.

Background

Meridian Health Services operates clinics and an online patient portal. Patient records are stored in a cloud database, transmitted to laboratories, and backed up nightly. The organisation uses encryption for database storage and TLS for network communication. It has recently expanded through acquisition and now has several legacy applications.

Problem

An internal review identifies four weaknesses:

1. The cloud database encryption key is managed by a shared administrator account.
2. A legacy application uses an outdated protocol and has no documented owner.
3. Backups are encrypted, but the recovery key has never been tested.
4. The privacy office cannot determine how long some patient exports are retained.

The organisation is concerned about patient harm, regulatory exposure, service interruption, and audit failure.

Analysis

The first weakness creates accountability and insider-threat risk. Shared accounts prevent reliable attribution and make access review difficult. The second creates technical and governance risk because unsupported systems may not receive security updates and no owner is accountable for remediation. The third creates availability risk: confidentiality protection is ineffective if authorised users cannot restore records after an incident. The fourth creates privacy and retention risk because encrypted data remains subject to governance requirements while the keys and exports remain accessible.

Approach and solution

Meridian establishes a cryptographic governance programme with the following actions:

• appoints data and system owners for every critical application;
• replaces shared administration with named accounts, strong authentication, and privileged-access management;
• introduces dual approval for production key changes;
• creates an inventory of keys, certificates, protocols, data stores, exports, and owners;
• isolates the legacy application and develops a funded replacement plan;
• defines approved cryptographic standards and an exception process;
• performs a controlled backup restoration using authorised recovery custodians;
• establishes retention and secure-destruction rules for patient exports;
• centralises relevant logs and reviews high-risk key operations;
• conducts a privacy impact assessment for the portal and laboratory integration; and
• reports residual risks and remediation deadlines to senior management.

Outcome

Meridian can demonstrate who owns each cryptographic asset, who approved sensitive actions, whether backups can be recovered, and how patient data is retained or destroyed. The organisation has not eliminated all risk, but it has reduced unmanaged exposure and improved its ability to detect, respond to, and explain control failures.

Learning points

The case demonstrates that cryptographic governance is broader than selecting an algorithm. Accountability, lifecycle management, recoverability, privacy, audit evidence, and legacy-system treatment are equally important. It also illustrates that compliance evidence should be generated by normal operations rather than assembled hastily immediately before an audit.

11. Challenges and Contemporary Developments

Cryptographic governance faces several continuing challenges. Organisations often have incomplete inventories, complex supply chains, inconsistent terminology, and limited specialist staff. Certificate expiration can cause outages even when no attacker is involved. Automated key rotation may fail if dependent applications are not designed to reload keys safely. Centralised key-management platforms improve consistency but become high-value targets and may create concentration risk.

The transition toward post-quantum cryptography is an important strategic issue. Large-scale quantum computers could threaten some currently used public-key systems, although the timing and practical capability remain uncertain. Organisations should identify where vulnerable public-key algorithms are used, prioritise long-lived sensitive data, examine supplier roadmaps, and plan for crypto-agility—the ability to replace cryptographic algorithms without redesigning entire systems. This does not justify careless deployment of immature algorithms; migration should follow authoritative standards and tested implementation guidance.

Artificial intelligence can assist with certificate discovery, configuration analysis, anomaly detection, and prioritisation. It can also generate insecure code, expose secrets through prompts or logs, and create false confidence through inaccurate recommendations. AI-assisted security decisions require human review, protected inputs, model governance, testing, and clear accountability.

12. Best-Practice Implementation Roadmap

A diploma-level practitioner can support a practical roadmap:

1. Discover: inventory data, systems, keys, certificates, algorithms, owners, suppliers, and regulatory obligations.
2. Classify: determine sensitivity, business criticality, privacy impact, and retention requirements.
3. Assess: identify threats, vulnerabilities, dependencies, and inherent risk.
4. Define: approve policies, standards, roles, algorithms, key lifetimes, exception rules, and evidence requirements.
5. Implement: deploy suitable encryption, authenticated protocols, key-management controls, access restrictions, logging, and recovery procedures.
6. Verify: test configurations, access, revocation, restoration, monitoring, and separation of duties.
7. Improve: review incidents, audit findings, technology changes, legal developments, and emerging cryptographic threats.

The roadmap should be proportionate. A small system containing low-risk information does not require the same governance complexity as a national payment platform or clinical-record service. Proportionality, however, must not become an excuse for undocumented decisions or uncontrolled exceptions.

Chapter Summary

Cryptographic security is a governance responsibility as well as a technical function. Effective protection depends on the complete lifecycle of keys, certificates, algorithms, data, and recovery mechanisms. Risk assessment should consider likelihood, impact, threats, vulnerabilities, inherent risk, controls, and residual risk.

ISO/IEC 27001 provides a risk-based ISMS structure; NIST guidance connects governance with identification, protection, detection, response, and recovery; and PCI DSS addresses specific risks in payment-card environments. These frameworks complement but do not replace applicable laws, privacy requirements, contracts, or professional judgement.

Privacy requires more than encryption. Pseudonymisation, retention, deletion, transparency, access rights, supplier controls, and lawful processing must also be addressed. Separation of duties, dual control, least privilege, protected logs, independent review, and reliable evidence reduce the likelihood of undetected misuse. Ethical practice requires proportionality, respect for privacy, responsible disclosure, fairness, and careful scrutiny of exceptional-access proposals.

A mature cryptographic programme is measurable, auditable, recoverable, adaptable, and continually improved. It assigns accountable owners and treats cryptographic assets as business-critical resources.

Key Terms

Cryptographic risk: The possibility that cryptographic controls will fail or create harmful consequences.

Residual risk: Risk remaining after controls are implemented.

Inherent risk: Risk existing before controls are applied.

Cryptographic lifecycle: The stages of generating, using, protecting, rotating, recovering, revoking, and destroying cryptographic assets.

Key management: Administrative and technical control of cryptographic keys throughout their lifecycle.

Cryptographic governance: Direction, oversight, accountability, and review of organisational cryptography.

ISMS: Information security management system used to manage information-security risk.

ISO/IEC 27001: An international standard specifying requirements for an information security management system.

NIST Cybersecurity Framework: A framework organising cybersecurity outcomes into functions including Govern, Identify, Protect, Detect, Respond, and Recover.

PCI DSS: A security standard for entities handling payment account data within its defined scope.

Separation of duties: Distribution of incompatible responsibilities among different people or roles.

Dual control: Requirement for two or more authorised people to perform a sensitive action.

Split knowledge: Division of secret information so that no single person possesses the complete secret.

Pseudonymisation: Replacement of identifiers with substitutes while retaining possible re-identification.

Anonymisation: Processing intended to make identification reasonably impracticable.

Crypto-agility: Ability to replace cryptographic algorithms or mechanisms with limited disruption.

Certificate revocation: Formal invalidation of a digital certificate before its scheduled expiry.

Residual risk acceptance: Formal approval to tolerate identified remaining risk.

Audit evidence: Records demonstrating that controls are suitably designed and operating.

Privacy by design: Incorporation of privacy considerations into systems and processes from their inception.

Review Questions

Short Answer Questions

1. What is cryptographic risk, and why is it broader than algorithm selection?
2. Distinguish inherent risk from residual risk.
3. State two differences between encryption and pseudonymisation.
4. Why is separation of duties important in key management?
5. Name three types of evidence that may support a cryptographic audit.

Long Answer Questions

1. Explain how ISO/IEC 27001 and NIST guidance can be used together to govern cryptographic controls.
2. Discuss the relationship between encryption, privacy, retention, and secure deletion.
3. Describe a complete lifecycle for managing a high-value encryption key.
4. Evaluate the ethical and security arguments surrounding exceptional access or cryptographic backdoors.
5. Explain how an organisation should govern cryptography in a cloud-service environment.

Analytical / Application Questions

1. A company discovers that one administrator can generate, approve, use, and destroy production keys. Analyse the risks and propose a revised control structure.
2. A payment service encrypts cardholder data but has no certificate inventory, no tested recovery process, and shared privileged accounts. Assess the likely governance and compliance weaknesses and prioritise remediation.
3. A hospital plans to retain encrypted patient exports indefinitely because “the data is protected.” Evaluate this decision from security, privacy, ethical, and records-management perspectives.

Multiple Choice Questions with Answers

Question 1

Which statement best describes residual risk?

A. Risk that exists before any security controls are applied

B. Risk remaining after security controls are implemented

C. Risk that can never be recorded in an audit

D. Risk caused only by weak encryption algorithms

Correct Answer: B. Risk remaining after security controls are implemented

Question 2

Which practice most directly supports separation of duties in key management?

A. Allowing one administrator to approve and execute all key changes

B. Using the same shared account for all custodians

C. Requiring one employee to request a key change and another to approve it

D. Storing all keys in an unencrypted spreadsheet

Correct Answer: C. Requiring one employee to request a key change and another to approve it

Question 3

Which statement about pseudonymisation is correct?

A. It always makes data anonymous and removes all privacy obligations

B. It replaces identifiers but may allow re-identification using additional information

C. It is identical to deleting the original data

D. It protects only data transmitted over public networks

Correct Answer: B. It replaces identifiers but may allow re-identification using additional information

Question 4

Which ISO/IEC 27001 concept is most closely associated with documenting and treating cryptographic risk?

A. A risk-based information security management system

B. A requirement to use one universal encryption algorithm

C. A guarantee that every system is technically secure

D. A prohibition on internal audits

Correct Answer: A. A risk-based information security management system

Question 5

Which NIST Cybersecurity Framework function includes restoring services and data after a cryptographic incident?

A. Identify

B. Protect

C. Recover

D. Govern

Correct Answer: C. Recover

Question 6

An organisation has 240 certificates due for renewal during a quarter and renews 228 before expiry. Using the stated compliance-rate formula, what is the rate?

A. 90%

B. 92%

C. 95%

D. 98%

Correct Answer: C. 95%

Question 7

Why is encryption alone insufficient to establish lawful processing of personal data?

A. Encryption cannot provide confidentiality

B. Lawfulness also depends on purposes, legal basis, transparency, retention, and other obligations

C. Encrypted data is never personal data

D. Encryption automatically violates privacy law

Correct Answer: B. Lawfulness also depends on purposes, legal basis, transparency, retention, and other obligations

Question 8

What is the main purpose of a certificate inventory?

A. To eliminate the need for certificate renewal

B. To identify certificates, owners, dependencies, and expiry or revocation requirements

C. To permit all users to issue certificates

D. To replace access control with encryption

Correct Answer: B. To identify certificates, owners, dependencies, and expiry or revocation requirements

Question 9

What does crypto-agility mean?

A. Using several passwords for one account

B. The ability to replace cryptographic mechanisms with limited disruption

C. Allowing algorithms to change randomly during a session

D. Avoiding all cryptographic standards

Correct Answer: B. The ability to replace cryptographic mechanisms with limited disruption

Question 10

Which is an important ethical concern regarding a deliberate cryptographic backdoor?

A. It may create a concentrated weakness that can be misused or compromised

B. It guarantees that only authorised investigators can access data

C. It eliminates the need for audit logs

D. It makes key management unnecessary

Correct Answer: A. It may create a concentrated weakness that can be misused or compromised