Enterprise Governance, Strategy and Emerging Developments

Introduction

Data security and access control are no longer confined to technical departments. They are enterprise-governance concerns involving directors, executives, regulators, employees, suppliers, customers and affected communities. A technically strong identity system can still fail if business ownership is unclear, policies conflict, risk appetite is undefined, or suppliers are not monitored. Conversely, an excellent policy may provide little protection if it is not translated into architecture, operating procedures, measurable controls and accountable decisions.

This chapter examines how organisations build security roadmaps, assess capability maturity, select meaningful metrics, justify investment, govern third parties and respond to emerging technologies. Particular attention is given to confidential computing, post-quantum cryptography, decentralised identity and artificial-intelligence-driven access control. The central argument is that enterprise security is a socio-technical capability: technology, people, processes, law and institutional accountability must operate together.

Learning Objectives

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

1. Construct a risk-informed data-security and access-control strategy.
2. Translate strategic objectives into a phased security roadmap.
3. Design maturity assessments, metrics and executive dashboards.
4. Prepare a defensible business case for security investment.
5. Establish third-party assurance and evidence-management programmes.
6. Analyse policy, compliance, ethical and accountability implications.
7. Evaluate confidential computing, post-quantum cryptography, decentralised identity and AI-enabled access control.
8. Critically assess the limitations and risks of emerging security technologies.

1. Governance as the Foundation of Security Strategy

Governance is the system by which an organisation is directed, controlled and held accountable. Security governance determines who may make security decisions, what evidence is required, how conflicting objectives are resolved and how performance is reviewed. It differs from management: governance sets direction and accountability, whereas management plans and operates controls.

A useful governance model separates four responsibilities:

A board should not approve individual permissions. It should approve risk appetite, strategic priorities, material exceptions and reporting thresholds. Operational decisions belong to appropriately authorised managers, supported by documented policy and segregation of duties.

1.1 Three lines of responsibility

A practical model consists of:

• First line: business and technology teams that own risks and operate controls.
• Second line: security, privacy, legal, compliance and risk functions that set requirements, advise and monitor.
• Third line: internal audit or another independent assurance function that evaluates governance and control effectiveness.

External auditors, regulators and customers provide additional assurance but do not replace internal accountability. A common failure is to treat the security office as the sole owner of every risk. Security can define standards and operate shared capabilities, but the business owner normally remains responsible for the data, process and consequences associated with access.

1.2 Policy hierarchy

A coherent policy hierarchy prevents vague principles from being mistaken for operating instructions:

1. Principles: broad commitments such as least privilege and accountability.
2. Policies: mandatory organisational rules.
3. Standards: measurable technical or procedural requirements.
4. Procedures: detailed steps for performing activities.
5. Guidelines: recommended practices where context permits discretion.
6. Records and evidence: approvals, logs, reviews, test results and exceptions.

Policies should identify scope, ownership, mandatory requirements, exceptions, enforcement, review frequency and links to relevant laws or contracts. A policy that cannot be tested or assigned to an owner is usually an aspiration rather than a control.

2. From Enterprise Objectives to a Security Roadmap

A security roadmap is a time-sequenced plan connecting business outcomes to capabilities, dependencies, resources and measurable results. It should not be merely a list of security products. The starting point is the organisation’s mission and information-risk profile.

2.1 Strategic alignment

A strategy can be expressed as a chain:

Business objective → information asset → threat and vulnerability → potential impact → control capability → measurable outcome.

For example, a bank’s objective of rapid digital lending depends on customer identity data, credit models and application interfaces. Threats include account takeover, unauthorised model access and supplier compromise. The resulting roadmap may prioritise phishing-resistant authentication, privileged-access management, API authorisation, data classification and supplier assurance.

2.2 Risk-based prioritisation

Risk analysis should consider at least confidentiality, integrity, availability, privacy, safety, legal exposure and business continuity. A simple qualitative matrix is useful for initial prioritisation, but it should not be confused with a precise probability calculation. Where reliable data exist, an annualised loss model can support economic comparison:

Here, ALE is annualised loss expectancy, SLE is single-loss expectancy in monetary units, and ARO is annual rate of occurrence. The model assumes that loss events can be reasonably estimated and that the annual rate is meaningful for the decision period. It is inappropriate to present uncertain estimates as exact forecasts. Control costs, implementation risk, secondary effects and risk reduction must also be considered.

