3.3 Scenario Practice for Governance and Management of IT
Key Takeaways
- Segregation of duties separates authorization, custody, recording, and reconciliation so no one person controls a whole transaction.
- When full segregation is impractical, compensating controls (supervisory review, reconciliation, audit logs, job rotation) reduce the residual risk.
- IT performance is monitored with KPIs and a balanced scorecard; IT risk is monitored with KRIs reported to governance.
- Outsourcing and cloud do not transfer accountability — the organization remains accountable and governs vendors through SLAs and right-to-audit clauses.
- Read scenarios as role → task → governing rule → cue → best action → expected output to choose between two plausible answers.
A Structured Way to Read the Stem
Domain 2 scenarios pair content knowledge with professional judgment, and the stem almost always contains the cue you need. Read every scenario as a chain:
- Role — who is acting (board, CIO, steering committee, auditor, process owner)?
- Task — what must be accomplished?
- Governing rule — which principle applies (segregation of duties, alignment, accountability, independence)?
- Cue — the timing or detail that separates two plausible answers.
- Best action — the choice that fits the role and the rule.
- Expected output — the evidence or deliverable that proves it was done.
When two answers both look right, the cue (who, when, what level) almost always points to the one that respects governance accountability over a faster technical fix.
Practice converting each stem into one sentence before you look at the options: 'A [role] must [task], and the governing rule is [principle].' If you can write that sentence accurately, the correct option usually becomes obvious and the distractors reveal themselves as either wrong-role, wrong-level, or wrong-timing. This habit slows you down by a few seconds but prevents the impulsive pick that the wordy Domain 2 stems are designed to provoke.
Segregation of Duties Scenarios
Segregation of duties (SoD) is the most tested control concept in Domain 2. Critical duties are split so no single person can both perpetrate and conceal an error or fraud. The four classic functions are:
| Function | Meaning | Example in IT |
|---|---|---|
| Authorization | Approve a transaction or change | Approving a code release |
| Custody | Control of an asset | Holding production access |
| Recording | Maintain the records | Logging the change |
| Reconciliation | Independently verify accuracy | Reviewing change logs vs. tickets |
In IT, this means separating systems development from operations, security administration from log review, and database administration from change approval. A developer who can also move code to production with no independent approval is a classic SoD violation. When a scenario shows one person spanning two incompatible functions, the best answer reduces that concentration — not one that merely speeds delivery.
A helpful test: ask whether one person could both commit an error or fraud and conceal it. If yes, segregation is broken. The exam also expects you to recognize that automated access provisioning, role-based access control, and an SoD conflict matrix are how organizations enforce these separations at scale in modern systems.
Compensating Controls and Vendor Governance
Small teams cannot always fully segregate duties. When that happens, compensating controls keep risk acceptable: independent supervisory review of high-risk transactions, periodic reconciliation, audit logging and monitoring, and job rotation. The exam favors answers that pair an unavoidable SoD limitation with a documented compensating control rather than answers that ignore the gap.
Outsourcing and cloud scenarios test a single governing rule: you can transfer an activity, but you cannot transfer accountability. The organization remains accountable for outsourced processes and must govern providers through clear SLAs, defined responsibilities, right-to-audit clauses, and monitoring of service performance. If a stem implies the company assumes the vendor 'has it handled,' the best answer restores oversight — independent monitoring, SLA metrics, and audit rights.
Monitoring: KPIs, KRIs, and the Balanced Scorecard
Governance is not complete without monitoring. Key performance indicators (KPIs) measure whether IT is meeting objectives (e.g., project on-time delivery, system availability); key risk indicators (KRIs) signal rising risk before it becomes an incident. An IT balanced scorecard translates strategy into measures across complementary perspectives — typically financial/business contribution, user/customer orientation, operational excellence, and future orientation/innovation — so the board sees more than cost.
In scenarios, the best monitoring answer reports the right metric to the right level: KRIs and value/risk summaries to governance; operational KPIs to management. A common distractor reports granular technical metrics to the board or hides a rising KRI inside an operational dashboard, defeating the early-warning purpose.
Organizational Structure and Reporting Lines
Scenarios also probe IT organizational structure, because reporting lines can create or resolve conflicts. The principle is independence: functions that should check each other must not report to a single person who could override both. For example, information security often reports outside the IT operations chain (to a CISO or risk function) so security is not subordinated to delivery deadlines; quality assurance should be independent of development; and the internal audit function reports to the audit committee of the board, preserving its independence from management.
When a stem shows security buried under the operations manager who is also chasing uptime targets, the conflict cue is the reporting line, and the best answer re-establishes independent reporting or compensating oversight. Apply the same lens to data ownership: business data owners classify and authorize access while IT acts as data custodian implementing the controls — mixing those roles is the violation the scenario is testing.
Reading the role, level, and reporting line first lets you separate two answers that both sound technically reasonable: only one preserves the independence and accountability governance requires. Watch especially for stems where a single capable individual has accumulated several roles 'because the team is small' — the scenario is asking you to spot the concentration of authority and propose either segregation or a documented compensating control, not to praise the person's efficiency.
An IS auditor finds that the same database administrator writes application changes, approves them, and moves them into production with no independent review. The auditor's PRIMARY concern is that:
A company outsources its payroll processing to a cloud provider and assumes the provider is fully responsible for data accuracy and security. What is the BEST response to this assumption?
To preserve its independence and objectivity, the internal audit function should report functionally to which body?