P3: Cyber risk

Answer: A. This scenario describes ransomware — malicious software that encrypts an organisation's files, rendering them inaccessible, and then demands payment (typically in cryptocurrency) in exchange for the decryption key needed to restore access. Ransomware primarily targets the availability of data and systems — the organisation typically still has its data, but cannot access or use it without the decryption key, distinguishing this from attacks that instead target confidentiality (unauthorised viewing of data) or integrity (unauthorised alteration of data). A virus is a genuinely distinct category of malware — self-replicating code that attaches to legitimate programs — which, while it can sometimes be used to deliver ransomware, is not definitionally identical to ransomware itself. Spyware covertly monitors and collects information about user activity without their knowledge, a fundamentally different mechanism and objective from encrypting files and demanding payment. Ransomware is a category of malicious software, not a firewall configuration vulnerability — firewalls are a defensive control that can help prevent malware delivery, not the malware itself.

Answer: B. This scenario describes SQL injection — a web application attack that typically exploits inadequate validation or sanitisation of user input before it is passed to the underlying database, allowing an attacker to craft input that the database interprets as executable database commands rather than as plain, harmless text data, potentially enabling unauthorised retrieval, modification or deletion of data the attacker should not be able to access. This is fundamentally different from a denial-of-service attack, which aims to overwhelm a system's capacity to make it unavailable to legitimate users, rather than to manipulate database queries through crafted input — the mechanism and objective are genuinely distinct attack types. Social engineering specifically involves psychological manipulation of human individuals (such as tricking someone into revealing a password), a fundamentally different mechanism from exploiting a technical input validation weakness in software. Ransomware involves encrypting files and demanding payment, a distinct malware category and mechanism entirely separate from the input validation exploitation described in a SQL injection attack.

Answer: C. This scenario describes a phishing attack, and more specifically a form often called business email compromise or CEO fraud — impersonating a senior individual to create a false sense of urgency and authority that pressures the recipient into bypassing normal verification processes and making an unauthorised payment. It is often effective despite technical security controls being in place because it exploits human psychology — urgency, deference to perceived authority, and trust in an apparently familiar sender — rather than a purely technical vulnerability that firewalls, antivirus software or other technical controls are primarily designed to address, which is precisely why security awareness training and verification procedures (such as requiring a second channel of confirmation for unusual payment requests) are important complementary controls alongside technical measures. This is not a SQL injection attack, which exploits database input validation weaknesses, a technically and mechanically distinct attack category from psychologically manipulative phishing emails. Phishing is not a consequence of firewall misconfiguration — it is a distinct social engineering attack category targeting human behaviour and judgement, not a technical network security gap. It is also not a physical security breach — the interaction occurs entirely through electronic communication, with no physical intrusion onto the organisation's premises involved.

Answer: D. ISO 27001 provides an internationally recognised framework and set of requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS) — deliberately covering people (roles, training, awareness), processes (policies, procedures, risk assessment) and technology (technical controls) together, rather than being a narrow, purely technical specification, reflecting the reality that effective information security depends on more than technology alone. It is not a hardware configuration specification for firewalls specifically — it addresses information security management holistically, including but not limited to specific technical control choices, which individual organisations determine based on their own risk assessment within the ISO 27001 framework's broader structure. The standard is applicable to organisations across both public and private sectors internationally, not restricted to government bodies alone. ISO 27001 does not mandate use of a single, identical, prescribed software product across all certified organisations — it sets out a risk-based management system framework within which organisations select and implement controls appropriate to their own specific risk assessment and context, allowing for considerable variation in the specific technical and procedural choices made by different certified organisations.

Answer: A. This practice is called penetration testing (or 'pen testing') — engaging an authorised, specialist third party to deliberately and systematically attempt to breach an organisation's own systems using genuine attacker techniques, under controlled and legally authorised conditions, specifically to identify exploitable vulnerabilities that could otherwise be discovered and exploited by a real malicious actor. Its value lies precisely in this proactive identification: vulnerabilities found through authorised, controlled testing can be remediated in a planned way before they cause actual harm, rather than the organisation only discovering the weakness after a genuine, damaging attack has already occurred. This is not ransomware deployment — ransomware is malicious software used by genuine attackers for extortion, an entirely different activity, purpose and legal status from authorised, contracted penetration testing conducted with the organisation's own consent and typically with carefully agreed scope and legal protections. Penetration testing may incorporate social engineering techniques as one element of a broader testing scope, but it is not exclusively or solely social engineering — it typically also includes technical testing methods across networks, applications and systems. Proactively identifying vulnerabilities before a real attacker does provides substantial, well-recognised value compared with the alternative of only learning about a weakness once it has already been exploited by a genuine attacker, contrary to a claim of no meaningful benefit.