A control’s expected value may be approximated as:

where ALE_before and ALE_after are estimated annual losses before and after the control, and C_control is the relevant annualised cost. The expression is a decision aid, not a complete valuation. It may omit regulatory penalties, reputational effects, safety consequences, interdependencies and uncertainty.

2.3 Roadmap horizons

A practical roadmap usually combines three horizons:

• Stabilise: inventory identities and data, remove obsolete accounts, establish logging, remediate critical vulnerabilities and define ownership.
• Standardise: implement central identity governance, privileged-access management, data classification, access certification, secure development and supplier controls.
• Optimise: introduce adaptive access, automation, confidential-computing use cases, cryptographic agility and continuous assurance.

Dependencies matter. For example, automated access certification is unreliable if applications lack authoritative ownership and entitlement metadata. Zero-trust policy enforcement is difficult when identity proofing, device signals and asset inventories are incomplete.

2.4 Roadmap governance

Each initiative should have an accountable executive, business owner, technical owner, risk statement, baseline, target state, dependencies, budget, delivery milestones and outcome measures. Architecture review boards should examine whether local projects create duplicated identity stores, incompatible policy engines or excessive administrative privilege.

A roadmap should be revisited after major incidents, mergers, regulatory changes, cloud migration, business-model changes and material technology changes. It is a living control instrument rather than a fixed project plan.

3. Maturity Assessment and Capability Development

Maturity models help an organisation compare current practices with a desired state. They are useful for prioritisation and communication, but they do not prove that controls are effective. A mature process can still be badly designed, and a low-maturity organisation may possess one highly effective control.

A five-level model is often practical:

Assessment domains may include governance, identity lifecycle, authentication, authorisation, privileged access, data protection, logging, incident response, third-party assurance and workforce capability.

A defensible assessment uses multiple evidence types: interviews, policy review, configuration inspection, sampled transactions, access-review records, incident data and independent testing. Maturity scoring should record confidence and evidence quality. A score of “defined” based only on an approved policy is weaker than the same score supported by operating evidence.

A useful assessment report distinguishes:

• Design effectiveness: whether a control, if operated as designed, addresses the stated risk.
• Operating effectiveness: whether it operated consistently during the assessment period.
• Coverage: which applications, identities, data sets and suppliers are included.
• Residual risk: what remains after controls and whether it is accepted by the correct authority.

4. Metrics, Measurement and Executive Reporting

Metrics should support decisions, not merely demonstrate activity. Counting security tools, policies or training completions can create an illusion of progress. Effective measures connect control operation with risk reduction and business resilience.

4.1 Metric categories

Important metrics require a defined numerator, denominator, scope, period, data source, owner and target. For example:

The metric is meaningful only if “leaver,” “revoked,” service-level agreement and measurement period are consistently defined. It should be supplemented by sampling because a technically disabled account may retain access through shared credentials, tokens or supplier pathways.

A dashboard should show trends, thresholds, exceptions, confidence and management actions. It should avoid mixing incompatible populations. A 98% compliance rate may conceal the fact that the remaining 2% are administrators of the most sensitive system.

4.2 Metric failure modes

Metrics can be gamed. Teams may close tickets without removing risk, classify incidents narrowly, or exclude difficult applications from the denominator. Excessive focus on mean time to close can encourage premature closure. Balanced reporting combines leading indicators, such as overdue access reviews, with lagging indicators, such as confirmed unauthorised access.

5. Building the Business Case

Security investment competes with revenue, operational efficiency and other risk-reduction programmes. A persuasive business case therefore combines quantitative analysis with strategic, legal and ethical reasoning.

A business case should contain:

1. The business problem and affected objectives.
2. Threats, vulnerabilities and current control weaknesses.
3. Options, including doing nothing and non-technical alternatives.
4. Costs: acquisition, implementation, integration, training, operations and exit.
5. Benefits: loss reduction, productivity, compliance, resilience and customer trust.
6. Dependencies, assumptions and delivery risks.
7. Residual risk and proposed acceptance authority.
8. Measures for verifying benefits after implementation.

For multi-year investments, discounted cash-flow analysis may be used:

Here, CF_t is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. Cash flows must use consistent time units and should be stated either in nominal terms with a nominal discount rate or in real terms with a real discount rate. Security benefits are often uncertain; scenario analysis is more honest than a single precise forecast.

