Governance, Risk, Compliance, and Decision-Making

Introduction

Cryptography is often presented as a technical discipline concerned with algorithms, keys, certificates, and protocols. In practice, however, cryptographic protection succeeds or fails within a governance system. An organization may deploy strong encryption and still suffer a serious security or privacy incident because keys were poorly managed, data stores were overlooked, certificates expired, suppliers used unapproved services, or business owners could not determine which information required protection.

Governance connects cryptographic capability to organizational purpose. It defines authority, accountability, acceptable risk, decision rights, and evidence of control. Risk management helps the organization decide what could go wrong and which safeguards are proportionate. Compliance translates legal, contractual, and regulatory obligations into demonstrable requirements. Decision-making brings these elements together when an organization selects algorithms, approves exceptions, evaluates vendors, responds to audit findings, or decides whether to accept, transfer, mitigate, or avoid risk.

This chapter explains how cryptographic inventories, policies, risk assessments, control frameworks, metrics, audits, and supplier evaluations support defensible decisions. It uses concepts aligned with NIST guidance, ISO/IEC 27001, PCI DSS, privacy law principles, and common organizational governance practices. These frameworks are complementary rather than interchangeable: a law creates obligations, a standard provides a management model, a control framework organizes safeguards, and a policy establishes internal requirements.

Learning Objectives

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

1. Explain why cryptography requires governance and accountable decision-making.
2. Construct a practical cryptographic inventory and identify its limitations.
3. Relate cryptographic policies to NIST, ISO/IEC 27001, PCI DSS, and privacy requirements.
4. Perform a basic qualitative cryptographic risk assessment.
5. Select useful control objectives, metrics, audit evidence, and corrective actions.
6. Evaluate cryptographic practices and risks in third-party suppliers.
7. Distinguish compliance evidence from genuine security effectiveness.
8. Recommend proportionate treatment of cryptographic risks in an organizational scenario.

1. Governance as the Foundation of Cryptographic Protection

Governance is the system by which an organization is directed, controlled, and held accountable. In cryptography, governance answers questions such as:

• Which data must be encrypted, tokenized, hashed, or digitally signed?
• Who owns the decision about a key, certificate, or cryptographic service?
• Which algorithms, key lengths, protocols, and providers are approved?
• How are keys generated, stored, rotated, backed up, revoked, and destroyed?
• Who may authorize an exception, and for how long?
• What evidence demonstrates that a control is operating?

A useful distinction is between governance, management, and operations. Governance sets direction and oversight. Management translates direction into plans, resources, policies, and risk decisions. Operations implement and monitor controls. For example, a board or executive committee may establish a low tolerance for exposure of payment-card data; a security manager may require encryption and centralized key management; system administrators may configure a database and maintain its keys.

Cryptographic accountability should be assigned to identifiable roles. Typical roles include:

• Information owner: determines the sensitivity, business value, and acceptable use of information.
• System owner: ensures that a system implements required safeguards.
• Key custodian: operates or administers key-management facilities under controlled procedures.
• Data protection or privacy officer: advises on personal-data obligations and individual rights.
• Risk owner: accepts, transfers, mitigates, or avoids a risk on behalf of the organization.
• Internal auditor: independently evaluates control design and operation.
• Vendor or procurement manager: ensures that supplier obligations and evidence are included in contracts.

The key principle is that technical administration does not automatically confer authority to accept business or regulatory risk. A person who can rotate a key should not necessarily be the person who decides that an unencrypted data flow is acceptable.

2. Cryptographic Inventories

A cryptographic inventory is a structured record of where and how cryptography is used. It is broader than a list of keys. It may include algorithms, protocols, certificates, keys, hardware security modules, cloud key-management services, applications, data classifications, owners, suppliers, dependencies, and lifecycle dates.

A practical inventory may contain the following fields:

The inventory should distinguish data at rest, data in transit, and, where relevant, data in use. It should also identify cryptographic boundaries. For example, a cloud database may be encrypted at rest, but data could become exposed in application logs, exports, backups, analytics workspaces, or support tickets.

Inventory construction usually combines several methods:

1. Review architecture diagrams, data-flow maps, asset registers, and data-protection impact assessments.
2. Query certificate stores, cloud key-management systems, HSMs, endpoint-management tools, and vulnerability scanners.
3. Inspect application configurations, source-code repositories, infrastructure-as-code, and deployment pipelines.
4. Interview system and data owners.
5. Compare discovered items with approved standards and exception registers.
6. Reconcile duplicates and establish a repeatable update process.

