Cybersecurity & Threat Management

Chapter 13
Cybersecurity Management, Metrics and Human Factors

Advance Diploma in Cybersecurity
Cybersecurity & Threat Management   •   Advance Diploma

Cybersecurity Management, Metrics and Human Factors

Introduction

Cybersecurity is not only a technical function. It is an organisational capability that protects information, services, people, assets and institutional trust while enabling legitimate business activity. Effective security management therefore combines governance, risk analysis, investment decisions, staffing, supplier oversight, performance measurement and human behaviour.

A security programme may contain excellent firewalls and endpoint tools yet remain ineffective if responsibilities are unclear, suppliers are unmanaged, employees are unprepared, or executives cannot determine whether investment is reducing material risk. Conversely, a mature programme does not attempt to eliminate every conceivable threat. It establishes priorities, allocates resources proportionately, measures outcomes and continually improves.

This chapter examines how security leaders develop and operate such programmes. It focuses on the relationship between strategy and operations, the design of meaningful metrics, maturity assessment, cost-benefit reasoning, human factors and security culture.

Learning Objectives

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

  1. Explain the components and governance requirements of an organisational cybersecurity programme.
  2. Develop high-level security budgets, staffing plans and awareness initiatives.
  3. Evaluate supplier, outsourcing and operational risks.
  4. Distinguish key risk indicators from key performance indicators.
  5. Design dashboards that support executive decisions rather than merely report activity.
  6. Apply maturity models and basic cost-benefit analysis.
  7. Explain how human behaviour, organisational culture and ethical leadership affect security outcomes.
  8. Critically evaluate limitations of metrics, models and security investments.

1. Cybersecurity as an Organisational Management System

A cybersecurity programme is a coordinated set of policies, people, processes, technologies and assurance activities designed to manage cyber risk. It should be aligned with organisational objectives, legal duties and risk appetite. A programme is broader than a security operations centre or a collection of security products.

A useful management cycle is:

Direct → assess → prioritise → implement → measure → improve.

Direction establishes purpose, scope, authority and risk tolerance. Assessment identifies threats, vulnerabilities, dependencies and consequences. Prioritisation determines which risks deserve treatment first. Implementation introduces controls and capabilities. Measurement tests whether the controls are operating and whether risk is changing. Improvement responds to evidence, incidents, audits, new technology and changing business conditions.

Governance, management and operations

Governance is the process by which the governing body and executives direct and oversee cybersecurity. It addresses accountability, strategy, risk appetite and assurance. Management converts that direction into plans, budgets, policies and control ownership. Operations perform activities such as monitoring, vulnerability remediation, access administration, incident response and recovery.

These levels must be connected. A board may approve a low tolerance for interruption of critical services, but that decision has practical consequences: resilient architecture, tested recovery procedures, supplier requirements, adequate staffing and measurable recovery capability.

Typical accountability arrangements include:

RolePrincipal responsibility
Board or governing bodyOversight, risk appetite and challenge
Executive leadershipResources, priorities and organisational accountability
Chief Information Security OfficerSecurity strategy, programme coordination and advice
System and business ownersRisk decisions and control implementation for their assets
Internal audit or assuranceIndependent evaluation of governance and controls
Employees and contractorsCompliance with policy and reporting of suspected events
SuppliersContractual security obligations and evidence of performance

A RACI matrix can clarify who is Responsible, Accountable, Consulted and Informed for activities such as patching, incident notification and recovery testing. It prevents the common failure in which everyone is assumed to be responsible but no one is accountable.

2. Building the Security Programme

Establishing scope and strategic alignment

The programme should begin with an inventory of organisational objectives and information assets. A hospital, for example, may prioritise patient safety and clinical availability; a bank may prioritise transaction integrity and confidentiality; a university may need to balance research openness with protection of personal data and intellectual property.

The security strategy should identify:

  • critical services and information;
  • legal, regulatory and contractual obligations;
  • principal threat scenarios;
  • risk appetite and unacceptable outcomes;
  • target capabilities and maturity;
  • investment priorities and time horizons; and
  • methods of reporting progress.

Security objectives should be expressed in business terms. “Reduce exploitable weaknesses in internet-facing systems” is more useful than “improve security posture,” because it can be linked to ownership, deadlines and evidence.

Risk-based prioritisation

Risk treatment commonly involves avoiding, reducing, transferring or accepting risk. Acceptance should be explicit, documented and authorised by an appropriate risk owner. Cybersecurity staff should not silently accept risks on behalf of business owners.

