Hard Difficulty Questions

Availability of project management software

Why it fails: Not a methodology selection factor.

Programming language preferences

Why it fails: Not a primary factor.

Implementing IT security controls

Why it fails: Implementing IT security controls is an operational task performed by IT and security teams under management direction. Boards set risk appetite, approve strategy and oversee assurance. It tempts because directors are accountable for governance outcomes, but accountability means oversight of control frameworks, not hands-on configuration or deployment of the controls themselves.

Monitoring daily IT operations

Why it fails: Monitoring daily IT operations is management's execution responsibility, delegated to IT staff; boards provide oversight, not operational supervision. It tempts because boards do monitor governance metrics and risk reporting, but that is periodic assurance at a strategic level, not day-to-day operational monitoring of systems and incidents.

Confirm that the backup window and retention schedule align with the recovery point objective.

Why it fails: Aligning backup frequency and retention with the recovery point objective addresses how much data loss is acceptable, which is a design question. It does not confirm that any given backup can actually be restored. An organization can have a perfectly aligned schedule and still fail to recover because of unreadable media or missing decryption keys. This is a planning review, not a restoration test.

Review the backup job logs to confirm that all scheduled jobs completed without errors.

Why it fails: Job logs confirm that the backup software wrote data without reporting errors, but they do not prove the data can be read back or that the application can be recovered. Media degradation, encryption key loss, or application-level inconsistency can all leave a successful job log while rendering restoration impossible. Reviewing logs is a useful completeness check but falls short of validating restorability, which is the specific objective in this scenario.

Verify that backup tapes are stored in a secure offsite location with environmental controls.

Why it fails: Secure offsite storage protects media from loss and damage, and is an important element of backup strategy, but it says nothing about whether the data on the media can be restored. A tape can be perfectly preserved and still be unreadable due to format changes, expired encryption certificates, or corrupted content. Physical protection addresses availability of media, not the recoverability of the application.

The control is ineffective because any deviation, regardless of cause, invalidates the entire control

Why it fails: Not every deviation renders a control ineffective. The auditor must evaluate the nature, cause, and effect of the exceptions and consider whether they represent a systematic failure or an isolated lapse. Concluding ineffectiveness without that evaluation overstates the finding and may not reflect the actual risk.

The control is operating effectively because the reviews were performed as scheduled

Why it fails: Performing the review is only part of the control. The control's purpose is to detect and resolve inappropriate privileged activity, so the absence of documented follow-up for identified anomalies means the control did not achieve its objective on those occasions, and effectiveness cannot be concluded from the review activity alone.

The control should be retested with a larger sample to determine whether the exceptions are isolated

Why it fails: Extending testing may be useful, but it is not the immediate and most appropriate action. The auditor already has evidence of deviations and should first understand their cause and effect; only then can the auditor decide whether additional testing would add value or whether the finding is already supportable.

The ACL denies TCP traffic to port 443

Why it fails: The ACL permits TCP to any destination on port 443.

The DNS server at 10.2.2.10 is unreachable

Why it fails: The ACL permits UDP to 10.2.2.10 port 53, so if that server is reachable, DNS should work.

The OUTSIDE interface has no security-level configured correctly

Why it fails: Security-level 0 is standard for outside interfaces.

Verify that the ERP system's database backups complete successfully each night.

Why it fails: Backup success is an availability and recovery control. It ensures data can be restored after loss or corruption but has no relationship to whether users hold conflicting access rights. SoD effectiveness is evaluated by examining role assignments, rulesets, and provisioning outcomes. Backup verification would be relevant to a different audit objective and does not test the segregation control described in the scenario.

Confirm that the ERP system's password policy enforces complexity and expiration requirements.

Why it fails: Password complexity and expiration strengthen authentication but do not address whether a single user can perform incompatible duties. SoD is about the combination of privileges assigned to an identity, not about credential strength. A user with a strong password can still hold conflicting roles. This procedure tests a different control area and would not provide evidence about the effectiveness of ongoing segregation of duties enforcement.

Interview the ERP administrator to confirm that SoD conflicts are taken seriously.

Why it fails: An interview provides management's perspective and can reveal tone and awareness, but it is not sufficient evidence of operating effectiveness. Administrators may believe conflicts are handled properly while exceptions go undetected. Auditors need to inspect configuration and test actual user access to confirm the control works. Relying on assertions without corroborating evidence would leave the audit conclusion unsupported, especially for a high-risk control area like segregation of duties.

General

Why it fails: SMART requires Specific, so a general recommendation cannot be actioned or measured against a defined target. It is tempting because broad statements feel safe and cover many concerns, but generality is precisely what SMART criteria exclude; a specific recommendation naming the system, control gap and owner would satisfy the framework.