Automated discovery is valuable but incomplete. A scanner may find certificates and TLS endpoints while missing an undocumented application that uses a library-level encryption function. A database inventory may identify encrypted tables but not reveal who can retrieve plaintext through privileged queries. Inventory quality therefore depends on ownership, reconciliation, and periodic validation.

An inventory also supports cryptographic agility. Cryptographic agility is the ability to replace algorithms, libraries, keys, certificates, or protocols without unacceptable disruption. It requires modular designs, documented dependencies, algorithm identifiers, tested migration procedures, and avoidance of hard-coded cryptographic assumptions. Agility is increasingly important because vulnerabilities, regulatory changes, vendor changes, and advances in computing may require migration.

3. Policy Architecture and Control Requirements

A cryptographic policy should state organizational intent and mandatory minimum requirements without becoming an unmaintainable list of implementation details. A layered policy architecture is often effective:

• Information-security policy: establishes overall security principles and accountability.
• Data-classification policy: defines categories and handling requirements.
• Cryptography policy: specifies approved uses, prohibited practices, minimum standards, and responsibilities.
• Key-management standard: defines generation, storage, access, rotation, backup, recovery, revocation, and destruction.
• Certificate-management procedure: addresses issuance, validation, renewal, monitoring, and revocation.
• Operational procedures: explain how teams implement and evidence the controls.
• Exception procedure: establishes risk assessment, approval, compensating controls, expiry, and review.

A policy should avoid statements such as “encrypt sensitive data appropriately” when an auditable requirement is needed. It should instead identify the decision criteria, such as data classification, approved cryptographic modules, transport requirements, separation of duties, and minimum logging. Exact algorithm and parameter choices should be maintained in a technical standard that can be updated more readily than a high-level policy.

Policies must address the complete key lifecycle:

1. Generation: use approved, adequately random generation processes and trusted cryptographic modules.
2. Distribution: transfer keys through controlled channels and restrict exposure.
3. Storage: protect keys separately from encrypted data where feasible; use access control and hardware protection for high-value keys.
4. Use: restrict operations, log administrative actions, and prevent unnecessary plaintext exposure.
5. Rotation or renewal: change keys according to risk, compromise indicators, technical limits, or contractual requirements.
6. Backup and recovery: protect backups and test recovery without creating uncontrolled copies.
7. Revocation and suspension: respond to compromise, loss of trust, personnel changes, or certificate invalidity.
8. Destruction: securely destroy keys when retention and recovery requirements no longer apply.

A policy also needs exception governance. An exception should identify the affected asset, business reason, risk, compensating controls, risk owner, expiry date, and review date. Permanent exceptions are usually evidence that the policy or architecture needs reconsideration.

4. Relating Frameworks, Laws, and Requirements

Organizations frequently confuse frameworks with laws. Their roles differ:

NIST CSF 2.0 organizes cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond, and Recover. Cryptographic governance appears particularly in Govern and Identify, while implementation and monitoring span Protect and Detect. NIST SP 800-57 provides key-management guidance, and NIST SP 800-53 supplies control families such as access control, audit and accountability, identification and authentication, system and communications protection, and supply-chain risk management.

ISO/IEC 27001 requires an information-security management system based on organizational context, leadership, risk assessment, risk treatment, continual improvement, and documented evidence. Annex A controls support the ISMS but do not replace risk assessment. An organization should not claim that selecting a control automatically proves effective implementation.

PCI DSS applies specifically to payment-account-data environments and related systems within the defined scope. It includes requirements concerning stored account data, transmission over open networks, access control, logging, vulnerability management, testing, and service providers. Encryption does not by itself remove systems from PCI DSS scope. Tokenization and segmentation may reduce exposure, but scope decisions require careful analysis.

Privacy laws generally emphasize principles such as purpose limitation, data minimization, confidentiality, integrity, accountability, retention limitation, transparency, and appropriate technical and organizational measures. Encryption may reduce the impact of a breach and, in some legal regimes, affect notification analysis, but it does not eliminate all legal duties. Organizations must evaluate the applicable jurisdiction, data type, processing role, contracts, and regulator guidance.

5. Cryptographic Risk Assessment

Risk assessment is a structured method for understanding uncertainty and prioritizing treatment. A simple qualitative model considers:

• Asset and data value: What would be harmed if confidentiality, integrity, or availability failed?
• Threat: Who or what could cause harm?
• Vulnerability or exposure: What weakness makes the event more plausible?
• Likelihood: How plausible is exploitation or failure?
• Impact: What would be the consequence?
• Existing controls: Which safeguards reduce likelihood or impact?
• Residual risk: What remains after controls?

