Select Two (Multi-Select) Questions

The cost of the breach to the organization.

Why it fails: Root cause analysis examines how the breach occurred and which controls failed; financial cost is a business impact metric quantified separately for risk and budget reporting. Cost analysis would be correct when assessing breach impact, not when determining causation.

The specific employee who clicked the phishing email.

Why it fails: Root cause analysis targets systemic control failures, process gaps and technical vulnerabilities; singling out the employee who clicked the email assigns blame rather than identifying why the phishing control failed. Individual attribution suits disciplinary investigation, not causal analysis.

Immediately issue a press release without consulting legal.

Why it fails: Issuing a press release without legal consultation could lead to inaccurate statements, liability issues, and violation of confidentiality. The correct procedure is to consult legal and public relations before any public disclosure.

Ignore the incident if no customers have complained.

Why it fails: Ignoring an incident is unacceptable. Even without customer complaints, the organization must investigate and respond appropriately to mitigate risks and comply with legal requirements.

Delete all system logs to prevent further exposure.

Why it fails: Deleting logs destroys evidence and violates preservation requirements. Logs are crucial for forensic analysis and legal proceedings.

Monitoring and review

Why it fails: Monitoring occurs in Check/Act phases.

Implementation of controls

Why it fails: Implementation is part of the Do phase.

A template for incident notifications

Why it fails: A notification template governs stakeholder communication, not the collection, labelling or retention of forensic artefacts. It is tempting because notifications are a standard incident response plan element, but they belong to the communications phase, whereas evidence handling requires documented custody and preservation procedures.

Contact information for law enforcement

Why it fails: Law enforcement contacts support escalation and reporting, not the preservation, chain-of-custody or forensic imaging that evidence handling demands. It is tempting because engaging authorities is a valid step for criminal incidents, but the stem asks for components ensuring evidence integrity, which this does not provide.

A list of acceptable forensic tools

Why it fails: A list of acceptable forensic tools names permitted software but does not itself specify how evidence is collected, preserved or documented. It is tempting because tooling feels central to forensics, and it would be correct when the plan must constrain which utilities analysts may run during evidence acquisition.

The incident involves a new type of malware not seen before

Why it fails: Novel malware is handled through existing incident response and containment procedures; unfamiliarity alone does not exceed the security team's capability. It tempts because unknown threats feel severe, but CMT escalation criteria hinge on business impact, cross-functional coordination and reputational or regulatory consequences.

The incident originated from a third-party supplier

Why it fails: Origin from a third-party supplier is not itself an escalation trigger; supplier incidents are managed through vendor risk and contract processes. Escalation to the CMT depends on impact severity, scope and business disruption. This criterion would be tempting where supplier due diligence or contractual remediation is required, but that is a procurement concern, not crisis management.

The incident requires coordination with multiple external vendors

Why it fails: Vendor coordination is routine operational activity managed by the incident response team within existing contracts and contacts. It tempts because multiple parties suggest complexity, but CMT escalation depends on enterprise-wide business impact, strategic decisions or resource authority beyond the incident team's remit.

An incident response plan that defines roles and procedures.

Why it fails: Incident response is operational, not governance.

A vulnerability scanning schedule and remediation SLAs.

Why it fails: This is a technical control, not a governance element.

A firewall policy that specifies allowed and denied traffic.

Why it fails: Firewall policy is a technical control, not governance.

Vulnerability scanning

Why it fails: Vulnerability scanning is a proactive assessment activity, typically owned by a vulnerability management or assessment team, not a standing SOC component. It is tempting because SOC analysts consume scan findings during detection, and scanning would be correct when asked which activity feeds vulnerability data into risk reporting.

Security awareness training

Why it fails: Security awareness training educates the wider workforce and sits outside the SOC's monitoring, detection and response functions. It is tempting because it is a genuine security control, and would be the right answer when asked which programme reduces human-risk behaviour, rather than which components constitute the SOC.

Security budget as percentage of IT budget