A simple annual loss expectation model can support initial comparison of scenarios. The single loss expectancy is:

SLE = AV × EF

where SLE is the estimated loss from one occurrence, AV is the asset value in monetary units, and EF is the exposure factor, expressed as a proportion from 0 to 1. If the estimated asset value is £500,000 and a scenario would affect 40% of that value, SLE is £200,000.

The annual rate of occurrence is then used to estimate annual loss expectancy:

ALE = SLE × ARO

where ALE is annual loss expectancy in monetary units and ARO is the expected number of occurrences per year. If SLE is £200,000 and ARO is 0.25, ALE is £50,000 per year.

These equations are screening tools, not precise predictions. They assume that the estimates are meaningful, that loss events can be represented by an average value and frequency, and that the time period is consistent. They may omit correlated events, regulatory penalties, reputational effects and uncertainty. More mature analysis uses ranges, scenarios, sensitivity analysis or probability distributions.

Security architecture and control selection

Controls should be selected according to risk, not popularity. A control may be preventive, detective, corrective, deterrent or compensating. It may also be administrative, technical or physical. Defence in depth is valuable because failure of one control should not automatically produce catastrophic compromise.

Control design should consider effectiveness, usability, maintainability, independence and residual risk. For example, multi-factor authentication can substantially reduce account-takeover risk, but poor implementation may create workarounds, exclude users with accessibility needs or leave non-integrated legacy applications exposed.

3. Budgeting and Staffing

Constructing a cybersecurity budget

A security budget should show how expenditure supports risk reduction and organisational objectives. Major categories commonly include:

  • personnel and professional development;
  • security platforms, licences and maintenance;
  • managed services and specialist consulting;
  • testing, audit and certification;
  • incident response and digital forensics;
  • resilience, backup and recovery capabilities; and
  • awareness, training and communications.

Budget proposals should distinguish operating expenditure from capital expenditure where the organisation uses that accounting distinction. They should also identify one-time implementation costs, recurring costs, dependencies and the consequences of underfunding.

Cost-benefit analysis should not claim false precision. A basic net benefit calculation is:

Net benefit = Expected benefit − Total cost

If a proposed control has an estimated annual benefit of £120,000 and total annual cost of £80,000, the estimated net benefit is £40,000. The estimate is useful only if the benefit definition, time period, assumptions and uncertainty are made explicit.

A more complete investment analysis may include discounted cash flow. For a project with cash flows over several periods:

NPV = −C₀ + ∑(t=1 to n) [Cₜ ÷ (1 + r)ᵗ]

Here NPV is net present value, C₀ is the initial investment, Cₜ is the net cash flow in period t, r is the discount rate per period and n is the number of periods. The formula assumes cash flows and the discount rate are defined on the same time basis. Security benefits are often uncertain and non-financial, so NPV should support rather than replace risk judgement.

Staffing and capability planning

Staffing should be based on required services and coverage rather than a fixed ratio of employees to security staff. A capability model asks:

  1. Which services must be provided internally?
  2. Which activities require 24-hour coverage?
  3. Which specialist skills are scarce?
  4. What workloads are generated by assets, alerts, incidents and regulatory obligations?
  5. Which functions can be safely outsourced?
  6. What resilience is required if a key person is unavailable?

Important roles may include security architecture, governance and risk, identity management, security engineering, vulnerability management, detection and response, threat intelligence, privacy, third-party assurance and awareness.

Workforce risk includes burnout, excessive on-call demands, skills obsolescence and dependence on one expert. Sustainable staffing requires training, succession planning, documentation, role rotation and psychological safety. A security team that is technically capable but chronically exhausted is itself an operational risk.

4. Suppliers and Operational Risk

Modern organisations depend on cloud providers, software vendors, managed security service providers, contractors, telecommunications companies and data processors. Supplier risk is therefore a component of enterprise risk, not merely a procurement issue.

Third-party risk lifecycle

A robust lifecycle includes:

  1. Inherent-risk classification: assess data sensitivity, access, criticality, concentration and geographic exposure before controls are considered.
  2. Due diligence: examine security governance, certifications, independent assurance, incident history, resilience and subcontractors.
  3. Contracting: define security requirements, audit rights, notification periods, data location, vulnerability management, access control, continuity and exit assistance.
  4. Onboarding: verify accounts, interfaces, data flows and responsibilities.
  5. Monitoring: review performance evidence, incidents, changes, testing and emerging risks.
  6. Offboarding: revoke access, return or securely delete data, retrieve assets and verify transition arrangements.