A commonly used conceptual relationship is:

Likelihood and impact in this expression are usually ordinal ratings, such as 1 through 5, not precise physical measurements. The multiplication creates a prioritization score; it does not establish a scientifically exact probability or financial loss. Organizations should define rating criteria consistently and avoid comparing scores from incompatible scales.

A five-level example is:

Suppose an organization stores payment data in a database. A legacy service uses an obsolete transport protocol. The team rates likelihood as 4 and impact as 5, producing a prioritization score of 20. After disabling the protocol, enforcing modern authenticated transport, monitoring configuration, and testing dependent applications, likelihood may be reassessed as 2 while impact remains 5. The residual score is 10. This does not mean the risk has disappeared; it means the likelihood assessment changed. The risk owner must decide whether 10 is acceptable or requires further treatment.

Risk treatment options are:

• Avoid: stop the risky processing or redesign the service.
• Mitigate: reduce likelihood or impact through controls.
• Transfer or share: use insurance, contractual allocation, or a managed service, while recognizing that accountability is rarely transferred completely.
• Accept: formally acknowledge the residual risk within delegated authority.

A strong assessment records assumptions, evidence, affected data, control dependencies, risk owner, treatment due date, and review trigger. Triggers include a cryptographic vulnerability, a new law, a supplier change, a major architecture change, or a suspected key compromise.

6. Metrics, Assurance, and Audit

Metrics translate governance objectives into observable evidence. A metric should have a defined numerator, denominator, time period, owner, data source, and target. For example:

The formula assumes that the inventory population is complete and that “meeting policy requirements” has an agreed definition. If 940 of 1,000 in-scope certificates meet requirements, the rate is 94%. Reporting only the percentage could conceal that 60 noncompliant certificates affect critical systems; therefore metrics should be accompanied by severity and exposure information.

Useful metrics include:

• Percentage of critical assets with an assigned cryptographic owner.
• Percentage of inventory items reconciled within the required period.
• Number of expired or soon-to-expire certificates.
• Percentage of high-risk keys protected by approved key-management services.
• Median time to revoke a compromised certificate.
• Number and age of cryptographic exceptions.
• Percentage of suppliers with current security evidence and contractual requirements.
• Number of systems using deprecated algorithms or protocols.
• Percentage of recovery tests that successfully restore encrypted data.

Metrics can be leading indicators, such as inventory completeness and training coverage, or lagging indicators, such as incidents, failed audits, and certificate outages. A mature program uses both. Metrics should support decisions rather than reward superficial compliance. For example, a high key-rotation rate may be undesirable if rotation is performed without testing recovery or updating dependent services.

Audit and assessment are related but distinct. An internal audit provides independent assurance against defined criteria. A control assessment examines whether controls are designed and operating as intended. A compliance assessment checks specified requirements. A penetration test examines selected technical weaknesses. None of these alone proves that cryptography protects every relevant data flow.

Audit evidence may include:

• Approved policies and standards.
• Inventory records and reconciliation reports.
• Key-management and certificate-management configurations.
• Access reviews and privileged-operation logs.
• Change records and separation-of-duty evidence.
• Vulnerability scans and configuration tests.
• Recovery and revocation test results.
• Supplier contracts, attestations, and assessment reports.
• Exception approvals and remediation tracking.

Evidence must be reliable, current, attributable, and sufficient for the control claim. A screenshot taken once is weaker evidence than a controlled report generated from an authoritative system and sampled over time.

7. Vendor and Supply-Chain Evaluation

Organizations depend on cloud providers, payment processors, certificate authorities, managed security providers, software vendors, and hardware suppliers. Cryptographic risk can enter through any of them. Vendor evaluation should therefore examine both the supplier and the service boundary.

Important questions include:

1. Which party generates, stores, rotates, backs up, and destroys keys?
2. Can the customer control keys, use customer-managed keys, or use an external key manager?
3. Who can access plaintext, metadata, logs, backups, and support channels?
4. Are cryptographic modules validated or independently assessed where required?
5. What algorithms, protocols, key sizes, and certificate authorities are used?
6. How are compromise, suspected government access, or service outages reported?
7. Can the customer retrieve data and securely delete keys at termination?
8. Where are data and keys processed, and what jurisdictions apply?
9. Does the supplier use subcontractors, and are they disclosed and governed?
10. What independent assurance is available, and what are its scope and dates?