Answer: B. This scenario illustrates pretexting — a social engineering technique in which the attacker fabricates a plausible scenario and identity (a senior executive with an urgent, understandable problem) to manipulate a target (the helpdesk employee) into taking an action, such as resetting a password, that they might not take under more careful scrutiny. A robust, independent identity verification procedure — one that does not rely on confident tone, claimed identity, or information that could plausibly have been obtained from public sources, but instead requires verification through an independent, harder-to-fake channel — can help mitigate this kind of attack by removing the reliance on the helpdesk employee's own judgement under social pressure. This is not ransomware, a distinct malware category involving file encryption and extortion, unrelated to a telephone impersonation scenario. It is not a firewall vulnerability — the attack targets human judgement and verification procedures, not network security configuration. It is also not SQL injection, which exploits technical database input validation weaknesses, a mechanically distinct category from a human-focused telephone deception.

Answer: C. Digital forensic analysis addresses exactly these needs following a confirmed cyber incident — systematically investigating how the attacker gained access, what systems and data may have been affected, and preserving relevant evidence in a way that supports subsequent legal, regulatory, or insurance-related action. Evidence handling requires particular care to preserve both the integrity of the evidence itself and a clear, documented chain of custody, since improperly handled evidence — for example, evidence that has been altered, or whose handling history cannot be clearly documented — may be ruled inadmissible in legal proceedings, or may itself introduce doubt about the investigation's conclusions even where no formal legal proceeding follows. This is distinct from penetration testing, which is proactive, authorised testing conducted before an incident to identify vulnerabilities, rather than reactive investigation conducted after a genuine incident has already occurred — the timing and purpose of the two activities are different. Understanding how an attacker gained access remains important even after immediate technical containment, since this understanding informs both any legal/regulatory response and how similar future incidents can be prevented — skipping this step leaves the underlying vulnerability and its lessons unaddressed. This is not social engineering — forensic investigation is a technical and procedural investigative discipline, not a technique for psychologically manipulating individuals.

Answer: D. Cyber risk can have consequences extending well beyond the technical IT domain — a significant cyber incident can cause substantial reputational damage, trigger regulatory penalties and legal liability (particularly under data protection regimes), disrupt core business operations, and carry material financial consequences — meaning board-level awareness and active oversight is important as part of the organisation's overall governance and enterprise risk management, not something that can be adequately addressed as a purely technical, IT-department-level operational matter. Claiming cyber risk has no strategic, financial or reputational connection at all directly contradicts extensive well-documented evidence of major cyber incidents causing exactly these kinds of broader organisational consequences across many organisations. The IT function typically requires appropriate resourcing, prioritisation and organisational support decisions that depend on board-level awareness and sponsorship — assuming IT alone always has complete, sufficient authority and resources regardless of board involvement understates the genuine governance and resourcing role the board plays in supporting effective cyber risk management. Board-level cyber risk oversight has become increasingly important across organisations in virtually all sectors that depend on digital systems and data, not confined to technology companies specifically.

Answer: A. A data breach specifically refers to an event involving unauthorised access to, or disclosure of, data — this often, but not always, arises from a broader cyber incident (such as a successful hacking attack), but a data breach could also arise from non-cyber causes such as physical loss of a device or documents, or human error such as accidentally sending sensitive information to the wrong recipient. A cyber incident is the broader term, covering any event that compromises the confidentiality, integrity, or availability of information systems — a denial-of-service attack, for example, is a cyber incident affecting availability, but does not necessarily involve any data breach (unauthorised access or disclosure) at all. Treating the two terms as identical collapses a distinction that matters for how each is classified, reported and responded to, including for regulatory notification purposes which often specifically hinge on whether a data breach (not merely any cyber incident) has occurred. The roles are reversed in the third option relative to their actual standard scope. Data breaches can arise from a range of different causes and cyber incident types, not exclusively ransomware — including hacking, insider misuse, and non-cyber causes such as physical loss, making the ransomware-only framing inaccurate and unduly narrow.