A qualitative benefit may be decisive. For example, a control may be required to meet a contractual condition or protect safety-critical data even when expected financial loss is difficult to estimate. Such reasoning should be documented rather than hidden inside an invented monetary value.

6. Third-Party Assurance and Supply-Chain Governance

An organisation’s security boundary includes suppliers, cloud providers, managed-service operators, software dependencies, contractors and business partners. Third-party assurance is the structured process of selecting, assessing, contracting with, monitoring and—when necessary—remediating or exiting suppliers.

6.1 Risk-tiering

Not every supplier requires the same scrutiny. Tiering should consider data sensitivity, privileged connectivity, operational criticality, substitutability, geographic and legal exposure, concentration risk and fourth-party dependence.

6.2 Assurance evidence

Evidence may include independent control reports, certifications, penetration-test summaries, vulnerability-management information, incident-notification performance, recovery-test results, subcontractor lists and secure-development evidence. A certificate is not a universal guarantee: its scope, period, exclusions and complementary customer controls must be examined.

Contracts should address purpose limitation, access control, encryption, logging, personnel screening where lawful, incident notification, vulnerability remediation, audit rights, data location, subcontracting, retention and secure deletion, business continuity and termination assistance. These terms must be operationally feasible; an audit right without a process for exercising it has limited value.

6.3 Continuous assurance

Assurance should continue after onboarding. Monitor changes in ownership, service architecture, incidents, critical vulnerabilities, attestations, access paths and concentration exposure. Supplier offboarding must revoke credentials, retrieve or delete data, disable integrations and preserve evidence.

7. Policy, Compliance and Ethical Decision-Making

Compliance establishes a floor, not necessarily a secure target. Laws and regulations differ by jurisdiction and sector, but common themes include lawful processing, purpose limitation, data minimisation, accountability, appropriate security, individual rights, breach response and records of decision-making. Organisations must map obligations to controls rather than treating a regulation as a checklist.

Policy decisions frequently involve conflict. Stronger authentication may reduce fraud but create accessibility barriers. Extensive monitoring may improve detection but intrude on worker privacy. Data localisation may reduce legal uncertainty but increase cost and operational complexity. Ethical governance asks whether a measure is necessary, proportionate, transparent, contestable and distributed fairly.

Access decisions should be explainable to affected users and reviewable by an authorised human where consequences are significant. Emergency access should be time-limited, logged, justified and retrospectively reviewed. Exceptions require an owner, rationale, compensating controls, expiry date and explicit acceptance of residual risk.

8. Emerging Development I: Confidential Computing

Confidential computing aims to protect data while it is being processed, in addition to protection at rest and in transit. It commonly uses a hardware-backed trusted execution environment (TEE), which isolates selected code and data from other software—including, in some threat models, privileged infrastructure administrators.

A typical confidential-computing workflow includes:

1. Code and configuration are measured.
2. A remote party verifies an attestation report.
3. Sensitive data are released only if the expected measurement and policy conditions are satisfied.
4. Processing occurs inside an isolated environment.
5. Outputs are restricted and logged.

Confidential computing can support privacy-preserving analytics, multi-party collaboration, protection of encryption keys and stronger cloud tenant isolation. It does not automatically protect data from malicious code running inside the enclave, compromised inputs, side-channel attacks, denial of service, insecure outputs or flawed attestation policy. Performance, debugging, key management and vendor dependence are significant concerns.

A sound adoption decision identifies the threat model. If the concern is an untrusted cloud operator, a TEE may help. If the application itself is malicious or the output reveals sensitive information, additional controls are required. Confidential computing should complement, not replace, application security, data minimisation and conventional access governance.

9. Emerging Development II: Post-Quantum Cryptography

Large-scale fault-tolerant quantum computers could threaten widely deployed public-key systems based on integer factorisation or discrete logarithms. Symmetric cryptography is generally affected differently; increasing key sizes can provide additional security margin, subject to the selected security level and implementation.

Post-quantum cryptography (PQC) uses algorithms designed to resist known quantum and classical attacks. Migration is not simply an algorithm replacement. Organisations must inventory cryptographic use, identify long-lived confidential data, locate embedded certificates and protocols, assess performance, update procurement requirements and preserve cryptographic agility.