A SOC report, ISO certificate, or PCI attestation can be useful but must be interpreted carefully. The organization should verify the report period, service scope, control exceptions, complementary customer controls, and whether the assessed service is the one actually used. A certificate is not proof that every customer configuration is secure.

Contracts should address security obligations, incident notification, audit or evidence rights, data location, subcontracting, retention and deletion, key ownership, business continuity, exit assistance, and cooperation with legal or regulatory requests. Vendor risk should be reassessed when the service architecture, ownership, cryptographic implementation, or legal environment changes.

8. Decision-Making in Practice

Sound cryptographic decisions combine technical evidence with business context. A decision record should identify the problem, alternatives, assumptions, risks, affected stakeholders, selected option, authority, implementation plan, and review date.

For example, a business may ask whether to adopt a cloud key-management service. Relevant criteria include security capability, availability, recovery design, integration, jurisdiction, cost, operational competence, exit feasibility, and concentration risk. The decision should not be reduced to whether the provider supports encryption. Nearly all major providers do; the important questions concern control, visibility, failure modes, and accountability.

A useful decision hierarchy is:

1. Determine legal, regulatory, contractual, and organizational obligations.
2. Define the data, system, trust boundaries, and business objectives.
3. Identify threats, failure modes, and dependencies.
4. Compare feasible controls and architectures.
5. Estimate residual risk and operational consequences.
6. Consult affected owners, privacy specialists, legal advisers, and technical experts.
7. Obtain approval from the authorized risk owner.
8. Implement, test, monitor, and review the decision.

Decisions should consider availability and recoverability as well as confidentiality. A key-management design that prevents unauthorized disclosure but makes all encrypted backups unrecoverable is not successful. Conversely, a recovery process that creates uncontrolled copies may undermine confidentiality.

9. Illustrative Case: Meridian Health Services

Background

Meridian Health Services is an illustrative regional healthcare provider operating clinics and a patient portal. It stores personal and health information, uses a cloud-hosted electronic-record system, and exchanges data with laboratories and insurers. An internal review finds that the organization has encryption enabled in major systems but lacks a unified cryptographic inventory.

Problem

The review identifies three concerns. First, several certificates are managed manually and one will expire within thirty days. Second, a backup platform uses keys administered by a supplier, but the contract does not clearly define access, deletion, or incident-notification responsibilities. Third, a legacy laboratory integration uses an outdated transport configuration. Management cannot determine whether all high-risk data flows are covered by policy or whether exceptions have been approved.

Analysis

The security team creates an inventory linked to the data-flow map. It identifies systems, data categories, cryptographic mechanisms, owners, suppliers, key locations, certificate dates, and control evidence. The privacy officer confirms that health information requires strong confidentiality and accountability measures. The risk team rates the legacy integration as high because exploitation could expose sensitive data, while the certificate issue is rated high operationally because expiration could disrupt patient services.

The team also discovers that the cloud provider’s independent assurance report covers the platform but not Meridian’s configuration. This distinction becomes a central governance issue.

Approach and Solution

Meridian adopts a cryptographic policy and a technical standard. It assigns information owners and risk owners, centralizes certificate monitoring, and defines renewal thresholds. The laboratory connection is upgraded after compatibility testing, with a documented temporary exception for one endpoint. The exception includes compensating network restrictions, increased monitoring, an owner, and a ninety-day expiry.

For backups, Meridian chooses customer-controlled keys through a managed key service. The contract is amended to define key responsibilities, breach notification, deletion at termination, subcontractor transparency, and evidence rights. Recovery tests are performed to verify that encrypted backups can be restored without bypassing access controls.

The audit committee receives a dashboard showing inventory completeness, expiring certificates, deprecated configurations, open exceptions, recovery-test results, and supplier-assurance status.

Outcome

Meridian reduces undocumented cryptographic dependencies and gains a defensible basis for prioritizing remediation. It does not claim that all risk has been eliminated. Instead, it can demonstrate who is accountable, which controls are operating, what remains unresolved, and when decisions will be revisited.

Learning Points

The case illustrates that encryption alone is not a governance program. Inventory, ownership, contractual clarity, lifecycle management, testing, and evidence are necessary to make cryptographic controls dependable. It also shows why supplier assurance must be matched to the customer’s actual configuration and responsibilities.

10. Challenges, Ethics, and Contemporary Developments

