Co-Managed IT Operating Model Checklist for Expansion

Managed IT & Buying Guidance

Updated July 12, 2026

Expansion exposes every vague sentence in a co-managed IT agreement. "Shared responsibility" sounds collaborative, but it does not tell a new employee who creates an account, a site leader who calls during an outage, or a provider who is authorized to change a firewall. A workable model assigns each recurring task, decision, and escalation before growth adds load.

Use this checklist to compare providers on operating evidence rather than presentation quality. Ask each provider to show how the proposed model works through a real scenario from your environment.

1. Establish the expansion baseline

Inventory current users, sites, endpoints, servers, networks, cloud services, applications, vendors, and support commitments.
Identify what expansion adds: headcount, locations, shifts, remote work, regulated data, acquisitions, applications, or customer obligations.
Record known technical debt, unsupported systems, open incidents, incomplete projects, and undocumented dependencies.
Name the business services that cannot be interrupted and the leaders who approve risk for them.

A provider cannot price or staff a reliable operating model from device count alone. The baseline should reveal complexity, operating hours, change volume, business criticality, and the work your internal team intends to retain.

2. Build a task-level responsibility matrix

For every recurring task, assign who performs it, who approves it, who must be consulted, and who receives evidence. Cover at least:

User onboarding and offboarding, access reviews, privileged access, and emergency accounts.
Endpoint, server, network, cloud, application, identity, backup, and vendor administration.
Alert triage, incident command, after-hours response, problem management, and security escalation.
Patch, configuration, change, release, procurement, warranty, licensing, and asset disposal work.
Recovery planning, backup review, restore testing, continuity exercises, and lessons learned.

"Joint" is not an owner. If both parties participate, identify the primary actor, approval point, handoff evidence, time expectation, and escalation when the other party is unavailable.

3. Test the service desk and escalation path

Walk a sample request from intake through closure. Confirm which channels create a ticket, how identity is verified, where priorities come from, who can change priority, what pauses a target, and how users receive updates. Then walk an outage and a suspected security event; these should not follow an ordinary request queue.

Ask the provider to demonstrate reporting from a representative workflow. The evidence should distinguish response, active work, customer wait, vendor wait, resolution, reopened work, recurring problems, and aged backlog. Aggregate ticket counts alone do not show whether service is improving.

4. Prove access and change governance

Who grants provider access, at what privilege, through which identity, and for how long?
Can administrative activity be attributed to an individual and reviewed by the customer?
Which changes are standard, normal, or emergency, and who approves each class?
What configuration, log, documentation, and rollback evidence closes a change?
How are provider staff changes, subcontractors, and third-party remote access handled?

NIST's Cybersecurity Supply Chain Risk Management guidance treats acquired products and services as lifecycle risks. Provider review should therefore continue after contract signature.

5. Make expansion a controlled service gate

Define evidence required before a new site, team, or system enters steady-state support. The gate might include an accepted asset list, diagrams, administrative access, monitoring and alert routes, backup coverage, restore evidence, licensing, vendor contacts, support instructions, known exceptions, and sign-off from the business owner.

Use three states instead of pretending every item is complete: accepted into service, accepted with a dated exception, or not accepted. A critical missing dependency should remain visible to the risk owner rather than disappearing into a general onboarding task list.

6. Inspect the commercial boundary

Separate recurring service, usage-based charges, licenses, projects, onboarding, travel, hardware, and third-party costs.
Define what changes when user, device, site, server, storage, or support-hour assumptions change.
List exclusions such as legacy remediation, major upgrades, migrations, cabling, compliance assessment, or vendor project work.
Confirm renewal, price-change, minimum-term, termination-assistance, data-return, and transition obligations.
Identify customer prerequisites that can delay service or create additional work.

Compare total operating scope, not only the monthly line item. A lower recurring fee can conceal project work, retained internal labor, weak after-hours coverage, or an expensive exit path.

7. Require an exit-ready operating model

The organization should retain access to its records, tenant relationships, configurations, asset data, documentation, tickets, logs, recovery information, and vendor contacts in agreed formats. Define how credentials and privileged roles transfer, how provider tools are removed, how retained data is handled, and what assistance is included.

Exit readiness is also an operating-health test. If documentation cannot support a transition, it may not support incident response or staff turnover today.

Monthly acceptance checkpoints

Review inventory reconciliation, unassigned responsibilities, unresolved service-acceptance exceptions, aged incidents and requests, failed or rolled-back changes, privileged-access exceptions, restore evidence due, repeat issues, supplier risks, and actions awaiting a business decision. Every item should have an owner, evidence due, and escalation date.

Primary buyer references

NIST Cybersecurity Framework 2.0 for governance, supplier, protection, detection, response, and recovery outcomes.
NIST SP 800-161 Rev. 1 Update 1 for cybersecurity supply chain risk across acquired products and services.
CISA software acquisition guidance for asking suppliers evidence-based security questions during procurement.
NIST CSF 2.0 Organizational Profiles for documenting current and target outcomes.

Related Cloud Core guides

Suggested next step

Choose one high-impact workflow and ask each provider to map the task, approval, evidence, exception, and escalation end to end. Explore our managed IT services if you need help designing a co-managed model that can absorb expansion.