Select Two (Multi-Select) Questions

Assumption

Why it fails: An assumption is an accepted premise without verification, not audit evidence; evidence must be sufficient, reliable and relevant, drawn from physical, documentary, testimonial or analytical sources. It is tempting because assumptions underpin audit scoping, and would be correct if the question concerned planning constraints rather than evidence types.

Conjecture

Why it fails: Conjecture is an opinion formed without sufficient proof, so it cannot constitute audit evidence; recognised types are physical, documentary, testimonial and analytical. It is tempting because auditors reason about possible causes during planning, and would be correct if the question asked about forming preliminary theories rather than evidence classification.

Hypothesis

Why it fails: A hypothesis is a proposed explanation awaiting testing, not evidence; IS audit evidence comprises physical, documentary, testimonial and analytical types. It is tempting because auditors do form hypotheses during enquiry, and would be correct if the question asked about an analytical technique used to direct testing rather than a category of evidence.

Availability of project management software

Why it fails: Not a methodology selection factor.

Programming language preferences

Why it fails: Not a primary factor.

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.

Immediate implementation without review

Why it fails: Change management requires assessment, approval and rollback planning before deployment; immediate implementation removes the review gate entirely, so no authorisation or risk evaluation occurs. It is tempting because emergency fixes feel urgent, yet even expedited changes still need retrospective approval and documentation under a formal change process.

Bypassing testing for urgent changes

Why it fails: Skipping testing removes the verification control that confirms a change works and introduces no regressions before production deployment. Urgency tempts teams to bypass it, but emergency changes still require testing, or documented compensating controls and post-implementation review, within the change process.

Update the disaster recovery plan

Why it fails: Disaster recovery plans are updated through change management and business continuity maintenance, not as a post-implementation review objective, which evaluates whether the system met its stated business case and requirements. It tempts because new systems alter recovery dependencies, but that update is a separate continuity activity.

Assess the project budget variance

Why it fails: Budget variance is examined during project closure and cost accounting, whereas a post-implementation review assesses whether the system delivered the intended business benefits and requirements. It tempts because both occur after go-live, but variance analysis addresses project financial control, not operational effectiveness of the delivered solution.

Evaluate vendor performance

Why it fails: Vendor performance is assessed through contract management and service-level reporting, not a post-implementation review, which examines whether the delivered system meets business requirements and whether benefits were realised. It tempts because procurement reviews do evaluate suppliers, but that occurs during vendor selection or contract renewal.

Generate test cases

Why it fails: Not a VCS feature.

Eliminate all bugs

Why it fails: Impossible.

Automate deployment

Why it fails: CI/CD tool.

Clear communication

Why it fails: Clear communication is a success factor that mitigates project risk, so it does not indicate impending failure. It is tempting because communication is repeatedly cited in project management guidance as critical. The question asks for failure indicators, such as unclear requirements, frequent scope changes or unresolved stakeholder conflicts, which are the inverse of clear communication.

Robust testing

Why it fails: Robust testing is a positive control that reduces delivery risk, not an indicator of failure, so it cannot signal an at-risk project. It is tempting because testing is genuinely central to project quality assurance. The question seeks warning signs such as scope creep, unrealistic schedules or unmanaged dependencies, where testing rigour is absent rather than present.

High team morale

Why it fails: High team morale is a healthy project attribute and evidence against failure risk, not a warning sign. It is tempting because morale is widely discussed in project literature as influencing outcomes. The question requires indicators such as staff turnover, missed milestones or escalating defects; sustained high morale contradicts those failure signals.

A list of all critical IT applications with their recovery priorities.

Why it fails: A prioritised application list is a recovery dependency input, not a BCP element covering business processes, people and facilities. It is tempting because application criticality drives recovery sequencing, and the list would be correct as part of the IT disaster recovery plan.

A complete inventory of hardware and software licenses.

Why it fails: Hardware and software licence inventories support asset and compliance management, not business resilience planning. It is tempting because recovery sites need licensed software, and the inventory would be correct for a software asset audit or licence true-up exercise.

