Governance, Professional Practice and Emerging Security

Introduction

Cybersecurity is not only a technical activity. Firewalls, encryption, identity systems and monitoring tools operate within organisational decisions about authority, risk, law, accountability and acceptable conduct. Governance provides the direction and oversight through which security objectives are established, implemented and evaluated. Professional practice converts that direction into repeatable procedures, competent decisions and defensible evidence.

This chapter examines governance and professional practice in network, internet and cloud security. It explains how policies, standards, risk treatment, audits and evidence support assurance; compares the NIST Cybersecurity Framework (CSF), CIS Controls and ISO/IEC 27001; and considers privacy, law, ethics and third-party risk. It concludes by evaluating SASE, security service edge (SSE), AI-assisted defence, adversarial AI, post-quantum cryptography and risks arising from digital transformation.

Learning Objectives

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

1. Explain the relationship between governance, risk management, policy and operational security.
2. Apply NIST CSF, CIS Controls and ISO/IEC 27001 to practical security problems.
3. Select risk treatments and assemble reliable audit evidence.
4. Assess privacy, legal, ethical and third-party security obligations.
5. Describe the security implications of SASE, SSE, artificial intelligence and post-quantum cryptography.
6. Recommend proportionate controls for emerging digital-transformation risks.

1. Governance as a Security Function

Governance is the system by which an organisation is directed, controlled and held accountable. Security governance defines who may make security decisions, what outcomes are required, how risk is accepted and how performance is reported. It is distinct from management: governance sets direction and oversight, while management plans and operates activities within that direction.

A useful governance chain is:

Objectives → risk appetite → policies → standards and procedures → controls → evidence → assurance → improvement

For example, an organisation may establish an objective to protect customer information. Its risk appetite may state that unauthorised disclosure of regulated data is intolerable. A policy can require classification and access control; a standard can specify multifactor authentication and encryption; procedures describe implementation; logs and test records provide evidence; and audits determine whether controls operate effectively.

Good governance has several characteristics:

• Accountability: named owners are responsible for systems, risks and controls.
• Authority: decision-makers have sufficient power and resources.
• Proportionality: controls reflect the likelihood and impact of harm.
• Transparency: decisions and exceptions are documented.
• Independence: assurance activities are sufficiently separate from implementation.
• Continuous improvement: lessons from incidents, audits and changes are incorporated.

Security governance should be integrated with enterprise governance rather than treated as an isolated information-technology concern. Boards and senior managers may not configure systems, but they decide priorities, funding, risk tolerance and accountability. Technical professionals therefore need to communicate in business terms: service availability, legal exposure, safety, revenue, reputation and customer trust.

Policy, Standard, Procedure and Guideline

These terms are related but not interchangeable.

A policy that cannot be implemented, measured or assigned to an owner is unlikely to produce effective security. Policies should have a scope, owner, approval authority, review date, exception process and relationship to legal or contractual requirements.

2. Risk Management and Treatment

Risk management is the structured process of identifying uncertainty that could affect objectives, analysing its likelihood and consequences, selecting responses and monitoring change. In security, a risk scenario normally connects an asset or service, a threat, a vulnerability or exposure, and a harmful consequence.

A simple qualitative model is:

Likelihood and impact may be scored on ordinal scales such as 1–5. These scores are not precise probabilities; they support consistent comparison. Multiplying ordinal values can be useful operationally, but the result should not be represented as a measured monetary loss unless the scales and assumptions justify that interpretation.

For quantitative analysis, expected annual loss may be estimated as:

where ALE is annualised loss expectancy, SLE is single-loss expectancy in currency units, and ARO is annual rate of occurrence. This model assumes that a loss event can be reasonably characterised and that the estimated frequency is meaningful. It is unsuitable when data are extremely limited or consequences are non-financial, such as loss of life or fundamental rights.

Risk treatment generally uses four choices:

1. Avoid: discontinue the activity creating unacceptable exposure.
2. Mitigate or modify: reduce likelihood or impact through controls.
3. Transfer or share: allocate some financial or operational consequences to another party, such as through insurance or a contract. Transfer does not eliminate accountability.
4. Accept: knowingly retain the risk within approved tolerance.

Risk acceptance must be explicit, time-bounded where appropriate and approved by an owner with authority. A technical team should not silently accept a risk on behalf of senior management.