The “harvest now, decrypt later” concern is important for data requiring confidentiality over many years. A roadmap may therefore prioritise long-lived sensitive information and systems with long procurement or hardware replacement cycles. Hybrid deployments can combine classical and post-quantum mechanisms during transition, but they increase implementation and interoperability complexity.

Important governance questions include algorithm standardisation status, validation requirements, library maturity, certificate and protocol support, fallback behaviour, key management and supplier commitments. PQC does not solve weak authentication, poor authorisation, stolen credentials or insecure endpoints.

10. Emerging Development III: Decentralised Identity

Decentralised identity seeks to give individuals or organisations greater control over digital identifiers and credentials. Common concepts include decentralised identifiers, verifiable credentials, issuers, holders and verifiers. A verifier may validate a credential’s issuer, integrity, status and claims without contacting the issuer for every transaction.

Potential advantages include reduced repetitive disclosure, portability across services and support for selective disclosure. Risks include key loss, recovery, revocation, issuer concentration, unreliable claims, correlation across transactions, accessibility and unclear legal responsibility. “Decentralised” does not mean trustless: ecosystems still need governance, trusted issuers, dispute mechanisms, status infrastructure and standards.

A responsible design asks:

• What claim is necessary, and can it be minimised?
• How is the issuer trusted and audited?
• How can a credential be revoked or suspended?
• What happens when a holder loses a key?
• Can users obtain service without disproportionate technical skill?
• How are privacy, fraud and accountability balanced?

11. Emerging Development IV: AI-Driven Access Control

Artificial intelligence can assist identity-risk scoring, anomaly detection, entitlement analysis, role mining, access-request triage and detection of unusual privilege use. It can identify patterns that rules alone might miss, but it should not be treated as an autonomous source of authority.

A robust architecture separates:

• Policy authority: explicit rules, legal requirements and approved business constraints.
• Evidence: identity, device, location, behaviour, resource sensitivity and transaction context.
• Inference: a model-generated risk signal or recommendation.
• Enforcement: a bounded policy decision with fail-safe behaviour and logging.
• Review: human oversight, appeal, testing and model monitoring.

AI introduces risks of bias, data leakage, adversarial manipulation, concept drift, opaque decisions, automation bias and feedback loops. Training data may encode historical over- or under-privileging. A model that learns from past approvals can reproduce poor governance.

High-impact decisions should use human review, minimum necessary data, explainable reasons, confidence thresholds and an appeal path. Models require version control, validation, performance monitoring, access restrictions, red-team testing and retirement criteria. A practical principle is AI-assisted, policy-constrained access, not unrestricted AI-controlled access.

12. Integrated Applied Case: Northstar Health Network

Background

Northstar Health Network, an illustrative regional healthcare organisation, operates hospitals, clinics, laboratories and a cloud-based patient portal. It shares selected services with an external laboratory and a managed electronic-health-record provider. An internal review found orphaned accounts, inconsistent privileged access, incomplete supplier evidence and excessive dependence on annual access reviews.

Problem

The board wanted a three-year security plan. It required improved patient-data protection without disrupting emergency treatment. The organisation had limited funds and could not replace all legacy applications.

Analysis

The security team mapped critical processes and identified patient safety, clinical availability, confidentiality and regulatory exposure as primary concerns. It discovered that a large proportion of legacy applications lacked automated joiner–mover–leaver integration. The highest-risk pathways were privileged administration, emergency accounts, laboratory interfaces and remote supplier access.

The team rejected a simple “buy zero trust” proposal because identity data, asset ownership and application authorisation were immature. It also rejected immediate deployment of AI-based behavioural blocking because false positives could delay clinical work.

Approach and solution

The roadmap was staged:

• First six months: assign data and application owners; remove dormant accounts; enforce phishing-resistant authentication for administrators; create emergency-access procedures; inventory supplier connections; centralise critical logs.
• Months 7–18: deploy privileged-access management; integrate authoritative HR data; implement time-bound supplier access; classify patient data; establish quarterly high-risk access certification; require evidence-based supplier tiering.
• Months 19–36: modernise application authorisation; introduce adaptive step-up authentication for selected workflows; test confidential computing for approved research analytics; begin cryptographic-agility and PQC inventory; pilot AI anomaly detection in advisory mode.

