Scenario practice questions

Automated unit testing results

Why it fails: Unit tests verify that individual code units behave as the developers intended; they do not confirm the system satisfies documented business requirements. They would be the right control for validating code correctness during construction, whereas waterfall demands formal requirements traceability and user acceptance testing before sign-off.

Code reviews by the development team

Why it fails: Code reviews check implementation quality, style and defects among developers; they cannot confirm the system meets documented business requirements. They are the right control for improving code correctness during development, whereas waterfall requires formal requirements traceability and user acceptance testing before the system is accepted.

Detailed technical design documents

Why it fails: Technical design documents describe how the system will be built, not whether it delivers the agreed business requirements. They are the correct artefact for guiding developers during construction, but waterfall's requirements phase needs traceability and user acceptance testing to confirm business needs are actually met.

Lack of customization

Why it fails: Custom builds exist precisely to deliver bespoke functionality, so lack of customisation is not the exposure; the real risk is the organisation owning development, maintenance and support burden. It tempts because vendor packages often constrain tailoring, making customisation a genuine buying criterion when requirements are unusual.

Dependence on external support

Why it fails: External support dependence arises from vendor-supplied software, not in-house development; the salient risk is instead skill scarcity, key-person dependency and long-term maintenance burden. Vendor dependence would be the correct emphasis had the organisation purchased a commercial product.

Vendor lock-in

Why it fails: Vendor lock-in arises from proprietary purchased platforms, not from in-house development, so it cannot be the risk here. It tempts because lock-in dominates buy-side analysis, and would be the correct emphasis if the organisation had selected a closed vendor product with proprietary data formats or APIs.

Regression testing

Why it fails: Regression testing re-runs existing cases to confirm prior functionality still works after change; it does not establish that new access controls enforce policy correctly. It is tempting because it guards against unintended breakage, and would be correct after a change to an already-verified identity system.

Unit testing

Why it fails: Unit testing exercises individual components in isolation, so it cannot verify that access rules behave correctly across the identity management system's integrated authentication and authorisation flows. It is tempting because granular checks catch coding defects early, and would be correct when validating a single module's logic before integration.

System integration testing

Why it fails: System integration testing confirms interfaces between components exchange data correctly, but does not validate that enforced access rules match policy across roles and resources. It is tempting because it exercises end-to-end data flows, and would be correct when the risk being tested is interface or messaging failure rather than authorisation logic.

The chief information security officer (CISO)

Why it fails: The CISO sets security strategy, policy and risk appetite across the organisation, but does not own individual data assets or decide their classification and access rules. Data ownership sits with the business function that creates and uses the data. The CISO role would be correct for approving the classification policy itself.

The system administrator of the database

Why it fails: A database system administrator operates and maintains the platform hosting the data, but holds no business accountability for its content, classification or authorised use. Ownership belongs to the business function generating the data. This role would be the correct choice for implementing technical access controls, not for owning data.

The legal counsel responsible for compliance

Why it fails: Legal counsel advises on regulatory obligations affecting data but does not own the asset or determine its business classification and access decisions. Ownership rests with the business function that creates and uses the data. Legal counsel would be the right role for interpreting compliance requirements, not for data ownership.

The hot standby site is located too far from the primary site.

Why it fails: Distance between sites is a design consideration, not a finding arising from the stale plan, untested recovery or new ERP system described. It is tempting because geographic separation protects against regional outages, but the stem's evidence concerns plan currency and testing, so this is unsupported by the audit observations.

The DR plan has not been reviewed and approved by senior management in the last year.

Why it fails: The stem already states the plan has not been updated in two years, so a separate finding about annual review merely restates that fact rather than identifying a distinct significant issue. It is tempting because management approval is genuinely important, but the auditor should report the underlying staleness and untested recovery instead.

Judgmental sampling

Why it fails: Judgmental sampling relies on the auditor's professional discretion to pick items based on risk or materiality, so it cannot explain a fixed interval selection. It is tempting because it suits targeted testing of high-value or suspicious transactions, but here the mechanical every-50th rule defines systematic sampling instead.