Answer: B. This describes a distributed denial-of-service (DDoS) attack — flooding a target with overwhelming traffic from many distributed sources simultaneously (often via a network of compromised devices), overwhelming its capacity to respond to legitimate requests. This primarily compromises availability — one of the three core elements of information security alongside confidentiality and integrity — since the underlying data itself is typically not accessed or altered, but legitimate users are prevented from accessing the service while the attack continues. This is not SQL injection, which exploits database input validation weaknesses to access or manipulate data, a mechanically distinct attack. It is not ransomware, a distinct malware category involving file encryption and extortion. It is also not pretexting, a social engineering technique involving fabricated identity, mechanically unrelated to a traffic-flooding attack against infrastructure.

Answer: C. Delaying a security patch for a known, publicly disclosed vulnerability leaves that vulnerability unaddressed for longer than necessary, creating a window of exposure that attackers can exploit — attackers often specifically monitor for and target known, publicly disclosed vulnerabilities in organisations that have not yet applied the available fix. Timely patch management — applying available security patches as promptly as practical, balanced against genuine operational considerations — closes this window of known exposure before it can be exploited. Claiming a publicly disclosed vulnerability is no longer a genuine concern inverts the actual risk dynamic — public disclosure without a corresponding patch often increases real-world exploitation risk, as the vulnerability becomes more widely known to potential attackers. Patch management is relevant to organisations of essentially any size using software with known vulnerabilities, not confined to very large organisations, even though resourcing may vary. While patches can occasionally introduce operational issues needing careful testing, this does not mean patching always introduces more risk than leaving a known, actively targeted vulnerability unaddressed.

Answer: D. Insider threat is often considered particularly challenging because insiders already possess legitimate access and detailed knowledge of the organisation's systems, data and processes — many external-facing technical defences, such as firewalls designed to keep unauthorised outsiders out, are not designed to prevent someone with already-authorised access from misusing that access, meaning insider threat requires a different set of controls, such as monitoring of unusual data access patterns, data loss prevention tools, and appropriately restricted access rights aligned to genuine business need (the principle of least privilege). Describing insider threat as not a genuine risk category ignores well-documented cases, including the kind of deliberate data exfiltration described in this scenario, where legitimate access was misused to cause genuine harm. Firewall configuration alone is not sufficient to address insider threat, given that insiders already operate from within the trusted network perimeter that firewalls are primarily designed to protect against external intrusion — additional controls specifically addressing insider risk are needed. Insider threat is a relevant risk consideration for organisations of varying sizes with employees who have system or data access, not confined to very small organisations — indeed, larger organisations with more extensive workforces and more complex access structures often face a larger overall insider threat surface.

Answer: A. This describes a Trojan (or trojan horse) — malware that disguises itself as legitimate, desirable software to trick a user into voluntarily downloading and running it, at which point it delivers its malicious payload. This differs from a virus, which typically self-replicates and spreads by attaching itself to other legitimate files or programs, propagating without necessarily needing to disguise itself as something the user actively wants to install — the deceptive packaging is the defining feature of a Trojan, while self-replication and propagation through infected files is more characteristic of a virus. Treating the two as interchangeable ignores this meaningful distinction in how each type of malware operates and spreads. This scenario is not necessarily ransomware — while a Trojan could be used to deliver ransomware as its payload, a Trojan is defined by its deceptive delivery mechanism, not by any single specific payload type, and not every Trojan delivers ransomware specifically. A Trojan is a category of malicious software, not a network firewall configuration weakness — firewalls are a defensive control that can help prevent certain malware delivery methods, not the malware itself.

Answer: B. This represents multi-factor authentication (MFA) — requiring an additional, independent authentication factor (here, a one-time code from a separate authenticator app) beyond just a password, which is generally considered significantly more effective than a password alone because a compromised password (obtained through phishing, a data breach elsewhere, or other means) is, by itself, insufficient for an attacker to gain access, since they would also need to obtain the second, independent factor, which is typically much harder to compromise simultaneously with the password, particularly if that second factor requires physical possession of a specific device. This is fundamentally a preventive access control, not exclusively a physical control category — while it may involve a physical device (the authenticator app running on a phone), its classification and function relate to authentication and access control, a broader category than physical controls specifically. It functions primarily as a preventive control, operating before access is granted to stop unauthorised access, not as a purely detective control identifying issues only after an incident has occurred. MFA is widely and consistently recognised as providing substantial additional security benefit compared with password-only authentication, directly contradicting a claim of no meaningful benefit — this is one of the most well-evidenced and commonly recommended cybersecurity controls in practice.