A certification is evidence, not a guarantee. It may have limited scope, an old assessment date or exclusions that matter to the customer. Organisations should understand the difference between a control description, an independent test and actual evidence that a control operated during the relevant period.

Operational resilience

Operational risk concerns failures of processes, people, systems or external dependencies. Security management should identify critical business services, maximum tolerable disruption, recovery priorities and dependencies. Business continuity and disaster recovery exercises should test realistic scenarios, including unavailable suppliers, corrupted backups and communications failure.

Concentration risk is particularly important in cloud and managed-service ecosystems. Several suppliers may ultimately depend on the same platform, region, identity provider or telecommunications carrier. Apparent diversity may therefore be illusory.

5. Metrics, Indicators and Dashboards

Measurement is valuable only when it informs a decision. Counting activities can create the appearance of control without demonstrating reduced risk.

KPI, KRI and control metrics

A key performance indicator (KPI) measures progress toward an objective. Examples include the proportion of critical systems patched within the required period or the percentage of privileged accounts reviewed on schedule.

A key risk indicator (KRI) signals changing exposure or the likelihood of an undesirable outcome. Examples include the number of unsupported internet-facing systems, phishing reports involving privileged users or the percentage of critical suppliers lacking tested recovery arrangements.

A control metric measures whether a control is operating, such as the percentage of endpoint agents reporting successfully. A control metric is not automatically evidence that risk has been reduced. An endpoint agent may report as healthy while a device remains vulnerable because its operating system is unsupported.

Good metrics have a defined owner, population, calculation method, frequency, target, threshold, data source and response. They should be comparable over time and resistant to manipulation.

Metric construction

For a percentage metric:

Percentage = (Numerator ÷ Denominator) × 100

The numerator must be a subset of the denominator, both must refer to the same period and scope, and the denominator must be defined consistently. If 920 of 1,000 critical assets meet a patching standard, compliance is 92%.

Metrics should be segmented where aggregation conceals risk. A 92% overall result may hide 100% compliance for low-impact assets and 60% for internet-facing critical systems. Dashboards should therefore allow executives to see trend, severity, business owner, exceptions and overdue remediation.

Dashboard design

An executive dashboard should answer four questions:

  • What is our most material exposure?
  • Is exposure increasing or decreasing?
  • Are management actions effective?
  • What decision or escalation is required?

A useful dashboard combines outcome, risk and activity measures. For example:

DimensionExample measureManagement interpretation
ExposureCritical vulnerabilities beyond remediation targetCurrent unresolved risk
ResilienceRecovery tests meeting recovery objectivesAbility to continue and restore services
Control operationPrivileged access reviews completedWhether a key control is functioning
Human behaviourReported suspicious messages per 1,000 usersReporting culture and exposure signal
ResponseMedian time to contain high-severity incidentsOperational capability

Metrics can produce harmful behaviour. A target to reduce incident counts may discourage reporting. A target to close tickets quickly may reward superficial closure. Leaders should look for counter-metrics, independent validation and qualitative context.

6. Maturity Models and Continuous Improvement

Maturity models describe the progression from ad hoc activity to repeatable, measured and optimised capability. A generic five-level model is:

LevelCharacteristics
1. InitialInformal, reactive and highly dependent on individuals
2. DevelopingBasic processes exist but are inconsistent
3. DefinedPolicies, roles and standard processes are established
4. ManagedPerformance is measured and risk-based management is routine
5. OptimisedContinuous improvement, automation and adaptive learning are embedded

Maturity is multidimensional. An organisation may have mature identity governance but immature supplier assurance. A maturity score is therefore a diagnostic, not a security rating or proof of compliance.

Assessment should use evidence such as policies, records, configuration data, interviews, test results and incident lessons. The desired maturity level should be based on mission criticality, threat exposure, regulatory expectations and cost—not on the assumption that level five is always necessary.

The improvement cycle resembles Plan–Do–Check–Act: establish objectives and controls, operate them, evaluate evidence, then correct and improve. Lessons from incidents and near misses should lead to changes in architecture, process, training or governance rather than merely individual blame.

7. Human Factors and Security Culture

People are neither simply the weakest link nor an infallible last line of defence. Human behaviour is shaped by workload, incentives, interface design, authority relationships, habits, trust and perceived consequences.

