Federated Governance and Shadow SaaS at Aurelia Group
Aurelia Group is a federated conglomerate with five business units and a central IT function. An internal audit found 230 SaaS applications in use, 60 of them unsanctioned, with customer data stored in three jurisdictions. Each business unit procured tools locally to meet its own regulatory and commercial needs; central IT approves purchases only above a spend threshold. The board wants 'one governed service management model' and is considering a central approval board for every new service. Business unit CEOs say that would repeat a previous failed centralization programme. Aurelia also acquires companies regularly, so any model must absorb new units quickly. The group CIO must present a governance design that satisfies the audit committee without turning service management into a bottleneck. The audit committee has asked for decision rights, not just a policy document.
1. Explain why a central approval board for every new service is probably the wrong governance response, and propose a federated alternative.
Read the worked answer
Governance is about direction and control: principles, decision rights, policies, and oversight that keep service management aligned to organizational objectives and risk appetite. It is not the same as central approval of every service. A central approval board for all new services would likely recreate the failed centralization, slow business units, and drive more shadow purchasing. A better design uses federated governance: group-level principles and risk tiers; central ownership of data classification, security, vendor-risk, and interoperability standards; business-unit ownership of service outcomes within those guardrails; and a time-bound exception route. Decision rights should be explicit-who can approve low-risk SaaS, who must be consulted on customer data, who owns the service catalogue entry, and who accepts residual risk. This satisfies the audit committee because accountability becomes visible without requiring central permission for every purchase.
2. Design the governing body and its decision rights. What should it decide, and what should it deliberately not decide?
Read the worked answer
Establish a service management governing body chaired by the group CIO, with empowered representatives from each business unit, risk, compliance, security, and procurement. It should set principles, approve risk tiers, review the service portfolio, arbitrate cross-unit conflicts, and own the exception process. It should not decide every low-risk tool purchase or every service feature; those belong to business units within guardrails. Create risk-based registration: low-risk tools auto-register, medium-risk tools need security and data review, and high-risk tools need governing-body approval. Publish standards for customer data and vendor risk rather than mandating a single platform. For acquisitions, require a 90-day integration playbook that maps acquired services into tiers and records exceptions. This keeps the body focused on direction and risk, not operational queue management.
3. What metrics would show that the governance design is working, rather than merely adding control?
Read the worked answer
Measure both control and speed. Useful metrics include the percentage of services and SaaS tools registered, the percentage of unsanctioned tools found in audits, time to approve by risk tier, number and age of exceptions, audit findings closed, and business-unit satisfaction with the process. Also track incidents caused by unregistered services and data-residency exceptions. A falling approval time with stable or improving risk indicators suggests governance is enabling rather than blocking. The governing body should review these measures quarterly and adjust thresholds. Avoid judging success by the number of central approvals or policy documents produced; those can rise while shadow IT continues. The audit committee should see decision-rights evidence, not just a policy.