Detailed step-by-step procedures for restoring network connectivity.

Why it fails: Network restoration procedures belong in the IT disaster recovery plan, which the BCP aligns with rather than duplicates. It is tempting because connectivity underpins recovery, and such procedures would be correct within the technical DR runbook executed by infrastructure teams.

Inquiry of management

Why it fails: Inquiry collects representations from management, which are assertions rather than the independent expectations analytical procedures compare against recorded amounts. It is tempting because inquiry is used throughout every audit, but it supports corroboration and risk assessment, not the substantive analytical comparison of financial data.

Inspection of documents

Why it fails: Inspecting documents verifies existence and authorisation of records; it yields no expectation against which fluctuations or ratios can be compared. It is tempting because inspection is a core audit evidence technique, yet analytical procedures demand the auditor to develop an independent expectation, which document inspection never produces.

Observation of process

Why it fails: Observation witnesses a process as it happens, producing direct evidence about performance, not the comparisons and ratio analyses that analytical procedures require. It is tempting because observation is a legitimate evidence-gathering technique, but it belongs to control testing and physical inspection, not to analytical review.

Using a host-based intrusion detection system (HIDS) on each VM.

Why it fails: A HIDS on each VM can detect malicious activity within the guest OS, but it does not directly prevent VM escape. If an attacker escapes the VM, they are operating at the hypervisor level, where the HIDS in the VM may not have visibility or control. HIDS is useful for detecting compromises, but it is not a primary mitigation for VM escape. The most effective controls target the hypervisor and the isolation between VMs.

Regularly backing up VM images to a separate storage system.

Why it fails: Backups are important for recovery, but they do not prevent VM escape. If an attacker escapes a VM, they could potentially access the hypervisor and other VMs, and backups would not stop that. Backups are a reactive control for data loss, not a preventive control for hypervisor compromise. While having backups is good practice, it is not an effective mitigation for the specific risk of VM escape.

Enabling promiscuous mode on the virtual switch to monitor all traffic.

Why it fails: Promiscuous mode on a virtual switch allows a VM to see all traffic on that switch, which can be a security risk because it could allow a compromised VM to sniff traffic from other VMs. It does not mitigate VM escape; in fact, it could aid an attacker in gathering information. Promiscuous mode is typically used for monitoring or IDS, but it should be used cautiously and not as a security control for VM escape.

Cost per incident

Why it fails: Cost per incident measures operational incident management expenditure, not disaster recovery test outcomes. A DR test report documents recovery time and recovery point achievements against objectives. Cost per incident would suit an incident management performance review, where financial impact of individual incidents is assessed.

Number of personnel involved

Why it fails: Personnel count is a resourcing input, not a recovery performance metric. A DR test report measures whether systems were restored within the recovery time objective and to the recovery point objective. Staffing numbers belong in resource planning or exercise participation records, not recovery capability evidence.

Network topology diagram

Why it fails: A network topology diagram is technical architecture documentation, not a governance component; governance comprises decision rights, steering committees, and performance measurement. It tempts because architecture artefacts inform risk and control discussions, but they describe infrastructure rather than who directs and oversees IT.

Help desk procedures

Why it fails: Help desk procedures are operational service-management documentation, not governance components, which comprise structures such as steering committees, decision rights, and strategic alignment processes. They tempt because ITIL-style process documentation supports service delivery, but governance concerns direction and oversight rather than day-to-day incident handling.

Hardware inventory

Why it fails: A hardware inventory is an asset-management record, not a governance component; governance frameworks comprise structures like executive steering committees, defined decision rights, and alignment processes. It tempts because asset registers underpin control and compliance activities, yet they document equipment rather than the direction and oversight of IT.

Data classification labels

Why it fails: Classification labels describe sensitivity but do not by themselves record what personal data exists, where it resides, or its retention. Labels are correct when driving handling and access rules, not as the inventory's core record of data elements and processing purposes.

Data retention periods

Why it fails: Retention periods are applied through a retention schedule derived from the inventory's classification and legal-hold data, so they are an output rather than a foundational element. Retention scheduling is the correct control when disposing of records under GDPR Article 5(1)(e) storage limitation.