Subjective

Why it fails: SMART demands Measurable and objective criteria, so a subjective recommendation cannot be verified or tracked. It appeals because stakeholder opinion often drives audit findings, yet subjectivity defeats the purpose; an objectively measurable recommendation with defined metrics would meet the SMART requirement instead.

Immediately delete all any-to-any rules without review

Why it fails: Deleting rules outright risks outage by removing traffic that may be legitimately required; each rule needs business justification and impact analysis first. Immediate deletion suits only confirmed malicious or unused rules. The recommendation should be review, then restrict or remove with change control.

Increase logging for any-to-any rules to detect misuse

Why it fails: Logging only records traffic; it neither restricts the excessive any-to-any access nor remediates the finding. The auditor should recommend tightening or removing the permissive rules. Enhanced logging is appropriate as a compensating detective control while remediation is pending, not as the primary action.

Encrypting all data at rest and in transit

Why it fails: Encryption protects data confidentiality but does not identify sensitive content or prevent its exfiltration, so it cannot enforce DLP policy. It is tempting because encryption is a fundamental data protection control, and it would be correct for securing data at rest and in transit rather than for detecting and blocking unauthorised transfers.

Training all employees on data handling procedures

Why it fails: Employee training builds awareness but does not itself detect or block sensitive data flows, so it cannot satisfy the technical enforcement requirement. It is tempting because awareness reduces accidental leakage, and it would be correct as a complementary control once classification, monitoring and policy enforcement are already in place.

Default DocumentRoot path is used

Why it fails: A default DocumentRoot exposes only the standard web root directory; it does not by itself grant write access, execute uploads, or leak configuration. It is tempting because non-standard paths are sometimes recommended for hardening, and would be the correct choice if the review required relocating content away from a predictable, well-known filesystem location.

AllowOverride All allows .htaccess overrides

Why it fails: AllowOverride All lets .htaccess files alter server behaviour, but exploitation requires an attacker to already write files into the web tree; it is not the direct exposure. It is tempting because .htaccess overrides are a recognised hardening concern, and would be correct if the finding were unauthorised per-directory configuration changes.

Require all granted permits all access

Why it fails: Require all granted permits access to the directory but does not itself expose sensitive files or enable code execution; the critical issue lies in what that directory contains or how it is served. It is tempting because broad access directives are a common audit finding, and would be correct if the requirement were restricting access to an administrative path.

The vendor releases quarterly patches but the organization only applies critical security patches.

Why it fails: Deferring non-critical patches leaves known flaws un-remediated in a heavily customised ERP, so patch currency is the weakness. It is tempting because risk-based patching is defensible for standard software, and would be correct where vendor patches carry no functional or regression impact.

Customizations are not tracked in a separate change management system.

Why it fails: Untracked customisations escape the change management process, so their configuration baseline and authorisation cannot be verified. It is tempting because vendor-delivered code is tracked by the vendor, and a separate system would be correct where customisations are numerous and independently deployed.

The organization does not have a formal testing environment for customizations.

Why it fails: Testing customisations directly in production risks corrupting live ERP data and invalidating change verification. It is tempting because small organisations often lack dedicated environments, and a formal test environment would be the right control where customisation volume justifies the cost.

Customer

Why it fails: Exceeds target, so no deficit.

Financial

Why it fails: 10% below target, but not the largest gap.

Internal Process

Why it fails: 4% below target, smaller than Learning & Growth.

Risk mitigation plans are not documented

Why it fails: While important, the identification of risks is foundational.

The project uses a combination of waterfall and prototyping

Why it fails: This is typical of the spiral model.

Risk analysis is performed by the project manager alone

Why it fails: While not best practice, it is less critical than failing to reassess risks.

Request additional budget from senior management

Why it fails: Requesting more budget treats the symptom; the cost performance index of 0.83 shows spending is outpacing earned value, so the variance needs root-cause analysis before any funding request. It would be appropriate only once analysis confirms the overrun is unavoidable and justified.

Reduce the project scope to align with the budget

Why it fails: Cutting scope changes the agreed deliverable and bypasses change control, and the schedule performance index of 0.91 shows the project is also behind plan. It is tempting as a quick cost fix, but scope reduction is a formal change decision, not a project manager's unilateral corrective action.

Crash the project schedule to make up for lost time

Why it fails: Crashing adds cost and resources to compress the schedule, yet the stem shows a cost overrun (CPI 0.83), not a schedule slip; the priority is cost control. Crashing suits a project that is behind schedule while still within budget, where duration must be reduced regardless of added expense.

Regular background checks on provider employees

