Metro Transit Authority's Shadow IT and Chargeback Dispute
Metro Transit Authority has five departments, 3,800 staff, and an IT service catalog listing 42 services. Cloud adoption happened department by department: 14 SaaS applications were bought on departmental credit cards, three of them store personal data, and none use single sign-on. The service desk records 1,100 tickets per month, and 22% breach the published 8-business-hour resolution target. There is no CMDB, so major incidents often list configuration items as 'unknown'. Finance allocates IT costs by headcount, which the scheduling department disputes because it uses 40% of the data platform but pays 8% of the cost. The CIO wants a consumption-based chargeback model, a service portfolio, and an exit strategy for the two most critical SaaS vendors, whose contracts renew in nine months.
1. Recommend a governance model and decision rights for cloud purchases. How should the authority bring the 14 shadow SaaS applications under control without stopping the business?
Read the worked answer
Use a federated governance model with a central platform team and departmental product owners.
Decision rights: the central team owns account structure, security baselines, identity, network, and the approved-service catalog. Departments own configuration and spend within guardrails. Finance owns chargeback rules. A cloud review board with the CIO, CISO, finance, and procurement approves any new SaaS that stores personal data or integrates with authority systems.
Bring shadow IT in with amnesty plus fast track. Publish a 10-business-day review covering security, data protection, integration, and exit. Offer to migrate approved apps onto SSO and a central contract. For the 14 existing SaaS applications, classify by data sensitivity; the three storing personal data get immediate security and data-processing review. Do not simply ban them - that drives them further underground.
Enforce going forward: no new contract without review, purchasing routed through the process, and the center able to block non-compliant accounts and enforce tagging and budget limits. Federated governance is not laissez-faire; the center needs real enforcement levers, but departments need a fast path so compliance does not become the bottleneck.
2. Redesign the SLA and service catalog to address the 22% breach rate. What should be measured, and what should change about the 8-business-hour target?
Read the worked answer
A 22% breach of an 8-business-hour target is a design problem, not a motivation problem.
First separate incident from request and define priority by business impact, not by who called. Publish a small number of tiers: critical (safety/eligibility systems) with 99.9% availability and a one-hour response; standard with eight business hours; low with three business days. A single target across 42 services guarantees mis-scoping.
Measure attainment from system timestamps, not closure notes: percentage met, backlog age, first-contact resolution, and major-incident restoration time. Analyze the 22% by service and priority before tightening anything. If most breaches are password resets or low-priority requests, the fix is self-service and triage, not more staff.
Add consequences and dependencies. Internal operational-level agreements between the service desk and platform teams; vendor service credits or escalation for external providers. An SLA without a consequence is a wish. If the authority wants a higher target, it must fund capacity or reduce scope. Also use the service catalog to define what is in scope, so 'unknown' configuration items become an exception to fix, not a normal state.
3. Design a consumption-based chargeback model and an exit strategy for the two critical SaaS vendors renewing in nine months. What tradeoffs should the CIO accept?
Read the worked answer
Move from headcount allocation to showback first, then chargeback. Define units: per user for collaboration, per GB stored and egress for the data platform, per VM-hour or namespace for IaaS, per transaction for the scheduling service. Publish a rate card and a monthly statement, and give departments a budget and forecast. The scheduling department's 40% usage versus 8% charge is exactly the signal a consumption model should surface.
Tradeoffs: metering costs money and can drive gaming; keep a small fixed platform fee for shared services so nobody free-rides, and smooth volatility with a cap or rolling average. Do not launch chargeback before showback data is trusted, or finance will spend a year disputing bills.
Exit strategy: inventory data and confirm export formats and deletion rights; document APIs and integrations; identify an alternate provider; set a nine-month transition plan with a dry-run export; and negotiate data-return and transition-assistance clauses before renewal. Test export in month three, not month eight. Accept that maintaining dual-running capability has a cost; that cost is the premium for avoiding lock-in. For the two critical vendors, require a exit plan owner and a board-visible milestone schedule.