Random sampling

Why it fails: Selecting every 50th purchase order is systematic selection, which uses a fixed interval through the population; random sampling gives every item an equal chance via random number generation. Systematic sampling is tempting because the interval feels arbitrary, but the deterministic pattern is the defining difference.

Stratified sampling

Why it fails: Stratified sampling divides the population into distinct subgroups and samples from each; selecting every 50th item applies one fixed interval across the whole list without stratification. It is tempting because both are probability methods, but no subpopulation grouping occurs here, so the technique is systematic selection.

A Trojan horse disguised as legitimate software.

Why it fails: A valid vendor signature with malicious execution indicates the vendor's signing key or update channel was compromised, or the binary was trojanised — supply-chain compromise, not a Trojan posing as legitimate software. It is tempting because signed malware resembles a Trojan, but Trojans impersonate trusted software without genuine vendor signatures.

A zero-day exploit targeting an unpatched vulnerability.

Why it fails: A zero-day exploits an unpatched software vulnerability; here the file is validly signed and runs as intended, so no vulnerability is exploited. It is tempting because signed malware evades signature detection, but zero-day would be correct where an unknown flaw is exploited before a patch exists.

A fileless attack that never writes to disk.

Why it fails: The stem describes a validly signed executable that turns malicious at runtime, which is a signed-binary or trojanised-software threat. Fileless attacks execute in memory via scripting or LOLBins and typically leave no signed file on disk, so the trusted signature contradicts this. Fileless detection would be the answer if no file were written.

Improved service level performance

Why it fails: Improved service level performance is a benefit, not a risk, so it cannot be highlighted as a subcontracting exposure. It is tempting because subcontractors can add capacity and resilience, and performance gains would be a valid consideration when evaluating a provider's delivery model under a contract that already authorises and governs subcontracting.

Increased licensing costs

Why it fails: Licensing costs are a commercial matter unrelated to undisclosed subcontracting, which raises confidentiality, data residency, and auditability exposures. Increased licensing costs would be the correct concern when reviewing software entitlement terms or a vendor's pricing model, not when assessing unauthorised third-party access to stored data.

Implement automatic firmware updates to eliminate human error.

Why it fails: Automatic firmware updates bypass CAB review and emergency change procedures entirely, so an unreviewed faulty update could still halt production. It tempts as a way to remove human error, yet it would be correct only for low-risk, non-production devices where change control is not required.

Increase the frequency of CAB meetings to weekly to expedite change approvals.

Why it fails: Weekly CAB meetings address approval throughput, not the engineer's bypass of the emergency change process. The stem's control gap is unenforced emergency procedures, so the fix must mandate post-implementation review and detection of unapproved changes. More frequent CAB sessions are genuinely useful when routine change volume overwhelms scheduled review capacity.

Remove the network engineer's administrative access to all network devices.

Why it fails: Revoking all administrative access removes the engineer's ability to perform legitimate network changes, and the outage stemmed from bypassing the emergency change process, not from holding rights. It tempts as visible punishment, but it would be correct only if the engineer lacked a genuine operational need for that access.

Availability of modern integration middleware

Why it fails: Modern integration middleware is generally available, and its absence is not an inherent challenge of legacy integration; the difficulty lies in protocol and data-format mismatches. It is tempting because middleware eases connectivity, but legacy systems often cannot support it, making this a symptom rather than the challenge itself.

Need for custom development to bridge the gap

Why it fails: This is an action taken in response to challenges.

The organization may fail to detect an incident in a timely manner

Why it fails: Tabletop exercises test response procedures and decision-making, not detection capability; detection depends on monitoring, SIEM alerts and logging. The option is tempting because exercises do surface gaps in escalation and communication, but timely detection is addressed by tuning monitoring tools, not by rehearsing scenarios.

The organization may not comply with regulatory reporting requirements