Worked Example: Selecting a Treatment

An online service has an estimated single-loss expectancy of £80,000 and an annual rate of occurrence of 0.25. Its estimated annual loss is therefore:

ALE = £80,000 × 0.25 = £20,000

A proposed control costs £7,000 per year and is expected to reduce the annual rate to 0.08. The residual annual loss is:

£80,000 × 0.08 = £6,400

The estimated reduction is £13,600, which exceeds the annual control cost by £6,600. This supports mitigation on economic grounds, assuming the estimates are credible and no important non-financial effects have been omitted. The analysis does not prove that deployment is mandatory: legal duties, safety, privacy and customer expectations may justify the control even when financial calculations do not.

3. Security Frameworks and Their Uses

Frameworks provide common language and structured coverage. They are not substitutes for risk assessment or professional judgement.

NIST Cybersecurity Framework

The NIST CSF 2.0 organises cybersecurity outcomes into six functions:

• Govern: establish and monitor cybersecurity strategy, policy, roles, supply-chain expectations and oversight.
• Identify: understand assets, dependencies, risks and improvement opportunities.
• Protect: implement safeguards for identity, access, data, platforms, awareness and resilience.
• Detect: discover and analyse anomalous activity and possible incidents.
• Respond: manage incidents, communicate, contain and mitigate.
• Recover: restore affected assets and improve recovery practices.

The CSF is outcome-oriented. An organisation may use it to describe a current profile, define a target profile, analyse gaps and prioritise improvement. Its flexibility supports organisations of different sizes, but flexibility can also produce vague implementation unless outcomes are mapped to owners, measures and evidence.

CIS Critical Security Controls

The CIS Controls are prioritised safeguards intended to reduce common attack paths. Examples include asset inventory, software inventory, data protection, secure configuration, account management, vulnerability management, audit-log management, email and browser protections, malware defences, recovery processes and service-provider management.

The Controls are practical and implementation-focused. They are particularly useful for building a baseline in a small or medium organisation. Their limitation is that a checklist can encourage superficial compliance. An organisation may possess a vulnerability scanner but still fail to remediate critical exposures; therefore effectiveness, not tool ownership, must be assessed.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for an information security management system (ISMS). An ISMS is a management system for establishing, implementing, maintaining and continually improving information security. It includes organisational context, leadership, planning, support, operation, performance evaluation and improvement. Risk assessment and treatment determine applicable controls, commonly documented through a statement of applicability.

Certification is performed by an independent certification body, not by the organisation itself. Certification provides evidence that an ISMS was assessed against specified requirements at a point in time; it does not guarantee that no breach will occur. The organisation remains responsible for the scope, accuracy of information supplied to auditors and continuing operation of the system.

Combining Frameworks

Frameworks can be layered rather than treated as competitors:

A sensible implementation begins with business services and risks, maps them to desired outcomes, selects controls, assigns owners and defines evidence. Framework mapping should reduce duplication, not create multiple uncoordinated compliance programmes.

4. Audit, Assurance and Evidence

An audit is a systematic evaluation against defined criteria. Assurance is broader: it gives stakeholders confidence that governance, risk management and controls are appropriate and operating as intended. Internal audit, external audit, penetration testing, management review and independent assessments may all contribute evidence, but they answer different questions.

Strong audit evidence is:

• Relevant: directly supports the control assertion.
• Reliable: comes from a trustworthy source and has not been altered.
• Sufficient: covers the required population or sample.
• Timely: relates to the period under review.
• Traceable: can be linked to an owner, system and requirement.
• Reproducible: another reviewer can understand how it was obtained.

Examples include approved policies, access-review records, configuration exports, vulnerability-remediation tickets, training records, incident timelines, backup restoration tests and supplier assessment results. A screenshot without date, system identity or context is weak evidence. A log export should have an explanation of the collection method, time zone, retention and integrity protections.

Auditors commonly distinguish design effectiveness from operating effectiveness. A control is design-effective when it is capable of addressing the stated risk. It is operating-effective when it actually operated consistently during the relevant period. A documented quarterly review that was never performed is not operating-effective.

Evidence collection must itself respect privacy and security. Audit data may contain personal information, credentials, confidential business information or attack details. Access should be restricted, retention should be defined and evidence should be securely destroyed when no longer needed.

5. Privacy, Law and Ethics