Answer: C. This scenario illustrates supply chain or third-party cyber risk — an organisation's own strong internal cybersecurity can be significantly undermined if it grants privileged access to a third party (such as a software vendor for maintenance purposes) whose own security practices are not subject to similarly rigorous scrutiny, since that third party effectively becomes an extension of the organisation's own attack surface, and a security weakness in the vendor's systems could provide an attacker with a route into the organisation's network via that trusted access. Extending due diligence to assess a prospective third party's security practices before granting access, along with ongoing monitoring and contractually specified security requirements throughout the relationship, can help close this gap rather than allowing third-party access to become an unscrutinised weak link. Claiming privileged third-party access has no bearing on the organisation's own cybersecurity exposure directly contradicts well-documented real-world incidents in which exactly this kind of third-party access has served as the entry point for significant breaches. While contractual terms are one relevant element of managing this risk, it is not exclusively a legal matter — genuine technical and security-focused practices (due diligence, monitoring, access restriction) are equally important and directly relevant to managing the risk. Third-party cyber risk is relevant to organisations of varying sizes that grant any external party privileged system access, not confined to very large organisations with extensive vendor networks specifically.

Answer: D. Information security is commonly structured around three core elements known by the acronym 'CIA': Confidentiality (ensuring information is not disclosed to or accessed by unauthorised individuals), Integrity (ensuring information is accurate, complete and has not been altered without authorisation), and Availability (ensuring information and systems remain accessible to authorised users when they are needed). Different types of cyber attack can be understood as primarily threatening one or more of these three elements — for example, a data breach primarily threatens confidentiality, unauthorised data manipulation threatens integrity, and a denial-of-service attack threatens availability. The CIA acronym in this context has no connection to cost, investment, audit, compliance, insurance or assurance concepts — it specifically and consistently refers to these three information security elements across cybersecurity literature and practice. All three elements are considered equally core and independently relevant to a complete understanding of information security, not merely confidentiality alone.

Answer: B. This scenario illustrates a genuine and important gap — even strong preventive controls cannot reduce the probability of a significant cyber incident to zero, given the inherent limitations of any control system and the evolving, adaptive nature of cyber threats, so having a documented, and ideally tested, incident response plan describing roles, communication protocols, containment steps and escalation procedures helps ensure a faster, more coordinated and more effective response if an incident does occur, reducing confusion, wasted time, and ultimately the eventual impact and cost of the incident compared with responding reactively with no pre-agreed plan in place. Claiming sufficiently strong preventive controls make any incident completely impossible ignores the well-recognised inherent limitations of any control system, discussed also in relation to broader internal control limitations, which apply equally to cybersecurity controls specifically. The entire value of incident response planning lies in having the plan prepared in advance of an incident, precisely so that the organisation is not trying to develop a coordinated response for the first time while already under the pressure of a live incident — describing advance planning as providing no benefit misunderstands its whole purpose. Incident response planning is a relevant preparedness practice for organisations of varying sizes with meaningful digital dependency, not confined to very large organisations with extensive dedicated cybersecurity teams, even though the specific scale and sophistication of the plan may reasonably differ by organisation size.

Answer: C. Technical controls — firewalls, antivirus software, intrusion detection systems — are primarily designed to address technical vulnerabilities and malicious traffic, but they are generally poorly suited to fully addressing attacks that specifically exploit human judgement and behaviour, such as phishing and other social engineering techniques, which rely on manipulating an individual into taking an action (clicking a link, revealing credentials, making an unauthorised payment) rather than exploiting a purely technical system weakness — regular security awareness training, helping staff recognise common social engineering tactics and know how to respond appropriately (such as verifying unusual requests through an independent channel), is an important complementary control specifically addressing this human dimension of cyber risk. Claiming staff behaviour has no bearing on cybersecurity exposure contradicts the well-documented reality that human error and successful social engineering remain among the most common routes for successful cyber attacks, even in organisations with strong technical controls. Technical controls alone, however strong, are not sufficient to fully prevent attacks specifically designed to bypass them by targeting human decision-making instead — this is precisely why awareness training addresses a genuinely different, complementary risk dimension. Security awareness training is a relevant and valuable control for organisations of varying sizes, not confined to those with dedicated, extensive training departments — even relatively simple, low-cost awareness initiatives can meaningfully reduce social engineering risk in smaller organisations.