Why it fails: Regulatory reporting is governed by legal obligations and notification workflows, which tabletop exercises only incidentally touch. The option tempts because exercises can reveal unclear reporting chains, yet compliance failures stem from absent policies or missed deadlines, not from a lack of scenario rehearsals.

The incident response plan may be outdated

Why it fails: An outdated plan is a documentation concern; the graver risk is that staff cannot execute the plan under pressure, leaving response capability unvalidated. It is tempting because plan currency is auditable, but it would be correct if the finding were that the plan had never been reviewed or updated.

Parallel test

Why it fails: A parallel test runs recovery systems at an alternate site alongside production, so it involves actual system activation. It is tempting because it validates real recovery capability, making it correct when the organisation wants assurance that backup systems function without disrupting live operations.

Walkthrough

Why it fails: A walkthrough is a discussion-based review of documentation and procedures, not a scenario-driven role-play of responses. It is tempting because walkthroughs do validate understanding of the plan, but they would be correct only when the objective is confirming procedural accuracy, not rehearsing participant roles against a simulated incident.

Simulation

Why it fails: A simulation is a scenario-based exercise, but the described discussion of roles without system activation is a tabletop exercise. It is tempting because simulation and tabletop overlap in discussion format, making simulation correct when participants practise responses using simulated system outputs.

The IR team may not have adequate forensic capabilities

Why it fails: Forensic capability is unaddressed by the finding; tabletop discussions test decision-making and coordination, not evidence acquisition tooling. This concern arises when incident investigations lack artefacts or chain-of-custody, whereas the stem's issue is that non-malware scenarios such as insider or availability events go unpractised.

The exercises are not conducted quarterly

Why it fails: Frequency is not the deficiency here; annual exercises can satisfy many frameworks, and the stem identifies scenario limitation, not scheduling. Quarterly cadence matters where regulations or risk assessments mandate it, but the auditor's concern should target the untested threat types rather than the interval itself.

The IR team is not following the defined procedures

Why it fails: Nothing in the stem indicates the team deviates from documented procedures; the finding concerns scenario coverage, not procedural adherence. Auditors raise this concern when evidence shows steps skipped or runbooks ignored during an actual incident, which is a separate control failure from narrow exercise scope.

Implement the change directly

Why it fails: The CAB authorises and schedules changes; it does not execute them. Direct implementation bypasses the change management process, removing the controlled handover to database administrators who perform the reboot. A CAB would implement directly only in a small organisation where the same staff both approve and carry out changes.

Reject the change as unnecessary

Why it fails: Rejecting the patch leaves a known vulnerability unaddressed, contradicting the low-impact risk assessment that supports proceeding. Rejection fits changes whose risk or business disruption outweighs their benefit, not a security patch requiring a brief reboot. The CAB's role is to authorise, not refuse.

Defer the change to the next release cycle

Why it fails: Deferring to the next release cycle delays a security patch that has already been risk-assessed as low impact, leaving the database exposed unnecessarily. Release-cycle batching suits non-urgent enhancements, not remediating known vulnerabilities, so the CAB should authorise the patch rather than postpone it.

The second rule blocks HTTPS traffic from any source to the host

Why it fails: Second rule blocks HTTPS from any source, but first rule already blocks all traffic from 10.0.1.0/24.

The third rule permits all traffic from the 10.0.0.0/16 subnet

Why it fails: The permit rule applies to a larger subnet, but the first rule is more specific and blocks the 10.0.1.0/24 range.

The firewall is misconfigured for TCP traffic

Why it fails: Configuration is explicit; no general misconfiguration.

Job failure alerts

Why it fails: Alerts only notify staff after the dependent job has already failed, so they detect rather than prevent the scheduling collision. Alerting is the right control when the goal is timely incident response to unexpected failures, but the stem asks for a control that stops the job launching before its prerequisite completes, which job dependency scheduling provides.

Manual job scheduling

