A co-managed IT services model combines an internal team with an external provider to operate the same technology estate. It can preserve business knowledge and decision authority while adding coverage, specialist skills, and disciplined service management. It can also produce dangerous ambiguity: both teams can see an alert, each can assume the other owns it, and neither may hold the access or authority to contain the incident.
A high-level RACI is a starting point, not the operating model. Shared operations need task-level triggers, one accountable role, executing responsibility by time and severity, consulted specialists, notification recipients, required access, evidence, handoff acceptance, and escalation when an owner is unavailable. The model must work at 2 a.m., during staff leave, and across third-party failures, not only in a governance workshop.
Define retained authority and provider boundaries
Start with service outcomes and the retained organization. The customer normally retains business priority, risk acceptance, data ownership, regulatory accountability, budget, architecture guardrails, and authority for material change. The provider may own monitoring, first response, routine administration, standard changes, platform maintenance, or specialist escalation within scope. The exact allocation depends on capability, access, hours, and risk, not job titles.
List in-scope services, environments, locations, user groups, hours, technologies, and exclusions. Then describe interfaces to product engineering, security, facilities, telecom carriers, cloud providers, SaaS vendors, and business continuity. ISO 37500 notes that outsourcing lifecycle processes cannot always be assigned exclusively to client or provider and must be tailored. Co-management makes that tailoring explicit at operational resolution.
| Decision or activity | Internal team | Provider | Control note |
|---|---|---|---|
| Business service priority | Accountable | Consulted | Named service owner decides conflicts |
| 24x7 event monitoring | Informed | Responsible | Coverage and tool health are measured |
| Priority-one incident command | Accountable or delegated by scenario | Responsible initial commander | Authority transfers through explicit handoff |
| Standard patch deployment | Approves policy | Responsible within window | Pre-approved runbook and rollback |
| Risk acceptance | Accountable | Advises | Provider cannot accept customer risk |
| Provider staffing and quality | Reviews outcomes | Accountable | Skills, succession, and coverage obligations |
Build a task-level RACI with triggers and authority
Decompose operations into observable activities: monitor queue health, triage endpoint alerts, approve emergency firewall change, restore a database, rotate certificates, grant privileged access, contact a carrier, communicate to executives, preserve evidence, update status pages, and close post-incident actions. Assign exactly one accountable role for each scenario. Multiple responsible roles are possible only when their work and sequencing are clear.
Extend RACI with execution fields: trigger, severity, time target, primary channel, tool, required privilege, runbook, evidence, backup owner, and escalation authority. AWS Well-Architected guidance on responsibilities and ownership recommends discoverable responsibility matrices and clear escalation paths. Store the matrix where responders work and link rows to executable procedures rather than attaching a static spreadsheet to the contract.
Design alert and incident handoffs as state transitions
Define who receives each alert, who acknowledges, what starts the clock, when an event becomes an incident, and who can declare severity. Route by affected service and symptom rather than by infrastructure ownership alone. Deduplicate correlated alerts, suppress only with approved rules, and monitor the monitoring path. Every unacknowledged alert needs a timed escalation to a role with authority, not merely another inbox.
Treat handoff as an accepted transfer of command or work. Record incident identifier, impact, timeline, hypotheses, actions taken, evidence locations, current risk, next action, owner, and next update time. The receiving role acknowledges explicitly; until then, the sender retains responsibility. NIST SP 800-61 Rev. 3 integrates incident response across preparation, detection, response, recovery, and improvement. Contract scope should support that full cycle, including cross-party learning.
| Stage | Primary role | Required evidence | Escalation trigger |
|---|---|---|---|
| Detect and acknowledge | Provider monitoring analyst | Alert, service, timestamp, initial context | No acknowledgment within target |
| Triage and classify | Provider duty lead | Impact, severity, affected boundary | Unclear ownership or suspected major impact |
| Command | Named incident commander | Objectives, workstreams, decision log | Authority or resource constraint |
| Contain and recover | Assigned technical owners | Actions, approvals, validation, rollback | Risk exceeds delegated authority |
| Communicate | Internal communications owner | Audience, message, approval, cadence | Regulatory or executive threshold |
| Learn and improve | Internal service owner | Timeline, causes, actions, owners | Repeat issue or overdue action |
Align access, change authority, and evidence
A provider cannot own a response it is unable to perform. Map every responsibility to least-privilege access, approval, and break-glass procedure. Use named identities, time-bound elevation, strong authentication, session logging where proportionate, and prompt offboarding. Keep emergency access usable when normal identity dependencies fail, and test it. The customer should retain independent access sufficient to govern and recover critical services.
Define standard, normal, and emergency changes with approval authority, risk threshold, testing, evidence, maintenance windows, conflict checks, rollback, and retrospective review. Pre-authorize well-tested routine actions so incidents do not wait for a meeting. Do not permit a broad emergency label to bypass accountability. Record configuration state and correlate changes with service impact across both organizations' tools.
Cover third parties, after-hours work, and unavailable people
Document who holds each cloud, hardware, telecom, and software support contract; who can open the highest-severity case; which identifiers and diagnostic evidence are required; and who may authorize paid work. Test vendor portals and escalation numbers. If only the internal procurement lead can invoke premium support during local office hours, the provider's 24x7 promise has an operational dependency that must be resolved.
Design coverage by role, not named hero. Maintain primary and backup schedules, contact channels, response expectations, language needs, and authority delegation. AWS guidance on personnel capability calls for enough trained personnel to support the workload and incidents, including rotation and leave. Measure missed pages, unsupported shifts, excessive escalations, and fatigue signals rather than assuming roster coverage equals capability.
Exercise shared operations before production pressure
Run tabletop and technical exercises around boundary failures: provider detects data exfiltration but cannot disable a customer identity; the customer changes a firewall without updating the provider; a cloud region fails while the internal owner is unavailable; an emergency patch conflicts with a business freeze; or the ticket platform itself is down. Observe who notices, decides, acts, communicates, and records. Correct access and authority gaps, not only documentation.
Use shadow and reverse-shadow during transition. The incumbent performs while the incoming party follows, then the new responsible role performs under observation. Test routine shifts, priority incidents, recovery, and vendor escalation. ISO/IEC 20000-1 covers service planning, transition, delivery, measurement, and improvement; readiness should be accepted on demonstrated operation across those stages.
Govern and refresh the operating model
Review service outcomes, SLOs, incidents, changes, access, automation failures, handoff time, escalation frequency, repeat defects, and open risks in a joint forum. Separate operational correction from contractual dispute, but preserve evidence for both. Give the service owner authority to resolve ambiguous ownership quickly and require the matrix owner to incorporate the decision. Track areas where consultation is slowing response and where the provider repeatedly acts outside scope to preserve service. Measure time to acknowledge a handoff, time waiting for retained approval, unsupported escalation attempts, and activities completed without required evidence. These signals show whether the boundary itself is degrading service.
Trigger RACI review after a major incident, new service, architecture change, acquisition, staffing model change, new regulation, or tool replacement. The UK Contract Management Playbook presents contract management as an ongoing delivery discipline. A co-managed agreement should similarly evolve its operating handbook under controlled change while keeping contractual accountability, pricing, and risk allocation aligned.
Co-managed IT operations takeaways
- Define retained business, risk, data, and architecture authority before assigning tasks.
- Decompose shared operations into triggered activities with one accountable role.
- Add access, evidence, timing, backup ownership, and escalation to the RACI.
- Require explicit acceptance when incident command or work transfers.
- Pre-authorize tested routine and emergency actions within risk limits.
- Map third-party support rights and after-hours authority to the teams expected to respond.
- Exercise boundary failures and update the model after operational change.
Co-managed IT services FAQ
Can a RACI have two accountable roles?
For one defined activity and scenario, use one accountable role. Split the activity or define conditional accountability by severity, service, or time if authority genuinely changes. Shared accountability often means no decisive authority.
Does the internal team still need on-call coverage?
Usually for retained decisions, business context, risk acceptance, security, or executive communication. The required coverage may be smaller than technical response, but escalation authority must match the service's operating hours and impact.
Should the full RACI be part of the contract?
Material accountability, scope, and service obligations belong in contractual documents. Detailed routing can live in a controlled operating handbook if the contract defines precedence, change authority, and how commercial impact is handled.
Conclusion
Co-managed IT works when two capable teams operate as one explicit control system. Define retained authority, connect each task to access and evidence, make handoffs accepted transitions, and rehearse the failures most likely to expose the boundary. Include automation in the model: every scheduled job, remediation rule, and self-service action needs an owner, failure destination, change authority, and manual recovery path across organizational lines. A living responsibility model then becomes more than a RACI chart: it becomes the mechanism that ensures somebody can decide and act when the service is under pressure.