Privacy concerns how information about identifiable people is collected, used, disclosed, retained and protected. Security is an important privacy safeguard, but privacy also concerns purpose, fairness, transparency, necessity and individual rights. A system can be secure against outsiders while still violating privacy through excessive monitoring or unjustified data collection.

Legal obligations vary by jurisdiction and sector. Common areas include data-protection legislation, breach notification, electronic communications law, computer misuse offences, intellectual property, records obligations, employment law, consumer protection, critical-infrastructure regulation and contractual duties. Organisations should obtain jurisdiction-specific legal advice rather than assuming that one country’s rules apply everywhere.

Important privacy-by-design practices include:

• collect only data needed for a defined purpose;
• document lawful authority and communicate processing clearly;
• apply retention and deletion schedules;
• separate access according to role and necessity;
• pseudonymise or anonymise data where appropriate;
• assess cross-border transfers and cloud locations;
• provide mechanisms for exercising applicable individual rights;
• test the impact of monitoring on employees and customers.

Ethical practice extends beyond legal minimums. Security professionals may have access to powerful tools, private communications and sensitive investigations. They should act with competence, confidentiality, proportionality, honesty and respect for human autonomy. Vulnerability research should minimise harm, follow authorised scope and support responsible disclosure. Penetration testing without written authorisation can be unlawful even when the tester claims benevolent intent.

Algorithmic security systems also raise ethical issues. Automated fraud or access decisions may produce unequal effects, lack explainability or create excessive surveillance. Human review, documented thresholds, appeal routes and monitoring for error are important where decisions affect people significantly.

6. Third-Party and Supply-Chain Risk

Cloud providers, managed security services, software vendors, contractors and open-source components create dependencies beyond the organisation’s direct control. Third-party risk is not eliminated by signing a contract. The customer remains responsible for understanding its obligations, configuring services appropriately and responding to failures.

A lifecycle approach includes:

1. Inherent-risk assessment: identify data, connectivity, criticality, jurisdictions and concentration risk before selection.
2. Due diligence: review security architecture, independent assurance, incident history, resilience, personnel controls and subcontractors.
3. Contracting: define security requirements, audit rights, notification periods, data location, deletion, cooperation, service levels and exit assistance.
4. Onboarding: restrict accounts, integrate logging, define contacts and validate configurations.
5. Continuous monitoring: review changes, incidents, assurance reports, vulnerabilities and performance.
6. Exit: retrieve or securely delete data, revoke access, replace dependencies and preserve required records.

A supplier’s certification is useful evidence but does not answer every customer-specific question. Scope, exclusions, control exceptions and the age of the assessment must be examined. Fourth parties—subcontractors and platform dependencies—can create hidden concentration and cascading failure risks.

7. SASE and Security Service Edge

Secure Access Service Edge (SASE) is an architectural model that converges networking and security functions, commonly through cloud-delivered services and identity-aware access. It is associated with software-defined wide-area networking (SD-WAN), secure web gateways, cloud access security brokers, zero-trust network access and firewall-as-a-service.

Security Service Edge (SSE) focuses on the security-service portion of this model, including secure web access, private-application access and cloud-application controls. Terminology and product boundaries vary among vendors; procurement teams should evaluate capabilities rather than labels.

SASE and SSE respond to distributed work, SaaS adoption, branch connectivity and users accessing services from many locations. Their advantages can include consistent policy enforcement, reduced backhauling, central visibility and identity-based access. Risks include dependence on provider availability, policy complexity, data inspection at provider points of presence, vendor lock-in, latency, misconfiguration and concentration of failure.

A responsible design should define application-level access, device posture, identity assurance, logging, encryption, administrative separation, resilience and exit options. Replacing a network perimeter with a cloud security service does not remove the need for asset management, endpoint security, secure development or governance.

8. AI-Assisted Defence and Adversarial AI

Artificial intelligence can assist defenders by prioritising alerts, identifying unusual behaviour, summarising events, searching threat intelligence, generating detection rules and supporting analysts. Large language models can help explain logs or draft procedures, but their outputs may be inaccurate, incomplete or influenced by malicious input.

AI systems introduce distinctive risks:

• Prompt injection: untrusted content manipulates an AI system’s instructions.
• Data leakage: sensitive prompts, retrieved documents or outputs are exposed.
• Hallucination: a plausible but false explanation or recommendation is produced.
• Model drift: changing data or attacker behaviour reduces performance.
• Automation bias: analysts accept model recommendations without challenge.
• Poisoning: training or reference data are deliberately corrupted.
• Adversarial examples: inputs are crafted to cause misclassification.

Attackers also use AI to scale phishing, reconnaissance, social engineering, malware variation and vulnerability research. Defensive use should therefore follow a controlled lifecycle: define the decision being supported, classify data, test accuracy and bias, constrain permissions, log prompts and actions, require human approval for high-impact changes, and continuously evaluate against adversarial scenarios.

AI should not receive unrestricted administrative authority merely because it can produce technically convincing text. Tool access must be least-privileged, segmented and reversible. Evaluation should measure false positives, false negatives, analyst workload and business impact rather than marketing claims.

9. Post-Quantum Cryptography

Large-scale quantum computers could threaten widely deployed public-key systems based on integer factorisation or discrete logarithms, including RSA and elliptic-curve cryptography. Symmetric cryptography is affected differently; sufficiently large key sizes and appropriate algorithms provide stronger resistance, although implementation and key-management issues remain.

Post-quantum cryptography (PQC) uses classical computers to implement algorithms believed to resist quantum attacks. Standardisation efforts have focused on key-establishment mechanisms and digital signatures, including lattice-based and hash-based approaches. Organisations should not replace cryptography casually: algorithm selection, protocol support, certificate size, performance, hardware capability and implementation assurance matter.

The “harvest now, decrypt later” threat is important for data that must remain confidential for many years. A practical migration programme includes:

• inventorying cryptographic algorithms, keys, certificates and protocols;
• identifying data with long confidentiality lifetimes;
• requiring cryptographic agility in new designs;
• tracking supplier and standards developments;
• testing hybrid or transition mechanisms where appropriate;
• planning certificate, hardware and embedded-device replacement;
• avoiding unverified algorithms and rushed migration.

PQC does not solve weak access control, stolen keys, poor random-number generation or insecure endpoints. Quantum-resistant algorithms must be deployed as part of a wider cryptographic governance programme.

10. Digital Transformation and Future Risk

Digital transformation links cloud platforms, application programming interfaces, operational technology, mobile devices, analytics, digital identity and third-party ecosystems. Connectivity can improve efficiency but also increases dependency, attack surface and speed of propagation. A compromised identity provider, software pipeline or widely used library may affect many services simultaneously.

Future-oriented governance should address:

• concentration risk in major cloud and identity providers;
• software supply-chain integrity and dependency visibility;
• insecure APIs and machine-to-machine credentials;
• shadow IT and unapproved AI services;
• resilience of operational technology and safety systems;
• deepfakes and loss of trust in communications;
• autonomous or semi-autonomous decision systems;
• climate, energy and physical risks to data centres and connectivity;
• skills shortages and overdependence on opaque vendors.

The appropriate response is not to prohibit innovation. It is to establish guardrails: secure-by-design requirements, threat modelling, staged deployment, independent testing, recoverability, clear accountability and measurable residual risk.

Applied Case: Illustrative Regional Health Platform

Background

A regional health organisation operates clinics, a patient portal and cloud-hosted analytics. It uses several software suppliers, remote clinicians and a managed security provider. Patient information is exchanged through APIs, and a new AI assistant is proposed to help staff summarise records.

Problem

An audit finds incomplete asset inventories, inconsistent MFA, unclear supplier responsibilities and inadequate evidence that terminated contractor accounts are removed. The organisation has a privacy obligation to protect health information and cannot tolerate prolonged portal unavailability.

Analysis

The organisation first identifies critical services and information flows. Its risk assessment considers identity compromise, API abuse, supplier outage, ransomware, excessive AI disclosure and failure to restore backups. The audit finding is not treated as a single technical defect: it reflects governance, ownership, lifecycle and evidence weaknesses.

The NIST CSF is used to create a target profile. CIS Controls provide practical priorities such as asset inventory, account management, secure configuration, vulnerability management, logging and recovery. ISO/IEC 27001 requirements are used to structure leadership review, risk treatment, documented information, internal audit and continual improvement.

Approach and Solution

The organisation assigns service and data owners, implements phishing-resistant MFA for privileged and remote access, and automates joiner–mover–leaver workflows. API access is restricted by workload identity and least privilege. Supplier contracts specify incident notification, evidence access, subcontractor disclosure, recovery objectives and secure deletion.