Answer: B. This describes a man-in-the-middle attack — an attacker secretly positions themselves within a communication channel between two parties who believe they are communicating directly with each other, potentially reading or even altering the information exchanged without either party's knowledge or consent. Encryption of data in transit, particularly through secure, authenticated communication protocols, is a specific and important control against this type of attack, since properly implemented encryption makes intercepted data unreadable to the attacker without the correct decryption key, and can also help ensure that any attempted alteration of the data in transit is detectable, undermining the attack's core objective of covert interception or manipulation. This is not a denial-of-service attack, which aims to overwhelm a system to make it unavailable, a mechanically distinct objective and method from covertly intercepting an ongoing communication. It is not ransomware, a distinct malware category involving file encryption and extortion, unrelated to intercepting a live communication channel. It is also not pretexting, a social engineering technique involving fabricated identity to manipulate a human target, mechanically distinct from a technical interception of a communication channel between two other parties.

Answer: D. This describes a zero-day vulnerability — a previously unknown software vulnerability that is discovered and, in this case, actively exploited by attackers before the software vendor itself is aware of it, meaning there has been 'zero days' during which a patch could have been developed and applied. This is particularly challenging to defend against precisely because, by definition, no patch or official fix yet exists at the point it is first exploited, meaning organisations cannot rely on the patch management approach (discussed in relation to known vulnerabilities) as their primary defence, and must instead depend on broader, complementary defensive measures such as monitoring for unusual system behaviour that might indicate exploitation, network segmentation to limit potential damage, and rapid incident response capability, since prevention through patching alone is not available for a vulnerability that is not yet known or patched. This is fundamentally different from a known vulnerability, for which a patch may already be available — the entire distinguishing feature of a zero-day is the absence of an available fix at the time of exploitation. It is not a physical security weakness — zero-day vulnerabilities are specifically a software or systems security concept, unrelated to physical facility access. While zero-day vulnerabilities are indeed challenging, organisations are not without any means of mitigation — layered defensive measures beyond patching alone, as described, can still reduce the risk and impact of a zero-day exploitation attempt.

Answer: A. This describes whaling — a highly targeted form of phishing specifically aimed at senior executives or other high-value individuals within an organisation ('big fish', hence the term), using detailed research about the specific target to craft a highly personalised, convincing attack that is generally more sophisticated and harder to detect than a generic, mass-distributed phishing email sent indiscriminately to many recipients. This is not a denial-of-service attack, which aims to overwhelm system capacity to make a service unavailable, a mechanically distinct objective and method from a personalised, targeted email deception. It is not ransomware, a distinct malware category involving file encryption and extortion, unrelated to researching and targeting a specific individual with a deceptive email. It is also not a physical control weakness — whaling is conducted entirely through electronic communication and research, with no physical facility access control dimension involved.

Answer: B. Because many data protection regulatory regimes impose specific, often quite short, timeframes for notifying a regulator (and in some cases affected individuals) after becoming aware of a significant data breach, incident response plans need to explicitly incorporate awareness of these applicable notification deadlines and requirements as part of the planned response, since failing to notify within the required timeframe can itself trigger additional regulatory penalties or scrutiny, layered on top of whatever direct consequences the breach itself has already caused — meaning notification timing is not a peripheral afterthought but a genuine, time-critical element of incident response that needs to be planned for in advance. Claiming notification requirements have no bearing on incident response planning ignores this direct, well-established connection between regulatory notification obligations and how an incident response plan needs to be structured and executed under real time pressure. These notification requirements typically apply broadly across many industries and sectors that hold personal data subject to the relevant data protection regime, not confined to the technology sector specifically. Planning for notification requirements in advance, before any specific incident occurs, is precisely the value of incorporating this into the incident response plan — waiting until after an incident is already fully resolved to consider notification requirements would risk missing the notification deadline entirely, since regulatory notification is often required promptly after becoming aware of a breach, well before full resolution of the underlying incident.

