Authority and accountability in Arcadia Bank's SIAM function
Arcadia Bank created an internal SIAM function of 22 FTE eight months ago to integrate four providers. Priya, the SIAM incident process owner, has documented a major incident process requiring all providers to use the bank's ServiceNow instance and to join a single incident bridge within 15 minutes. Provider A, an application support supplier worth €14m a year, refuses. Its delivery manager says its contract requires it to use its own tool and that joining the bank's bridge 'duplicates effort'. Provider A escalates to its account director, who contacts the bank's vendor manager, who tells Priya to 'be pragmatic'. In six weeks there have been three P1 incidents, each with two parallel bridges, and the mean time to assemble the right people is 45 minutes. Priya's manager is the same director who owns vendor management. The SIAM head has no authority over provider staff and no seat on the service governance board.
1. Diagnose what is wrong with the role and authority design, and propose changes to the accountability model.
Read the worked answer
The problem is not that Priya lacks personal authority; it is that the design has collapsed two different accountabilities into one reporting line and given the process owner no escalation route that does not pass through the commercial relationship.
Root causes:
- Vendor management and SIAM are conflated. Priya's manager owns both, so a commercial concern can override a process decision with a single instruction. The vendor manager's instinct is to protect the relationship, which is appropriate for contracts but not for process compliance.
- No documented authority for the process owner. Accountability for process design, process compliance and arbitration should be written into role descriptions, endorsed by the governance board and reflected in the provider contracts.
- No seat at governance. The SIAM head cannot escalate beyond the director, so disputes become personal rather than procedural.
Changes: separate vendor management from SIAM process ownership in the reporting line; place the SIAM head on the service governance board; publish a RACI that distinguishes process authority (Priya decides how the process works and whether a provider is compliant) from line and commercial authority (the vendor manager negotiates and enforces contract consequences); and create a time-bound escalation route ending at the governance board. Authority should be over process and evidence, not over provider staff.
2. How should the dispute with Provider A be handled in the short term and the longer term?
Read the worked answer
Short term, establish the facts before escalating. Read Provider A's contract and statement of work to see whether it is actually obliged to use the bank's tool and process; the delivery manager's claim may be correct, or the contract may be silent. If the contract already requires it, the vendor manager should confirm the obligation in writing and the governance board should record the expectation. If the contract is silent, the bank cannot simply impose the process; it needs a change control with a defined scope and date, and in the interim a documented bridging arrangement - for example, Provider A joins the bank's bridge while continuing to log in its own tool, with data exported to the SIAM team within an agreed time.
Longer term: standardise process and tooling obligations in all provider contracts at renewal, with explicit clauses on major incident participation, data sharing and compliance with the SIAM process model. Run a joint workshop with Provider A to show how the duplicated bridge increases its own cost and risk. Pilot the single bridge on the next P1 and measure mean time to assemble and restoration time before and after. Report the result to the governance board as evidence rather than as an argument. Throughout, keep the process debate and the commercial relationship separate, so that neither is used as leverage against the other.
3. What would you include in the RACI to prevent this recurring across all four providers?
Read the worked answer
The RACI should be built around activities, not around organisations, and should explicitly separate process decisions from commercial decisions.
For major incident management: the SIAM incident process owner is accountable for the process definition, the priority matrix and compliance; the service integrator is responsible for running the bridge and coordinating providers; each provider is responsible for its own technical resolution and for supplying named contacts and updates; the vendor manager is consulted on contractual consequences and informed of breaches; the governance board is accountable for arbitration when escalation reaches it.
For tooling and data: the SIAM function owns the data model and reporting requirements; providers are responsible for supplying data in the agreed format; vendor management is accountable for embedding the obligation in contracts.
For service level performance: the service integrator is accountable for end-to-end reporting; providers are responsible for their own measures; the business relationship owner is consulted on priorities.
Add two rules: no single individual may be accountable for both a commercial relationship and the arbitration of that provider's process compliance; and every accountable role must have a named escalation point with a stated time limit. Publish the RACI, walk it through with all four providers, and make it an annex to each contract at the next change.