Why it fails: Budget share measures resourcing, not employee beliefs or behaviour, so it does not reflect security culture. It is tempting because budget indicates management commitment, but culture metrics must capture attitudes, awareness, and reported behaviours rather than spending ratios.

Number of security policies published

Why it fails: Counting published policies measures documentation output, not whether staff understand or follow them, so it does not gauge culture. It is tempting because policies signal intent, but culture requires metrics on awareness, behaviour, and reporting rather than document volume.

Low disk space on a file server.

Why it fails: Low disk space is a capacity or housekeeping issue, not evidence of malicious activity such as unusual outbound traffic, privilege escalation or unexpected file changes. It would be relevant to availability monitoring, but incident indicators require behaviour deviating from the established baseline.

A new version of a critical software released.

Why it fails: A vendor releasing a new software version is routine lifecycle news, not an observed event on the organisation's systems, so it cannot indicate compromise. It would be relevant to patch management planning. Incident indicators require suspicious activity within the environment, such as anomalous logins or malware alerts.

A successful login by an authorized user.

Why it fails: A successful login by an authorised user is expected activity and matches the normal baseline, so it signals nothing anomalous. It would matter only if correlated with impossible travel or unusual hours. Security incident indicators require events deviating from normal behaviour, such as failed logins or unexpected privilege use.

List of all employees' contact information

Why it fails: A full employee contact directory is an HR asset, not an incident response component; the plan needs an escalation and notification contact list for responders and stakeholders. It is tempting because reachability matters during incidents, and a complete directory would be the right artefact for general business continuity communications.

Annual budget for incident response tools

Why it fails: Budgeting is a financial planning activity, not a component of the incident response plan itself, which defines roles, phases, communication and procedures. It is tempting because tooling funding underpins response capability, and an annual budget line would be the correct choice in a security programme budget document.

Current technology architecture

Why it fails: Technology architecture is an operational concern, not governance.

The complete network diagram of the data center hosting the asset.

Why it fails: Network diagrams are architecture documentation referenced during assessment, not components of an individual risk entry. Embedding full diagrams makes the register unwieldy and duplicates information maintained elsewhere. The risk entry should instead reference the affected asset or process, leaving detailed topology in the configuration management or architecture repository where it is version controlled.

The specific antivirus product version deployed on affected endpoints.

Why it fails: Product version details belong in asset or configuration inventories, not in the risk register entry itself. A risk register captures the risk statement, its causes, likelihood, impact, and treatment. Recording a specific endpoint product version adds maintenance burden and becomes stale quickly, while contributing nothing to understanding or managing the underlying risk.

The names of every employee who has access to the affected system.

Why it fails: Full access lists are access management records, not risk register content. Including them would bloat the register with volatile data that changes constantly and is better maintained in identity and access management systems. The register should describe the risk and its treatment, not serve as a personnel or entitlement inventory for the affected system.

Vulnerability scanning

Why it fails: Vulnerability scanning identifies weaknesses on a schedule; a SOC's key components are the people, processes and platforms performing continuous monitoring, detection and response. It is tempting because scan output informs SOC triage, yet scanning is a vulnerability management activity, not a core SOC component.

Identity and access management

Why it fails: IAM governs who may access which resources, but a SOC's components are monitoring, detection, analysis and response functions such as SIEM, not access control. It is tempting because identity telemetry feeds SOC investigations, yet IAM itself is an operational security control owned outside the SOC.

Application security testing

Why it fails: Application security testing is a development-lifecycle control producing findings before deployment, whereas SOC components centre on continuous monitoring, detection and incident response. It is tempting because test results can feed threat intelligence, but testing is not a SOC function; it belongs to secure development and assurance.

The user's browser history.

Why it fails: Browser history records the user's own web activity, not artefacts left by the phishing message or the credential theft. It would be relevant when investigating browsing behaviour or a suspected malicious website visit, not for extracting sender, header or URL indicators.

The user's personal phone number.

Why it fails: A personal phone number is not an IOC from the phishing email or the credential compromise, and collecting it raises privacy concerns. It would matter only if the attacker used smishing or voice phishing as the initial vector, which the stem does not describe.