Behavioural influences

Common influences include:

  • Authority and urgency: attackers exploit requests apparently issued by senior staff.
  • Cognitive load: tired or interrupted users make more errors.
  • Normalisation of deviance: repeated policy violations become accepted because no immediate harm occurs.
  • Overconfidence: experienced users may underestimate social-engineering risk.
  • Fear of blame: employees may conceal mistakes instead of reporting them.
  • Usability friction: controls that obstruct legitimate work encourage workarounds.

Security culture is demonstrated by everyday decisions: whether staff report mistakes promptly, whether managers support secure procedures under deadline pressure, whether privileged access is challenged and whether lessons are shared without unfair blame.

Awareness and behaviour-change programmes

Awareness is not synonymous with an annual online course. Effective programmes identify target behaviours, explain why they matter, provide usable procedures, rehearse decisions and measure outcomes.

A practical programme may include role-specific learning for executives, developers, administrators, finance staff and general users; simulated exercises that are ethical and non-punitive; accessible reporting channels; secure-by-default technology; and feedback after incidents.

Training metrics should include behaviour and outcomes, not only completion. Relevant measures may include reporting speed, use of approved authentication methods, repeat policy violations and time to correct risky configurations. Simulated phishing exercises must respect privacy, accessibility and employment law; public humiliation is counterproductive and unethical.

8. Ethics, Privacy and Responsible Use of Data

Security monitoring can involve employee communications, device activity, location data and behavioural profiles. Legitimate security objectives do not remove obligations of necessity, proportionality, transparency, purpose limitation, access control and retention. Organisations should consult legal, privacy and employee representatives where appropriate.

Security leaders face ethical choices when using surveillance, automated risk scoring or artificial intelligence. A model may generate false positives, encode bias or encourage disproportionate scrutiny of particular groups. Automated recommendations should be explainable enough for responsible review, and consequential decisions should retain human oversight.

Incident disclosure presents another tension. Organisations must communicate accurately and promptly while protecting investigations and affected individuals. Concealing material facts damages trust and may breach legal or contractual duties.

9. Contemporary Developments and the Role of AI

Cloud-native services, software supply chains, remote work, operational technology and artificial intelligence have expanded the security management problem. Security teams must understand identity-centric architecture, machine-to-machine access, application programming interfaces, infrastructure-as-code and dependency risk.

AI can assist with alert triage, summarisation, anomaly detection, code review and threat-intelligence analysis. However, generated content may be inaccurate, confidential data may be exposed to an external service, and attackers can use AI to increase the scale and quality of social engineering. Governance should define approved tools, data-handling restrictions, validation requirements, logging and accountability.

The appropriate management question is not whether AI is fashionable, but whether a particular use case produces reliable value at acceptable risk. Human review remains essential for high-impact decisions, novel incidents and actions that could disrupt critical services.

Applied Case: Northbridge University’s Security Programme

This is an illustrative fictional case.

Background

Northbridge University operates research laboratories, online learning systems, payment services and a large bring-your-own-device population. Its IT department had purchased several security tools independently. The board received monthly reports listing blocked attacks and training completion but lacked a view of material risk.

Problem

A review found that 18% of internet-facing systems had unresolved critical vulnerabilities, two important suppliers had no tested recovery evidence, and privileged accounts were reviewed inconsistently. Staff were reluctant to report suspicious messages because previous awareness campaigns publicly identified individuals who had clicked simulated links.

Analysis

The CISO mapped critical services and assigned business owners. Risk analysis showed that disruption of learning identity services would affect teaching, assessment and access to research systems. Supplier concentration also meant that several services depended on one identity platform. Existing metrics measured activity but not exposure or resilience.

Approach

The university established a risk committee, a RACI matrix and a three-year target capability plan. It prioritised phishing-resistant multi-factor authentication for privileged and high-risk users, vulnerability remediation for internet-facing systems, tested recovery for critical suppliers and a confidential reporting channel. The dashboard was redesigned to include overdue critical vulnerabilities, privileged-access review coverage, recovery-test results, high-severity response time and reporting behaviour.

The awareness programme shifted from blame to learning. Exercises were role-specific, accessible and followed by short explanations. Supplier contracts were amended at renewal to require incident notification, evidence of recovery testing and secure offboarding.

Outcome