Why it fails: Background checks address personnel integrity and confidentiality risk, not whether the help desk resolves incidents within agreed service levels. They tempt because vetting sounds like strong due diligence, and they would be the correct choice where the concern is insider threat or data protection rather than service quality measurement.

Access to provider's incident management system

Why it fails: Read access to the provider's incident system gives visibility of tickets but no contractual obligation or independent verification of resolution quality. It tempts because live data feels authoritative, and it would be the correct choice when the organisation needs operational oversight of individual incidents rather than assurance of overall service performance.

Monthly meetings with provider management

Why it fails: Meetings discuss performance but generate no measurable evidence of service quality; service level agreements with defined metrics and reporting provide the enforceable control. Meetings tempt because governance contact feels reassuring, and they would be the right choice for relationship management or escalation, not for verifying service delivery.

Penalties for non-performance

Why it fails: Penalties for non-performance enforce remedies after a breach of agreed terms; they grant no right to examine the vendor's controls, logs or evidence, which is what auditability demands. It tempts because penalties appear to strengthen accountability, and it would be correct where the concern is contractual compliance rather than independent verification.

Service level agreements (SLAs) for system uptime

Why it fails: Uptime SLAs define availability targets and credits, not the auditor's right to inspect records, processes and controls; auditability needs a right-to-audit clause. It tempts because availability is measurable and contractual, and it would be correct where the requirement is service performance assurance rather than examination of the vendor's environment.

Data ownership and confidentiality provisions

Why it fails: Ownership and confidentiality protect data rights, not the auditor's ability to inspect vendor records, systems and controls; auditability requires a right-to-audit clause. It tempts because confidentiality is a standard contract concern, and it would be correct where the risk is unauthorised disclosure rather than unverifiable processing.

Backup compression

Why it fails: Backup compression reduces data volume for storage and transfer but applies no cryptographic transformation, so it cannot demonstrate encryption of offsite backups. Compression suits capacity and bandwidth optimisation where confidentiality is handled by a separate mechanism.

Offsite transport log

Why it fails: An offsite transport log records chain of custody and movement of media, not whether the backup data itself was encrypted before leaving the site. Transport logs suit verifying physical handling and delivery of tapes to the offsite facility.

Backup verification logs

Why it fails: Backup verification logs evidence that restore tests succeeded, confirming data integrity and recoverability rather than encryption of offsite copies. Verification logs suit proving backups are readable and complete, which is a separate control from confidentiality.

Deploying an intrusion detection system to identify breaches sooner

Why it fails: Detection addresses the breach going unnoticed, but the vulnerability was already identified and wrongly deprioritised, so the governance failure lies in risk assessment and escalation against the board's risk appetite. It tempts because IDS genuinely shortens dwell time where breaches go undetected.

Disciplining the IT operations team for not escalating the vulnerability

Why it fails: Disciplining the team treats a symptom; the root cause is that no mechanism reconciled the team's low-risk rating with the board-approved risk appetite, so escalation criteria and oversight failed. It tempts because accountability for ignored findings is a legitimate control, but only where governance processes already exist.

Implementing a more robust patch management system with automated patching

Why it fails: Automated patching does not address the governance failure: the vulnerability was known and consciously deprioritised against the board's risk appetite, so the gap is risk escalation and oversight, not patch deployment speed. It tempts because automation genuinely reduces unpatched exposure where remediation backlogs stem from manual effort.

Reduce IT costs further to reallocate savings to customer service.

Why it fails: Cutting costs further attacks the financial perspective, which the scorecard already reports as within budget, leaving the engagement and satisfaction deficits untouched. It is tempting because savings could theoretically fund service improvements, yet the stem identifies low employee engagement as the causal learning-and-growth weakness that must be addressed first.

Increase the IT budget to hire more staff.

Why it fails: Hiring more staff addresses headcount, not the low engagement driving declining satisfaction; budget is already within plan, so extra funding targets no measured gap. It is tempting because the learning and growth perspective can involve workforce capacity, but that perspective is corrected through training, development and engagement initiatives rather than simply adding personnel.

Outsource customer-facing IT support to a third party.

Why it fails: Outsourcing customer-facing support removes internal capability without remedying the low employee engagement that the learning and growth perspective identifies as the root cause of declining satisfaction. It is tempting when service delivery skills are genuinely absent, but here the deficiency lies in workforce engagement, so external transfer would not resolve the measured gap.

The policy grants access to all objects in the bucket

Why it fails: This is the intended effect; it does not inherently create a security issue.

The policy allows access from any IP in the 10.0.0.0/8 range

Why it fails: While broad, this is a CIDR that may be intended for internal use; not necessarily a security concern if properly managed.

The condition uses a private IP range which is not routable from the internet

Why it fails: This is a functional constraint, not a security concern; it restricts access to internal networks.