The company's public website.

Why it fails: The public website is the organisation's own externally hosted content and carries no evidence of the phishing message or stolen credentials. It would be examined during defacement or web-application compromise investigations, not for harvesting email-borne indicators.

Employee's years of service

Why it fails: Years of service does not predict phishing susceptibility; tenure is unrelated to whether an employee recognises a lure. It suits onboarding or role-based training assignment, not setting simulation frequency and difficulty, which should follow baseline click rates and risk exposure.

Number of security incidents in the past year

Why it fails: Lagging indicator; not used to design simulations.

Length of contract

Why it fails: Contract length reflects commercial commitment, not the risk a vendor introduces; tiering uses data sensitivity, system access, and business criticality. It tempts because long engagements imply dependency, yet a short contract for critical data access still warrants a high-risk tier.

Vendor's annual revenue

Why it fails: Annual revenue reflects the vendor's size, not the likelihood or impact of a breach affecting the organisation, so it cannot drive tiering. It is tempting because financial scale is a common procurement metric, and revenue would be relevant when assessing a vendor's financial stability or creditworthiness rather than its inherent risk exposure.

Vendor's geographic location

Why it fails: Geographic location alone does not indicate risk exposure; tiering depends on data sensitivity and access, service criticality, and security posture. It tempts because jurisdiction affects breach notification and privacy obligations, but location is a secondary factor, not a primary classification criterion.

Vendor risk assessment reports

Why it fails: Vendor risk assessments feed third-party risk management, not incident response planning. They are correct when evaluating supplier security posture, but an IR plan needs escalation contacts, roles, and containment and recovery procedures rather than procurement due-diligence artefacts.

Detailed network architecture diagrams

Why it fails: Network diagrams support preparation and impact assessment but are reference material, not an essential IR plan component. They belong in architecture documentation; an IR plan requires defined roles, communication paths, and phased procedures for detection, containment, eradication and recovery.

Playbook for ransomware incidents

Why it fails: A ransomware playbook is a valuable scenario-specific annex, but the question asks for essential components present in every IR plan. Playbooks are the right choice when building response runbooks for named threats; the core plan needs generic phases, roles and communication procedures.

Password expiration

Why it fails: Password expiration is a scheduled identity lifecycle event, not a security incident; it triggers helpdesk resets, not containment or forensics. Dedicated playbooks belong to incident types such as ransomware or insider threat, where response actions must be rehearsed. Expiration generates predictable, routine tickets that standard service procedures already cover.

Software update failure

Why it fails: Software update failure is routine patch management, handled through change and release processes rather than security incident playbooks. A dedicated playbook is warranted for incidents such as malware outbreaks or data breaches, which require containment, eradication and notification steps. Update failures lack the adversarial, forensic response actions playbooks exist to standardise.

Phishing simulation

Why it fails: Phishing simulations are authorised security-awareness tests, not incidents, so a response playbook would be triggered by routine training activity rather than an actual compromise. It is tempting because phishing is a genuine incident category, and a playbook would be correct for real reported phishing messages that users have received.

Too many technical staff

Why it fails: Incident management typically suffers from too few skilled technical staff, not too many; overstaffing is not a recognised challenge. Excess headcount is tempting because large teams appear costly, yet the real difficulty is scarce expertise and resource contention during major incidents.

Over-reliance on automation

Why it fails: Automation reduces manual toil, so over-reliance is a governance and skills risk rather than a routine incident-handling challenge. It becomes the answer when the stem asks about tooling dependency or loss of analyst judgement, not the standard difficulties of detection, triage, escalation and coordination.

Excessive documentation

Why it fails: Excessive documentation is not a standard incident management challenge; teams usually struggle with too little or poorly maintained documentation. It is tempting because bureaucracy is a familiar complaint, but the recognised issues are unclear roles, poor communication and inadequate post-incident review.

Adoption of cloud security tools

Why it fails: Tool adoption is not a program component; it's an implementation detail.

Single point of failure for security decisions

Why it fails: Mature programs distribute accountability.