Cryptographic governance faces several limitations. Inventories become stale, ratings can create false precision, frameworks may overlap, and compliance activity can displace real risk reduction. Small organizations may lack specialist staff, while large organizations may suffer from fragmented ownership and excessive exceptions.

Ethically, organizations should avoid using encryption as a justification for collecting excessive data or retaining it indefinitely. Strong controls should protect individuals without concealing unlawful processing, discrimination, or irresponsible data use. Access to keys and lawful investigative processes must be governed transparently and proportionately. Backdoors and deliberately weakened cryptography create systemic risks because they can be discovered or misused by unauthorized parties.

Artificial intelligence can assist with inventory discovery, configuration analysis, anomaly detection, and policy mapping. However, automated recommendations may misclassify data, overlook business context, or reproduce errors in source records. Human review remains necessary for risk acceptance, privacy judgments, legal interpretation, and high-impact decisions. AI systems themselves introduce cryptographic governance questions involving model confidentiality, training data, logging, supplier access, and provenance.

Post-quantum migration is another strategic development. Organizations should identify long-lived sensitive data, cryptographic dependencies, certificates, protocols, and suppliers that may require future replacement. A practical first step is not immediate universal replacement but discovery, prioritization, vendor engagement, testing, and development of migration road maps. Organizations should follow current authoritative standards and transition guidance rather than adopting unreviewed algorithms.

Best-Practice Checklist

A proportionate cryptographic governance program should:

• Maintain an owned and regularly reconciled cryptographic inventory.
• Link cryptographic mechanisms to data classification and business purpose.
• Separate policy, technical standards, procedures, and exceptions.
• Assign accountable owners and authorized risk accepters.
• Manage keys and certificates through their complete lifecycle.
• Use approved, supported algorithms, protocols, libraries, and modules.
• Test backup recovery, revocation, renewal, and compromise response.
• Measure both control coverage and unresolved exposure.
• Treat audits and attestations as evidence, not as automatic proof of effectiveness.
• Include cryptographic responsibilities, evidence, and exit provisions in supplier contracts.
• Review risks after incidents, architecture changes, legal developments, and supplier changes.
• Build cryptographic agility into new systems.
• Retain human accountability for significant security and privacy decisions.

Chapter Summary

Cryptography is an organizational control as well as a technical capability. Effective governance establishes accountability, decision rights, policy requirements, exceptions, and oversight. A cryptographic inventory connects data, systems, keys, certificates, protocols, suppliers, owners, and lifecycle events. It provides the foundation for risk assessment and migration planning, although automated discovery must be supplemented by interviews, reconciliation, and review.

NIST CSF 2.0, NIST control and key-management guidance, ISO/IEC 27001, PCI DSS, privacy laws, and contracts serve different but complementary purposes. Risk assessment helps organizations prioritize threats and weaknesses, while metrics and audits provide evidence about control coverage and operation. Vendor evaluation must examine actual service boundaries, customer responsibilities, key control, data location, evidence scope, incident handling, and exit arrangements.

The strongest decisions are documented, proportionate, risk-informed, and revisited when circumstances change. Compliance is valuable when it improves protection and accountability, but a certificate, dashboard, or audit report cannot substitute for effective technical and organizational practice.

Key Terms

Governance: Direction, accountability, and oversight of organizational activities.

Cryptographic inventory: A structured record of cryptographic assets, mechanisms, dependencies, owners, and lifecycle information.

Information owner: Person accountable for the value, classification, and acceptable handling of information.

Key custodian: Authorized person or service responsible for controlled key-management operations.

Cryptographic agility: Ability to replace cryptographic components with manageable disruption.

Risk owner: Person authorized to decide how a defined risk will be treated.

Residual risk: Risk remaining after safeguards are implemented.

Risk acceptance: Formal decision to tolerate a defined residual risk.

Compensating control: Alternative safeguard used when a required control cannot be implemented directly.

Control framework: Organized set of control objectives or outcomes used to manage risk.

ISMS: Information-security management system required by ISO/IEC 27001.

PCI DSS: Payment Card Industry Data Security Standard.

Audit evidence: Reliable information demonstrating control design or operation.

Leading indicator: Measure that signals future control performance or risk.

Lagging indicator: Measure of an outcome that has already occurred.

Certificate lifecycle: Issuance, validation, renewal, suspension, revocation, and expiration of certificates.

Separation of duties: Division of responsibilities to reduce error, misuse, or unauthorized action.

Supplier assurance: Evidence that a third party manages agreed security and privacy responsibilities.

Exception: Authorized temporary departure from a policy or standard.