The proposed AI assistant is initially limited to a test environment using de-identified records. It cannot alter clinical records, disclose information externally or make clinical decisions. Outputs require human verification, prompts are logged securely, and an independent privacy and safety review is required before expansion.

The organisation also performs restoration exercises, collects dated evidence for each control, and reports residual risks to the executive risk committee. A SASE capability is introduced selectively for remote access, but critical identity, endpoint and recovery controls remain under separate review.

Outcome

The organisation gains a defensible inventory, measurable access-review completion, clearer supplier accountability and tested recovery procedures. The AI project proceeds slowly, with explicit safeguards rather than unrestricted deployment. The case illustrates that frameworks are most valuable when they connect business services, control owners, evidence and decisions.

Learning Points

1. A framework does not replace risk ownership.
2. Privacy and security must be designed together.
3. Supplier assurance requires contracts, technical integration and ongoing monitoring.
4. AI should be constrained according to impact and data sensitivity.
5. Audit evidence must demonstrate operation, not merely intention.

Challenges and Limitations

Governance programmes can become bureaucratic if documentation is valued more than risk reduction. Frameworks may overlap, use different terminology or encourage checklist compliance. Risk scores can create false precision, particularly when likelihood data are weak. Certification can be misunderstood as proof of absolute security. Cloud and SASE services may improve consistency while increasing concentration and provider dependency. AI can increase analyst capability while also creating new attack paths and automation bias. PQC migration is technically complex and must be coordinated across suppliers and long-lived systems.

Professional judgement is therefore essential. Controls should be selected according to threat, consequence, legal duty, architecture, cost and organisational capability. Exceptions should be visible and reviewed. The objective is not perfect security—an unrealistic condition—but informed, accountable and continually improving risk management.

Best-Practice Checklist

• Establish accountable owners for services, information, risks and controls.
• Maintain current inventories of assets, identities, data flows, suppliers and cryptographic dependencies.
• Map business objectives to policies, controls, evidence and measurable outcomes.
• Use NIST CSF, CIS Controls and ISO/IEC 27001 for complementary purposes.
• Test operating effectiveness, not merely policy existence.
• Minimise personal data and protect audit evidence.
• Require written authorisation for security testing.
• Assess suppliers throughout selection, operation and exit.
• Treat AI outputs as advice unless explicitly validated and authorised.
• Plan cryptographic agility and post-quantum migration.
• Test restoration, communications and decision-making through exercises.
• Report residual risk honestly to an authorised decision-maker.

Chapter Summary

Security governance connects organisational objectives, risk appetite, policies, controls, evidence and assurance. Effective risk management identifies scenarios, evaluates likelihood and impact, selects proportionate treatment and assigns accountable owners. NIST CSF provides outcome-oriented functions; CIS Controls provide prioritised practical safeguards; and ISO/IEC 27001 provides an auditable information security management system.

Audit evidence must be relevant, reliable, sufficient, timely and traceable, while remaining protected as sensitive information. Privacy, law and ethics require more than technical confidentiality: they require lawful purpose, proportionality, transparency and responsible professional conduct. Third-party risk must be managed through the complete supplier lifecycle.

SASE and SSE can support distributed access but introduce provider, concentration and configuration risks. AI can improve defence while enabling new forms of attack, leakage and automation bias. Post-quantum cryptography requires inventory, agility and long-term migration planning. Across all emerging technologies, secure-by-design, human accountability, resilience and continuous improvement remain essential.

Key Terms

Governance: Direction, oversight and accountability for organisational activities.

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

Risk treatment: The decision to avoid, mitigate, transfer or accept risk.

Residual risk: Risk remaining after controls or other treatments are applied.

Policy: An approved statement of mandatory organisational intent.

Standard: A compulsory specification that supports a policy.

Control: A measure that modifies risk.

Assurance: Confidence that governance, risk management and controls are appropriate and effective.

Audit evidence: Information supporting an auditor’s conclusion against defined criteria.

NIST CSF: A cybersecurity framework organised around Govern, Identify, Protect, Detect, Respond and Recover.

CIS Controls: Prioritised safeguards for improving practical cybersecurity.

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

Privacy by design: Integrating privacy protections into systems and processes from the outset.