After two reporting cycles, executive decisions focused on the most exposed services rather than the largest number of blocked events. Reporting increased, which initially appeared to be a deterioration but actually indicated greater trust and visibility. The university also identified that one supplier’s recovery claim did not cover a dependency on the university’s own identity platform, leading to a revised resilience design.

Learning points

The case illustrates four principles: metrics must support decisions; maturity must be assessed by capability and evidence; supplier risk includes dependency chains; and a psychologically safe culture can increase reported events while reducing hidden risk.

Challenges and Limitations

No model eliminates uncertainty. Risk estimates may be affected by incomplete inventories, changing threats, uncertain loss values and correlated failures. Metrics may be gamed or misinterpreted. Maturity models can encourage compliance theatre when organisations pursue scores rather than outcomes. Cost-benefit analysis may undervalue human safety, institutional trust and long-term resilience because these benefits are difficult to monetise.

Security leaders should therefore combine quantitative and qualitative evidence, state assumptions, use ranges where appropriate, validate data quality and invite challenge from business owners, auditors, privacy specialists and affected users. The strongest decision is not necessarily the one with the highest calculated return; it is the one that best supports mission objectives within accepted risk and ethical constraints.

Best-Practice Principles

  1. Align security objectives with critical services and organisational purpose.
  2. Assign accountable risk owners and document accepted risk.
  3. Fund capabilities and sustainable staffing, not isolated products.
  4. Treat suppliers and concentration dependencies as part of the attack surface.
  5. Use a small number of decision-oriented metrics with clear definitions.
  6. Combine leading indicators, lagging indicators and qualitative context.
  7. Measure outcomes and resilience, not merely activity or tool output.
  8. Design awareness around behaviour, usability and psychological safety.
  9. Protect privacy and apply human oversight to monitoring and automation.
  10. Reassess strategy after incidents, near misses, major technology changes and organisational change.

Chapter Summary

Cybersecurity management is an organisational discipline that integrates governance, risk management, technology, people, suppliers and continuous improvement. A credible programme begins with business priorities and critical services, assigns accountability and selects controls according to risk. Budgets should explain how investment supports risk reduction, while staffing plans must address capability, resilience, workload and succession.

Supplier assurance requires a lifecycle covering classification, due diligence, contracting, monitoring and secure exit. Metrics are useful only when their scope, owner, calculation and management response are clear. KPIs measure progress, KRIs signal exposure and control metrics show whether controls operate; none should be interpreted without context. Dashboards should support executive decisions through trend, severity, exceptions and required action.

Maturity models provide structured diagnostic language but do not prove security. Human factors are central because behaviour is shaped by culture, usability, incentives and trust. Awareness programmes should promote reporting and secure behaviour rather than blame. Finally, ethical governance, privacy protection and cautious use of AI are essential as monitoring and automation become more pervasive.

Key Terms

Annual rate of occurrence (ARO): Estimated number of times a risk event occurs in one year.

Annual loss expectancy (ALE): Estimated annual financial loss, calculated in a basic model as SLE × ARO.

Awareness programme: Organised activities intended to develop secure knowledge, behaviour and reporting.

Business owner: Person accountable for the risks and decisions associated with a business service or asset.

Control metric: Measure of whether a specified security control is operating.

Cybersecurity programme: Coordinated people, processes, technologies and assurance activities for managing cyber risk.

Defence in depth: Use of multiple complementary controls so one failure does not cause total compromise.

Exposure factor (EF): Proportion of asset value expected to be affected by one loss event.

Key performance indicator (KPI): Measure of progress toward an organisational or security objective.

Key risk indicator (KRI): Measure that signals changing exposure or likelihood of an undesirable event.

Maturity model: Framework describing progressive levels of capability and institutionalisation.

Net present value (NPV): Present value of future net cash flows less initial investment.

Operational risk: Risk arising from failures of people, processes, systems or external dependencies.

Residual risk: Risk remaining after controls and treatments are applied.

Risk appetite: Amount and type of risk an organisation is willing to pursue or retain.

Risk owner: Person authorised and accountable for managing a defined risk.

Single loss expectancy (SLE): Estimated loss from one occurrence of a risk event.

Supplier concentration risk: Risk arising from excessive dependence on one provider, platform or dependency.

Security culture: Shared values and behaviours that shape how an organisation handles security.

Third-party risk management: Processes for assessing and controlling risks associated with suppliers and service providers.

Review Questions