Answer: B. This assumption illustrates a misunderstanding of the shared responsibility model widely used to describe how security responsibilities are typically divided in cloud computing arrangements — the cloud service provider is generally responsible for the security 'of' the cloud (the underlying physical infrastructure, network, and foundational platform security), while the customer organisation remains responsible for security 'in' the cloud, including how it configures access permissions, manages user identities, classifies and protects its own data, and secures the applications it builds or deploys on the platform — misconfiguration by the customer organisation itself remains a very common and significant source of cloud security incidents precisely because organisations sometimes mistakenly assume the provider has this covered entirely. Claiming the provider is entirely and solely responsible for every security aspect once migration occurs, with no residual customer responsibility, directly describes the misconception this scenario illustrates rather than an accurate description of how responsibility is actually shared. The reverse claim — that responsibility rests entirely with the customer with no provider responsibility at all — is equally inaccurate; the model is explicitly about shared, not exclusively one-sided, responsibility. The shared responsibility model is relevant to cloud customers of varying sizes, not confined to very large enterprise customers specifically — organisations of any size using cloud services need to understand which security responsibilities remain theirs.

Answer: B. This represents network segmentation — dividing a network into separate segments so that a compromise of one segment does not automatically grant access to other segments, meaning that if an attacker successfully breaches a less sensitive segment (such as guest Wi-Fi), segmentation limits their ability to then move laterally across the network to reach more sensitive segments (such as finance systems), containing the potential spread and impact of the compromise rather than allowing an attacker who has breached any single point to roam freely across the organisation's entire network. This is a technical network security control, not exclusively a physical control — while it involves network architecture design, its function and classification relate to technical containment of network-based threats, distinct from restricting physical access to tangible facilities. It is not an authorisation control, which concerns approval before a specific transaction or action, a different control mechanism entirely from network architecture design limiting lateral movement. Network segmentation is a well-established and widely recommended control specifically because it does meaningfully limit how far a successful attacker can move within a network — describing it as having no effect on lateral movement directly contradicts its well-documented, core containment function and purpose.

Answer: D. This describes credential stuffing — an attacker uses credentials leaked from a breach at one, entirely unrelated organisation and systematically attempts to use the same username/password combinations to gain access to accounts at other, different organisations, exploiting the common practice of individual users reusing the same password across multiple different services. Its success rate depends heavily on the extent of password reuse across services — if a given user has used a genuinely unique password for the organisation being targeted, the leaked credentials from the unrelated breach will simply not work there — meaning encouraging or technically enforcing unique passwords per service, alongside multi-factor authentication (which would still block access even if the correct password is successfully guessed or stuffed), are important complementary mitigating controls. This is not a denial-of-service attack — while it does involve automated repeated attempts, the objective is gaining unauthorised access through valid-looking credentials, not overwhelming system capacity to deny service to legitimate users, a different attack objective and mechanism. It is not ransomware, a distinct malware category involving file encryption and extortion, unrelated to attempting login with leaked credentials. It is also not SQL injection, which exploits database input validation weaknesses directly, a mechanically distinct technique from attempting valid-format login credentials through a standard authentication interface.

Answer: C. This practice violates the principle of least privilege — a foundational access management principle holding that individuals should be granted only the access genuinely necessary for their specific current role, rather than broad access exceeding what their role actually requires; granting unnecessarily broad administrative access increases the potential damage that could result if any given account is compromised, whether through external attack (a compromised broad-access account gives an attacker far more reach than a narrowly scoped one) or insider misuse, and unnecessarily expands the organisation's overall attack surface by creating more high-privilege accounts than are functionally needed. Claiming broad default access is the most efficient, lowest-risk approach inverts the standard security analysis — efficiency in initial access provisioning does not offset the significantly increased risk exposure that unnecessarily broad access creates. Maximising every employee's access rights is not inherently more secure — quite the opposite, it is a widely recognised security anti-pattern that increases risk rather than reducing it. The principle of least privilege is relevant to organisations of varying sizes and role structures, not confined to very large organisations with especially complex structures — even simpler, smaller organisations benefit from restricting access to what each role genuinely needs rather than granting broad access by default.