Data subject consent status

Why it fails: Consent status is recorded per processing activity, not as a core inventory attribute; the inventory must first map data elements, flows and lawful basis. Consent tracking belongs in a consent management or preference store, and would be the right artefact when demonstrating GDPR Article 7 proof of consent.

Insufficient network bandwidth during cutover

Why it fails: Bandwidth shortfalls slow transfers and can be scheduled around or upgraded before cutover, so they rarely threaten data integrity or project viability. Bandwidth planning is genuinely important for large-volume migrations, but it is an operational performance concern rather than a highest-risk data migration failure.

Lack of user training on the new system

Why it fails: Training gaps degrade adoption and productivity after go-live, but they do not corrupt or lose the migrated records themselves. Training is a change-management concern, addressed by rollout and hypercare planning; it would be the priority in an end-user readiness assessment, not in a data migration risk ranking.

Lack of segregation of duties in the new system

Why it fails: Segregation of duties is an access-design control configured in the new ERP's roles, not a data migration risk. It matters during security design and post-implementation audit; migration risk instead centres on data completeness, accuracy and reconciliation between legacy and target records.

The encryption algorithm used to protect the data

Why it fails: Encryption algorithms are security controls applied to data, not inventory attributes; a privacy inventory records what personal data exists, its location, purpose and retention. It is tempting because encryption details matter for compliance evidence, but they belong in a control register rather than the data inventory itself.

The cost of storing the data

Why it fails: Storage cost is a financial metric, not a privacy attribute; an inventory must record what personal data is held, where, why and for how long. It is tempting because cost tracking is a legitimate FinOps concern, but it does not evidence lawful processing or support data subject requests.

The names of all employees who process the data

Why it fails: Naming every employee who processes data creates a personnel list, not a data inventory; the inventory records the data itself, its categories, location, purpose and retention. It is tempting because accountability matters under privacy rules, but access records belong in an access register, not the inventory.

Sampling interval

Why it fails: Sampling interval determines which items are selected, not how many; it is the spacing used in systematic selection. It becomes relevant only after sample size is fixed, when planning selection. Factors affecting size include population size, confidence level, tolerable error and expected error rate.

Population standard deviation

Why it fails: Standard deviation is a variable-sampling parameter used in monetary-unit or classical variables sampling to project misstatement amounts, not an attribute-sampling input. For attribute sampling, size derives from confidence level, tolerable deviation rate and expected deviation rate. The stem's generic audit sampling assumes attribute testing.

Increased complexity in password management

Why it fails: Password management complexity is an operational inconvenience, not a control failure. It tempts because shared credentials genuinely complicate rotation and distribution, but the significant risks are loss of individual accountability and non-repudiation, since activity cannot be traced to a specific administrator during incident response.

Increased overhead for account provisioning

Why it fails: Provisioning overhead is an administrative cost, not a security risk arising from lost accountability. It tempts because shared accounts do reduce the number of credentials to manage, but the significant risks are non-repudiation loss and inability to attribute actions to an individual during incident response.

Higher likelihood of password sharing outside the authorized group

Why it fails: While possible, the main risk is lack of accountability.

Completion of the initial risk assessment

Why it fails: Completing the initial risk assessment is a planned fieldwork input that shapes the audit programme before testing begins, not a trigger to change approach mid-fieldwork. It is tempting because risk assessment legitimately drives audit planning, and it would be correct when asked what determines the initial scope.

Audit team members are behind schedule

Why it fails: Team members falling behind schedule is a resourcing and project management issue, not evidence that the audit approach itself is misdirected. It is tempting because slippage often prompts reassessment, yet the correct triggers are findings such as control failures or new risks that invalidate the planned procedures.

Management requests a change in audit scope

Why it fails: A scope change alters what the audit must cover, which is handled by re-planning and revising the engagement terms, not by adjusting fieldwork technique. It is tempting because it does affect the audit, and would be correct when the objective itself shifts rather than evidence-gathering methods.