Short Answer Questions

  1. Distinguish governance, management and cybersecurity operations.
  2. What is the difference between a KPI and a KRI?
  3. Why is a supplier certification not a complete guarantee of security?
  4. State two ways that security culture affects incident reporting.
  5. What are the five levels in the generic maturity model presented in this chapter?

Long Answer Questions

  1. Explain how an organisation should develop a risk-aligned cybersecurity programme from strategy through continuous improvement.
  2. Discuss the main components of a cybersecurity budget and the limitations of cost-benefit analysis.
  3. Describe a complete third-party risk-management lifecycle and explain why supplier concentration matters.
  4. Evaluate the principles of effective executive security dashboards.
  5. Explain how awareness, usability, incentives and psychological safety influence human security behaviour.

Analytical / Application Questions

  1. An organisation estimates an asset value of £800,000, an exposure factor of 25% and an annual rate of occurrence of 0.2. Calculate SLE and ALE, state your assumptions, and explain why the result should not be treated as a precise forecast.
  2. A dashboard reports 98% patch compliance, but all overdue patches are on critical internet-facing systems. Analyse why the metric is misleading and propose three improved measures.
  3. A managed service provider refuses to provide recovery-test evidence but is critical to service continuity. Recommend a risk treatment, contract response and executive escalation path.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a KRI from a KPI?

A. A KRI measures exposure or changing risk, while a KPI measures progress toward an objective.

B. A KRI is used only by auditors, while a KPI is used only by engineers.

C. A KRI always measures financial loss, while a KPI always measures technical controls.

D. A KRI is historical, while a KPI must always predict future events.

Correct Answer: A. A KRI measures exposure or changing risk, while a KPI measures progress toward an objective.

Question 2

An asset has an estimated value of £400,000 and an exposure factor of 30%. What is the single loss expectancy?

A. £12,000

B. £120,000

C. £280,000

D. £1,333,333

Correct Answer: B. £120,000

Question 3

Which activity belongs primarily to supplier offboarding?

A. Classifying inherent supplier risk before procurement

B. Reviewing a supplier’s independent assurance report

C. Revoking access and verifying data return or deletion

D. Defining the organisation’s risk appetite

Correct Answer: C. Revoking access and verifying data return or deletion

Question 4

What is a major limitation of a maturity score?

A. It cannot provide any common language for improvement.

B. It proves that all security controls are effective.

C. It may encourage pursuit of a score rather than meaningful security outcomes.

D. It can only be used for technical vulnerability scanning.

Correct Answer: C. It may encourage pursuit of a score rather than meaningful security outcomes.

Question 5

Which dashboard measure most directly represents current unresolved exposure?

A. Number of security newsletters issued

B. Number of critical vulnerabilities beyond their remediation target

C. Number of security staff attending conferences

D. Number of awareness slides viewed

Correct Answer: B. Number of critical vulnerabilities beyond their remediation target

Question 6

Why can an increase in suspicious-message reports be a positive result?

A. It proves that the organisation has eliminated phishing.

B. It may indicate greater visibility and psychological safety to report events.

C. It means users no longer need technical controls.

D. It shows that all reported messages are confirmed attacks.

Correct Answer: B. It may indicate greater visibility and psychological safety to report events.

Question 7

Which formula represents annual loss expectancy in the basic model used in this chapter?

A. ALE = AV ÷ EF

B. ALE = EF ÷ ARO

C. ALE = SLE × ARO

D. ALE = ARO − SLE

Correct Answer: C. ALE = SLE × ARO

Question 8

Which staffing practice reduces key-person dependency?

A. Keeping procedures undocumented to preserve specialist knowledge

B. Using succession planning, documentation and skills development

C. Assigning all critical duties to one highly experienced employee

D. Removing training so staff remain focused on operations

Correct Answer: B. Using succession planning, documentation and skills development

Question 9

What is the principal purpose of a RACI matrix?

A. To calculate annual loss expectancy

B. To encrypt supplier communications

C. To clarify responsibility and accountability for activities

D. To replace all security policies

Correct Answer: C. To clarify responsibility and accountability for activities

Question 10

Which is an ethical concern when using AI for employee security-risk scoring?

A. The system may produce bias or false positives requiring human oversight.

B. AI always prevents unauthorised access.

C. Automated scores cannot affect privacy.

D. AI outputs never require validation.

Correct Answer: A. The system may produce bias or false positives requiring human oversight.

Cybersecurity & Threat Management
Chapter 13 of 14