Third-party risk: Risk arising from suppliers, contractors and other external dependencies.

SASE: An architecture combining networking and security capabilities through policy-driven, often cloud-delivered services.

SSE: The security-service component of the SASE model.

Adversarial AI: Techniques that manipulate or attack artificial-intelligence systems.

Cryptographic agility: The ability to change cryptographic algorithms and mechanisms efficiently.

Post-quantum cryptography: Cryptography designed to resist attacks from anticipated quantum computers.

Residual risk: The remaining exposure after selected safeguards are implemented.

Review Questions

Short Answer Questions

1. Distinguish governance from security management.
2. Name and explain the four common risk-treatment options.
3. What are the six functions of NIST CSF 2.0?
4. Why is a supplier’s security certification not sufficient by itself?
5. Define cryptographic agility.

Long Answer Questions

1. Explain how policies, standards, procedures, controls and audit evidence form a governance chain.
2. Compare the purposes and limitations of NIST CSF, CIS Controls and ISO/IEC 27001.
3. Discuss how privacy and ethics influence security monitoring and AI-assisted defence.
4. Explain the benefits and risks of adopting SASE or SSE in a distributed organisation.
5. Develop a post-quantum cryptography migration plan for an organisation with long-lived confidential data.

Analytical / Application Questions

1. A cloud supplier refuses to provide detailed subcontractor information but offers a recent independent assurance report. Analyse the decision factors and recommend conditions for proceeding.
2. An AI monitoring system reduces alert volume by 60% but misses several simulated attacks. Evaluate whether it should be deployed and identify required safeguards.
3. An organisation has strong perimeter firewalls but no reliable asset inventory or tested backups. Use a framework-based approach to prioritise improvements and justify your sequence.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily a governance responsibility?

A. Configuring a firewall rule

B. Setting security direction and assigning accountability

C. Installing an endpoint agent

D. Reviewing a packet capture

Correct Answer: B. Setting security direction and assigning accountability

Question 2

Which risk treatment retains the activity but reduces its likelihood or impact?

A. Avoidance

B. Mitigation

C. Acceptance

D. Elimination of the organisation

Correct Answer: B. Mitigation

Question 3

What is the main purpose of the NIST CSF Govern function?

A. To define and monitor cybersecurity strategy, policy and oversight

B. To restore backups after an incident only

C. To replace all technical security controls

D. To perform vulnerability scanning exclusively

Correct Answer: A. To define and monitor cybersecurity strategy, policy and oversight

Question 4

Which is an example of operating effectiveness evidence?

A. A draft access-control policy

B. A vendor advertisement

C. Completed and approved quarterly access-review records

D. An unsigned security proposal

Correct Answer: C. Completed and approved quarterly access-review records

Question 5

Why does a supplier contract not eliminate third-party risk?

A. Contracts cannot contain any security requirements

B. The customer still has configuration, oversight and accountability responsibilities

C. Suppliers are never legally responsible

D. Technical controls are unnecessary after contracting

Correct Answer: B. The customer still has configuration, oversight and accountability responsibilities

Question 6

Which statement best describes SSE?

A. A physical cable standard

B. The security-service component associated with SASE

C. A method for deleting cloud accounts

D. A replacement for all endpoint protection

Correct Answer: B. The security-service component associated with SASE

Question 7

Which is a risk associated with AI-assisted security operations?

A. Guaranteed elimination of false positives

B. Hallucinated recommendations and automation bias

C. Inability to process any security data

D. Automatic compliance with every privacy law

Correct Answer: B. Hallucinated recommendations and automation bias

Question 8

What is the purpose of post-quantum cryptography?

A. To prevent all phishing attacks

B. To resist threats from anticipated quantum computing capabilities

C. To eliminate the need for key management

D. To make passwords unnecessary

Correct Answer: B. To resist threats from anticipated quantum computing capabilities

Question 9

An organisation estimates SLE at £40,000 and ARO at 0.5. What is the ALE?

A. £8,000

B. £20,000

C. £40,500

D. £80,000

Correct Answer: B. £20,000

Question 10

Which practice best supports privacy by design?

A. Collecting all available data indefinitely

B. Sharing personal data with every supplier

C. Collecting only data needed for a defined purpose

D. Disabling deletion processes

Correct Answer: C. Collecting only data needed for a defined purpose