Cryptographic boundary: Defined point separating cryptographic processing, trust, or responsibility.

Review Questions

Short Answer Questions

1. Why is a cryptographic inventory more comprehensive than a list of encryption keys?
2. Distinguish governance from cryptographic operations.
3. What information should be included in a cryptographic exception record?
4. Why does a compliance certificate not automatically prove effective security?
5. Name two important questions to ask a cloud provider about key management.

Long Answer Questions

1. Explain how a cryptographic policy, technical standard, procedure, and exception process should work together.
2. Compare the roles of NIST CSF 2.0, ISO/IEC 27001, PCI DSS, and privacy law in cryptographic governance.
3. Describe the lifecycle of a cryptographic key and identify governance risks at each stage.
4. Explain how metrics and audit evidence can support, but also potentially distort, security decision-making.
5. Discuss why supplier cryptographic responsibilities should be addressed in contracts as well as technical assessments.

Analytical / Application Questions

1. An organization discovers 8% of its certificates are expired or within seven days of expiration, including certificates on critical services. Propose an immediate response and a longer-term governance improvement.
2. A supplier offers encryption at rest but retains exclusive control of the keys and provides only a general security certificate. Analyze the questions the organization should ask before approval.
3. A legacy system cannot support the organization’s approved transport protocol for six months. Design a risk-based exception, including compensating controls, ownership, evidence, expiry, and review conditions.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a cryptographic inventory?

A. To replace all security policies

B. To record cryptographic assets, mechanisms, dependencies, owners, and lifecycle information

C. To guarantee that no security incident can occur

D. To eliminate the need for risk assessment

Correct Answer: B. To record cryptographic assets, mechanisms, dependencies, owners, and lifecycle information

Question 2

Which role normally has authority to accept a defined residual business risk?

A. Any system administrator

B. The certificate authority

C. The authorized risk owner

D. An external software vendor automatically

Correct Answer: C. The authorized risk owner

Question 3

Which statement best describes the relationship between ISO/IEC 27001 and Annex A controls?

A. Annex A eliminates the need for organizational risk assessment

B. ISO/IEC 27001 requires an information-security management system, while Annex A provides supporting control references

C. Annex A applies only to payment-card environments

D. ISO/IEC 27001 is a cryptographic algorithm standard

Correct Answer: B. ISO/IEC 27001 requires an information-security management system, while Annex A provides supporting control references

Question 4

If 940 of 1,000 certificates meet policy requirements, what is the certificate compliance rate?

A. 9.4%

B. 40%

C. 94%

D. 106%

Correct Answer: C. 94%

Question 5

Which action is an example of risk avoidance?

A. Adding monitoring to an existing service

B. Buying cyber insurance

C. Formally accepting the residual risk

D. Stopping the risky processing entirely

Correct Answer: D. Stopping the risky processing entirely

Question 6

Why should a supplier assurance report be checked for scope and complementary customer controls?

A. Because every report automatically covers every customer configuration

B. Because the report may not cover the specific service or customer responsibilities being relied upon

C. Because supplier reports are never useful

D. Because technical controls cannot be audited

Correct Answer: B. Because the report may not cover the specific service or customer responsibilities being relied upon

Question 7

Which is a leading indicator for cryptographic governance?

A. Number of confirmed data breaches last year

B. Number of failed recovery tests already completed

C. Percentage of critical assets with an assigned cryptographic owner

D. Total cost of a past incident

Correct Answer: C. Percentage of critical assets with an assigned cryptographic owner

Question 8

What is the main purpose of an exception expiry date?

A. To make an exception permanent

B. To ensure the exception is reviewed and does not continue indefinitely without reconsideration

C. To remove the need for compensating controls

D. To transfer all accountability to an auditor

Correct Answer: B. To ensure the exception is reviewed and does not continue indefinitely without reconsideration

Question 9

Which statement about encryption and PCI DSS scope is most accurate?

A. Encryption automatically removes all systems from PCI DSS scope

B. Encryption is irrelevant to payment-card security

C. Encryption may reduce exposure, but scope must still be determined from the environment and applicable requirements

D. PCI DSS applies only to encryption keys

Correct Answer: C. Encryption may reduce exposure, but scope must still be determined from the environment and applicable requirements

Question 10

What does cryptographic agility mean?

A. Using as many algorithms as possible in every system

B. The ability to replace cryptographic components with manageable disruption

C. Allowing users to bypass key management

D. Avoiding all cryptographic standards

Correct Answer: B. The ability to replace cryptographic components with manageable disruption