Answer: D. Cyber insurance is a risk transfer mechanism (in TARA terms) that helps cover some of the financial consequences of a cyber incident once it has occurred — such as incident response costs, certain legal liabilities, and business interruption losses — but it does not itself prevent the incident from happening in the first place, nor does it fully address non-financial consequences such as operational disruption while systems are restored, or reputational damage and loss of customer trust that can persist well beyond any insurance payout; strong preventive controls (the kinds of technical and procedural measures discussed throughout this risk area) remain necessary to reduce the likelihood and severity of incidents occurring at all, with insurance serving as a financial backstop for the risk that remains even after reasonable prevention efforts, rather than a substitute for those prevention efforts. Claiming cyber insurance eliminates the need for preventive controls entirely misunderstands its role as addressing financial consequences after the fact, not reducing the likelihood of an incident occurring in the first place — indeed, many insurers now require evidence of adequate preventive controls as a condition of coverage, reflecting this complementary rather than substitutive relationship. Cyber insurance (risk transfer) and preventive controls (risk reduction) are genuinely distinct risk management approaches within the broader TARA framework, not interchangeable terms for the same thing. While insurance claims processes can be complex and some claims may be disputed or only partially paid, cyber insurance has provided genuine, well-documented financial value to many organisations following significant incidents, contradicting a blanket claim that insurers never pay out under any circumstances.

Answer: D. Addressing security only after core functionality has already been fully built risks costly, less effective retrofitted security — by that stage, security vulnerabilities may already be deeply embedded in fundamental architectural and design choices that would need substantial rework to properly address, making fixes more expensive, more disruptive, and often less thorough than if security requirements had been considered as an integral part of the design process from the very outset. 'Security by design' is a widely recommended alternative approach, embedding security considerations into every stage of development from initial design onward, rather than treating security as a separate, later add-on step — the underlying principle being that it is generally easier, more effective and less costly to build security in from the start than to retrofit it onto an already-completed design. Claiming development sequencing has no bearing on eventual product security ignores the well-documented, generally higher cost and lower effectiveness of retrofitted security compared with security by design. Security is not inherently incompatible with genuine core functionality — well-designed security by design integrates with functional requirements rather than working against them. Retrofitting security after the fact is not generally faster or cheaper — the opposite is typically true precisely because of the deeply embedded nature of vulnerabilities that must then be addressed within an already-fixed design.

Answer: B. This describes a watering hole attack — named by analogy to a predator waiting at a watering hole frequented by its prey, this technique involves compromising a third-party website known to be frequented by the intended target group, rather than attacking the target organisation's own systems directly, exploiting the trust employees place in a familiar, regularly visited site that they would not treat with the same suspicion as an unfamiliar or obviously unsolicited communication. This is not a denial-of-service attack, which aims to overwhelm system capacity to deny availability, a fundamentally different objective from covertly infecting visitors to a compromised third-party site. It is not ransomware, a distinct malware category and objective (file encryption and extortion) unrelated to the watering hole delivery mechanism itself. While SQL injection could potentially be one technique used to actually compromise the third-party website in the first place, a watering hole attack is defined by its overall strategic approach — targeting a frequented third-party site rather than the target directly — not by any single specific compromise technique, and it is not automatically or exclusively classified as SQL injection regardless of the actual method used.

Answer: A. This describes a tabletop exercise — a simulated, discussion-based walkthrough of how key personnel would respond to a hypothetical but realistic incident scenario, without any actual systems being affected, providing genuine value beyond simply having a written incident response plan by testing whether key personnel actually understand their specific roles and can coordinate effectively when talked through simulated incident conditions, often revealing gaps, ambiguities, or unrealistic assumptions in the written plan that would not become apparent simply from reading the document on paper, since a written plan can look complete while still leaving important practical questions unaddressed until people actually try to apply it to a realistic scenario. This is distinct from penetration testing, which involves an authorised third party actually attempting technical exploitation of real systems, a different activity and purpose from a discussion-based tabletop walkthrough that does not involve any actual technical exploitation attempt. A written plan alone, however well drafted, cannot guarantee that personnel will apply it effectively and coherently under actual pressure — this is precisely the gap tabletop exercises are designed to test and address before a genuine incident occurs. A tabletop exercise is explicitly a simulation with no actual systems affected, fundamentally different from, and much lower-consequence than, a genuine live cyber incident actually affecting real organisational systems and data.