Why it fails: Manual scheduling replaces automation with human sequencing, reintroducing the operator error and delay that automated schedulers exist to remove. It is tempting where jobs are few, irregular, or need judgement calls, but for recurring batch chains the reliable preventive control is defining predecessor dependencies so the scheduler holds the job until its prerequisite succeeds.

Rerun procedures

Why it fails: Rerun procedures only recover the job after it has failed, leaving the dependency conflict unresolved and wasting the failed run. Reruns are correct for transient faults such as timeouts or locked resources, but the stem's cause is deterministic sequencing, which dependency-based scheduling prevents rather than repairs after the fact.

Measuring the recovery time objective (RTO)

Why it fails: A tabletop measures decision-making and communication, not elapsed recovery time; RTO is quantified only by executing recovery and timing it. It is tempting because participants do discuss timelines, and a full or parallel recovery test would be the correct choice when the objective is measuring actual RTO.

Validating the technical recovery procedures

Why it fails: A tabletop exercise is a discussion-based walkthrough; participants talk through roles and decisions rather than executing recovery steps, so it cannot validate technical procedures. It is tempting because procedure review feels like validation, and a full technical recovery test would be the correct choice for confirming those procedures work.

Testing the actual restoration of systems

Why it fails: Restoring systems requires executing the actual recovery, which a discussion-based tabletop never performs; no systems are touched. It is tempting because testing restoration is genuinely valuable, and a parallel or full-interruption test would be the correct choice when the objective is verifying that systems can actually be recovered.

The project was completed 10% over budget.

Why it fails: Budget overrun is a cost-management concern, not a control weakness in the delivered payroll system; auditors focus on data integrity, segregation of duties and processing accuracy. Overspend is tempting because it signals weak project governance, and would concern the auditor during a project audit rather than a post-implementation review.

The vendor's implementation team was helpful.

Why it fails: A helpful vendor implementation team is a positive observation, not a control deficiency, so it raises no audit concern. Vendor cooperation is tempting because auditor independence and support matter during reviews, but the question asks which findings should concern the auditor, and this is favourable rather than adverse.

The system's response time is slower than expected.

Why it fails: Slower response time is a performance and user-satisfaction concern, not a control weakness affecting payroll accuracy, authorisation or data integrity. Performance tuning is tempting because post-implementation reviews do assess it, but auditors prioritise findings indicating control failure or material misstatement risk.

Review the encryption algorithm and key length used for the backup tapes.

Why it fails: Reviewing the algorithm and key length confirms only that data at rest on the tape is cryptographically protected; it says nothing about whether the physical containers were sealed, tracked, or delivered intact. An encrypted tape left unattended on a loading dock still represents a loss of custody, so this evidence does not address the transit protection objective the auditor is testing.

Interview the backup administrator about the tape pickup schedule.

Why it fails: An interview provides management's assertion about the process but is not corroborating evidence that protection actually occurred on any specific shipment. The auditor needs documentary or observational proof of the transit chain, not a verbal description of the intended schedule, which could be inaccurate or optimistic and would not withstand independent verification.

Examine the offsite storage vendor's SOC 2 report.

Why it fails: A SOC 2 report addresses controls at the storage facility after the tapes arrive, covering the receiving and vaulting environment. It does not evidence what happened during transport between the data center and the vendor, so it leaves the exact transit risk the auditor is evaluating unaddressed and cannot confirm that sealed containers stayed sealed en route.

Password policies may not be enforced

Why it fails: Password policy enforcement is a platform configuration control, not an outcome of HR-led provisioning. The missing approval process risks users receiving inappropriate entitlements or orphaned accounts, whereas password complexity and expiry are set in the system's authentication settings regardless of provisioning ownership.

User accounts may not be locked after multiple failed login attempts

Why it fails: Account lockout thresholds are configured within the application or identity platform's authentication settings, independent of who provisions users. The absence of approval workflow creates risks of excessive or unauthorised access rights, not failed-login lockout gaps, which would be the concern if authentication configuration were unmanaged.