The board dashboard reported leaver-revocation rate, privileged-session coverage, overdue high-risk reviews, supplier evidence completeness, emergency-access review time and clinically significant authentication disruptions. Each metric had an owner and a documented scope.

Outcome

After the first phase, Northstar reduced dormant privileged accounts and improved visibility of supplier access. The organisation did not claim that risk had been eliminated. Instead, it documented residual legacy risk, funded compensating controls and established expiry dates for exceptions. The pilot AI system generated investigation leads but could not deny clinical access automatically.

Learning points

The case demonstrates that governance precedes advanced technology. Sequencing matters: authoritative ownership and reliable identity data are prerequisites for automation. Critical services require safety-aware exceptions, and metrics must measure meaningful coverage rather than activity alone. Emerging technologies should be tested against a defined threat model and bounded by policy.

13. Limitations and Research Directions

Security maturity scores are subjective and may encourage competition over ratings rather than risk reduction. Quantitative loss models are sensitive to uncertain assumptions. Compliance evidence can become performative if organisations optimise for audit rather than protection. Third-party assurance is limited by scope, timing and supplier transparency. Emerging technologies often have immature standards and concentrated vendor ecosystems.

Research and professional practice should therefore examine causal evidence: which controls reduce incidents in particular contexts, how human behaviour changes under different authentication designs, how AI access systems perform across demographic groups, and how cryptographic migration affects long-lived infrastructure. Organisations should preserve experimental evidence, publish assumptions internally and treat uncertainty as a governance issue rather than hiding it.

Best-Practice Checklist

• Define business, data and risk ownership before selecting tools.
• Maintain authoritative inventories of identities, applications, data and suppliers.
• Use least privilege, separation of duties and time-bounded elevation.
• Make exceptions explicit, compensating and expiring.
• Measure coverage, timeliness, quality and outcomes together.
• Test control operation rather than relying on policy existence.
• Tier suppliers and monitor them throughout the relationship.
• Design for accessibility, privacy, explainability and contestability.
• Build cryptographic agility before urgent PQC migration is required.
• Treat confidential computing, decentralised identity and AI as risk-dependent capabilities, not universal solutions.
• Review strategy after incidents, major changes and evidence of control failure.

Chapter Summary

Enterprise data security is a governance responsibility supported by management, technology and independent assurance. Effective strategy begins with business objectives, information assets, threats, impacts and accountable ownership. A roadmap should stabilise foundations, standardise capabilities and then optimise through automation and adaptive controls.

Maturity assessments are most useful when supported by evidence and separated into design effectiveness, operating effectiveness, coverage and residual risk. Metrics must have defined scope and should connect activity to outcomes. Business cases should combine carefully qualified quantitative analysis with legal, strategic, resilience and ethical considerations.

Third-party assurance requires risk-tiering, contractual controls, evidence review, continuous monitoring and secure offboarding. Compliance is a baseline; ethical governance additionally considers necessity, proportionality, accessibility, transparency and appeal. Confidential computing can protect data in use but depends on trustworthy code and attestation. Post-quantum cryptography requires inventory and cryptographic agility. Decentralised identity may improve portability and selective disclosure but needs ecosystem governance. AI can assist access decisions, but policy authority, human oversight, auditability and fail-safe behaviour remain essential.

Key Terms

Governance: Direction, accountability and oversight of organisational activity.

Risk appetite: The amount and type of risk an organisation is willing to accept.

Risk owner: The person accountable for managing a defined risk.

Control owner: The person responsible for designing and operating a control.

Security roadmap: A sequenced plan for achieving target security capabilities.

Maturity model: A framework for assessing capability development across defined levels.

Design effectiveness: Whether a control is appropriately designed for its intended risk.

Operating effectiveness: Whether a control operates consistently as required.

Security metric: A defined measure used to evaluate security activity or outcomes.

Annualised loss expectancy: Estimated annual loss calculated from single-loss expectancy and annual rate of occurrence.

Third-party assurance: Evaluation of a supplier’s security controls and evidence.

Residual risk: Risk remaining after controls are applied.

Confidential computing: Protection of data during processing using a trusted execution environment or related mechanism.

Remote attestation: Evidence used to verify the state or measurement of a computing environment.

Post-quantum cryptography: Cryptography designed to resist relevant classical and quantum attacks.

Cryptographic agility: The ability to change cryptographic algorithms and parameters safely.