Answer: A. Cyber threats continue to evolve and adapt over time, as attackers develop new techniques, exploit newly discovered vulnerabilities, and adjust their approaches partly in direct response to widely deployed defensive measures — meaning cybersecurity defences designed around historical attack techniques can become progressively less effective against newer, evolved techniques that those historical defences were never designed to address, requiring ongoing review, monitoring of the threat landscape, and updating of defensive approaches as an ongoing discipline, rather than a one-time implementation that can simply be treated as permanently sufficient once established. Claiming cybersecurity defences remain permanently and fully effective against every future technique, regardless of how attacker methods evolve, ignores this well-documented, continuously evolving and adaptive nature of the cyber threat landscape. Attacker techniques are demonstrably not static — the continuous emergence of new malware variants, attack techniques, and exploitation methods over time directly contradicts a claim of unchanging attacker behaviour. This need for ongoing defensive review and adaptation is relevant to organisations of varying sizes with meaningful digital exposure, not confined to very large, specifically and repeatedly targeted organisations — even smaller organisations facing lower overall targeted attack volumes remain exposed to the general evolution of prevalent attack techniques and should adapt their defences accordingly over time.

Answer: C. This describes vishing (voice phishing) — a social engineering technique conducted via telephone or voice call, rather than email, exploiting the pressure and immediacy of a real-time verbal conversation, where the target may feel less time to pause and verify the caller's claimed identity than they might with a written email they could examine more carefully at their own pace, making vishing a genuinely distinct channel and technique from email-based phishing even though both rely on the same underlying social engineering principles of manipulating human trust and urgency. This is not SQL injection, which exploits database input validation weaknesses through a technical interface, mechanically unrelated to a verbal telephone deception targeting a human individual. It is not a denial-of-service attack, which aims to overwhelm system capacity to deny availability, a fundamentally different mechanism and objective from a targeted voice-based social engineering attempt to obtain a specific authentication code. It is also not ransomware, a distinct malware category involving file encryption and extortion, unrelated to a voice-based request for an authentication code.

Answer: A. Expected annual loss is calculated by multiplying the annual probability of the event by its average cost if it occurs: 0.08 x £2,500,000 = £200,000. This figure gives the board a basis for judging how much annual investment in cybersecurity controls or insurance might reasonably be justified in expected-value terms. £2,500,000 simply restates the cost of a breach on its own, as if a breach were certain to occur every year. £312,500 would result from dividing the cost by the probability rather than multiplying by it. £20,000 would result from using 0.8% instead of the correct 8% probability, a misplaced decimal point.

Answer: A. The expected annual loss is 0.05 x £4,000,000 = £200,000, which exceeds the £150,000 annual insurance premium by £50,000. On a purely expected-value basis this suggests the insurance may be worthwhile, though the real decision should also weigh the policy's exclusions, excesses and the fact that insurance transfers financial consequences without preventing the incident itself or its operational and reputational impact. £200,000 is the expected annual loss on its own, without comparing it to the premium. £150,000 is simply the premium itself, not the difference between the two figures. £3,850,000 would result from an unrelated calculation that does not correctly apply either the probability or the comparison the question asks for.

Answer: A. The expected loss reduction from MFA is the difference between expected loss without it and expected loss with it: (0.12 x £600,000) - (0.01 x £600,000) = £72,000 - £6,000 = £66,000. Since this reduction (£66,000) comfortably exceeds the £10,000 annual cost of implementing MFA, the control is strongly cost-justified on expected-value grounds. £72,000 is only the expected loss without MFA, not the reduction achieved by implementing it. £6,000 is only the expected loss with MFA in place, not the amount of reduction achieved. £56,000 would result from incorrectly deducting the £10,000 MFA cost from the reduction figure, which conflates the benefit calculation with a separate net-benefit calculation not asked for here.

Answer: A. Using simple expected value, the expected number of services compromised is the number of services multiplied by the probability of compromise per service: 4 x 0.05 = 0.2. This illustrates, at a basic level, why password reuse across multiple services increases overall exposure compared with a single, unique password per service, since each additional reused instance adds to the expected exposure. 4 simply restates the number of services on its own, without applying the probability. 5 does not correspond to a correctly applied step of the calculation. 0.05 simply restates the per-service probability, without multiplying by the number of services over which the password is reused.

Answer: A. The estimated revenue lost is the number of hours the site was offline multiplied by the average revenue generated per hour while operating normally: 6 x £45,000 = £270,000. This figure represents only the direct revenue impact of the outage and would typically be considered alongside other costs, such as reputational damage or customer attrition, when assessing the full cost of the attack. £45,000 simply restates the hourly revenue figure on its own, as if the outage lasted only one hour. £51,000 would result from incorrectly adding the hours to the hourly rate (6 + 45,000, an invalid combination) rather than multiplying them. £7,500 would result from dividing the hourly revenue by the number of hours rather than multiplying.