Decentralised identity: An identity approach that supports portable, user-controlled identifiers or credentials.

Verifiable credential: A digitally signed claim whose issuer and integrity can be checked.

Adaptive access control: Access decisions that consider changing context and risk signals.

Automation bias: The tendency to over-trust an automated recommendation or decision.

Review Questions

Short Answer Questions

1. Distinguish governance from security management.
2. What is the difference between design effectiveness and operating effectiveness?
3. Why should third-party suppliers be risk-tiered?
4. State two limitations of confidential computing.
5. What is cryptographic agility, and why is it important for PQC migration?

Long Answer Questions

1. Explain how an organisation can translate business objectives into a security roadmap.
2. Discuss the design of an executive security dashboard, including useful and misleading metrics.
3. Evaluate the role of contracts, independent evidence and continuous monitoring in third-party assurance.
4. Compare confidential computing, decentralised identity and AI-driven access control in terms of benefits and risks.
5. Explain why compliance should be treated as a baseline rather than the complete security strategy.

Analytical / Application Questions

1. A university discovers that 15% of privileged accounts have no current owner. Design a 12-month remediation plan, including governance, controls, metrics and exception handling.
2. A hospital wants to use an AI model to block unusual access to patient records. Analyse the safety, privacy, bias and accountability risks, and propose a policy-constrained deployment architecture.
3. A cloud supplier provides a current security certification but excludes the organisation’s most sensitive service from its scope. Decide what additional assurance is required and whether the supplier should remain classified as critical.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily a governance responsibility?

A. Approving the board’s risk appetite and material exceptions

B. Resetting an employee password

C. Patching an individual workstation

D. Investigating one failed login

Correct Answer: A. Approving the board’s risk appetite and material exceptions

Question 2

In the expression ALE = SLE × ARO, what does ARO represent?

A. Annual recovery objective

B. Annual rate of occurrence

C. Authorised risk operation

D. Aggregated residual exposure

Correct Answer: B. Annual rate of occurrence

Question 3

Which evidence most directly supports operating effectiveness?

A. A policy approved by the board

B. A product brochure

C. Sampled access reviews showing completed approvals during the assessment period

D. A proposed future roadmap

Correct Answer: C. Sampled access reviews showing completed approvals during the assessment period

Question 4

Why is risk-tiering important in third-party assurance?

A. It allows every supplier to avoid security requirements

B. It allocates assurance effort according to exposure and criticality

C. It eliminates the need for contracts

D. It guarantees that a supplier cannot be breached

Correct Answer: B. It allocates assurance effort according to exposure and criticality

Question 5

What is a principal purpose of confidential computing?

A. Protecting data while it is being processed

B. Replacing all identity governance

C. Guaranteeing that application code is trustworthy

D. Eliminating denial-of-service attacks

Correct Answer: A. Protecting data while it is being processed

Question 6

What is the main strategic reason to begin post-quantum preparation early?

A. All current symmetric encryption has already failed

B. Long-lived data and complex infrastructure may require lengthy migration

C. PQC removes the need for key management

D. PQC automatically fixes stolen credentials

Correct Answer: B. Long-lived data and complex infrastructure may require lengthy migration

Question 7

Which is a recognised governance challenge for decentralised identity?

A. Credentials never need revocation

B. Key loss and recovery must be addressed

C. No issuer is required

D. Selective disclosure makes privacy impossible

Correct Answer: B. Key loss and recovery must be addressed

Question 8

What is the most appropriate role for an AI model in high-impact access control?

A. Unrestricted autonomous authority

B. A policy-constrained recommendation or risk signal with oversight

C. A replacement for all audit logs

D. A mechanism that bypasses legal requirements

Correct Answer: B. A policy-constrained recommendation or risk signal with oversight

Question 9

Which metric definition is most defensible?

A. Security quality, measured regularly

B. Good access management, according to staff opinion

C. Leavers revoked within the SLA divided by total leavers, over a stated period

D. Number of security tools purchased

Correct Answer: C. Leavers revoked within the SLA divided by total leavers, over a stated period

Question 10

Why should a security exception have an expiry date?

A. To ensure accepted residual risk is periodically reconsidered

B. To make the exception permanent

C. To prevent anyone from recording the decision

D. To eliminate the need for compensating controls

Correct Answer: A. To ensure accepted residual risk is periodically reconsidered