Short answer: Co-managed IT is an operating model in which an internal IT team and an external managed service provider divide technology responsibilities. The internal team remains in place. The provider supplies agreed coverage, tools, specialists, or project capacity. A useful co-managed arrangement identifies who approves, performs, monitors, escalates, documents, and verifies each task. The label alone does not define the service.
How this guide was prepared
Reviewed: August 18, 2026. This guide uses current NIST and CISA guidance on cybersecurity governance, supplier due diligence, managed service provider relationships, baseline controls, and recovery planning. It does not promise lower cost, uninterrupted service, complete security, compliance, or a fixed response time.
- Source policy: operating and security claims link to official government publications.
- Scope: the guide explains responsibilities, evidence, onboarding, escalation, and evaluation. It does not replace a contract, legal advice, or an industry-specific risk assessment.
- Freshness rule: confirm the provider’s current service description, tools, subcontractors, data handling, support hours, exclusions, and contract terms before signing and at renewal.
- Decision rule: accept a co-managed model only when every material responsibility has one accountable owner, a handoff path, evidence, and a testable outcome.
What co-managed IT means
Co-managed IT supplements an internal technology function. It can add service-desk capacity, monitoring, infrastructure administration, Microsoft 365 support, cybersecurity operations, backup oversight, project delivery, procurement support, or after-hours escalation. The organization retains internal staff and decides which decisions and tasks remain in-house.
That differs from fully outsourced IT support, where a provider may own most agreed daily technology operations. It also differs from a one-time consulting project. Co-management is an ongoing division of operational responsibility, even when projects are included.
The dedicated Rivell co-managed IT services page describes the commercial service. This article owns the informational question: what the model is, how responsibilities should be divided, and what evidence a buyer should request.
When co-managed IT can fit
Common fit signals
- An internal team understands the business but lacks coverage for every location, system, or support hour.
- Specialized work in cybersecurity, cloud, networking, recovery, or Microsoft 365 exceeds current capacity.
- Projects and daily tickets compete for the same internal people.
- The organization wants to retain internal authority while adding documented operational support.
- A vacancy, acquisition, expansion, or technology transition creates a temporary or continuing capacity gap.
Warning signs
- No internal owner has authority to approve priorities, access, exceptions, or change windows.
- The proposal uses “shared” without assigning one accountable party for each outcome.
- Monitoring is sold without a staffed response and escalation process.
- The provider cannot identify its privileged tools, subcontractors, data locations, or exit process.
- Success is described through general promises instead of service records, tests, and acceptance criteria.
Three common co-managed operating models
| Model | Internal team typically owns | Provider typically owns | Critical handoff |
|---|---|---|---|
| Coverage extension | Business applications, local relationships, approvals, daytime escalation | After-hours service desk, monitoring, overflow tickets, defined escalation | Severity, acknowledgement, communication, and next-business-day transfer |
| Specialist extension | Daily support, business systems, user relationships, priorities | Cybersecurity, cloud, network, recovery, Microsoft 365, or project specialists | Scope boundary, change authority, evidence, and technical documentation |
| Platform operations | Strategy, application ownership, budgets, risk decisions, vendor priorities | Agreed infrastructure, endpoints, identity, backup, monitoring, and service processes | Responsibility matrix, exceptions, vendor coordination, and acceptance tests |
Actual ownership can differ. A proposal should describe the selected model task by task. Do not infer coverage from the words “co-managed,” “proactive,” or “24/7.”
Build a responsibility matrix before comparing providers
The NIST Cybersecurity Framework 2.0 emphasizes governance, roles, responsibilities, and oversight. Its supply-chain outcomes also call for supplier, customer, and partner responsibilities to be established, communicated, and coordinated. Use that principle across technology operations, not only cybersecurity.
| Responsibility | Decisions to document | Evidence to retain |
|---|---|---|
| User onboarding and offboarding | Who approves, creates, changes, disables, and verifies access? | Requests, approvals, timestamps, group changes, license changes, and closure checks |
| Service desk | Which users, sites, systems, hours, channels, priorities, and languages are covered? | Ticket history, queue age, escalation records, reopen rate, and user confirmation |
| Endpoint and server management | Who inventories, configures, patches, monitors, replaces, and supports each device class? | Inventory, configuration status, patch exceptions, alerts, and lifecycle records |
| Microsoft 365 and identity | Who owns tenants, roles, MFA, conditional access, licenses, domains, and vendor escalation? | Role register, access reviews, configuration exports, change records, and recovery contacts |
| Network and connectivity | Who owns diagrams, firewalls, wireless, circuits, DNS, certificates, carriers, and changes? | Diagrams, configurations, warranties, carrier records, change logs, and failover tests |
| Cybersecurity operations | Who triages alerts, investigates, contains, communicates, preserves evidence, and approves risk? | Alert records, investigation notes, access logs, incident exercises, and exception decisions |
| Backup and recovery | Who selects scope, retention, isolation, monitoring, restore authority, and recovery order? | Job status, failed-job response, restore tests, RPO/RTO results, and exercise findings |
| Applications and vendors | Who administers the application, supports users, manages integrations, and contacts the vendor? | Owner register, support entitlements, dependencies, escalation history, and renewal dates |
| Projects and changes | Who designs, approves, implements, tests, communicates, accepts, and rolls back work? | Requirements, plan, approvals, test results, acceptance, documentation, and rollback evidence |
| Documentation and exit | Who maintains records, owns credentials, exports data, removes tools, and transfers knowledge? | Document register, credential custody, data export test, tool-removal plan, and transition checklist |
Security responsibilities remain shared, not assumed
A joint CISA-led advisory for MSPs and customers recommends transparent contractual arrangements, clear expectations, secure remote access, monitoring, backups, incident planning, and defined ownership for hardening, detection, response, and recovery. Hiring a provider does not transfer every risk decision to that provider.
CISA’s risk considerations for MSP customers recommends a shared responsibility model, detailed service levels, incident-management terms, log requirements, data-separation evidence, and remediation acceptance criteria. Ask who can access which systems, how privileged access is approved and removed, where logs are retained, what the customer can inspect, and how incidents affecting the provider or its subcontractors are communicated.
Use CISA’s Cross-Sector Cybersecurity Performance Goals as a voluntary baseline for priorities such as account security, vulnerability remediation, logging, incident response, and tested recovery. Then map the applicable tasks to the internal team, Rivell, software vendors, carriers, cloud providers, and any other participating party. Rivell’s cybersecurity services, Microsoft 365 support, and backup and disaster recovery services should be included only where the written scope assigns those responsibilities.
Evaluate the provider and its supply chain
NIST SP 800-161 Revision 1 addresses cybersecurity risk across technology products and services. The newer NIST SP 1326 supplier due-diligence guide provides a structured way to research supplier ownership, provenance, resilience, foundational practices, and supply-chain tiers. Apply due diligence to the MSP, its remote-management tools, security platforms, cloud services, subcontractors, and other dependencies that can reach the client’s environment.
- Request the legal provider name, service locations, relevant subcontractors, and ownership of each platform.
- Document administrative access paths, multifactor authentication, technician authorization, logging, session control, and access removal.
- Ask how customer environments and data are separated, backed up, exported, and returned or destroyed.
- Review provider incident notification, business continuity, recovery, insurance, and vendor escalation processes.
- Confirm which evidence is available before purchase, during service, after an incident, and at termination.
Plan onboarding as a controlled transition
Onboarding should begin with authority and inventory, not immediate tool installation. Identify people, locations, users, endpoints, servers, networks, cloud tenants, applications, vendors, data, backups, contracts, current tools, known risks, open projects, and support expectations. Record what is verified, what is reported but unverified, and what remains unknown.
- Authorize: name executive, internal IT, security, procurement, legal, and provider decision owners.
- Discover: reconcile assets, identities, administrative access, dependencies, support agreements, and documentation.
- Design: approve the service boundary, responsibility matrix, escalation path, security controls, maintenance windows, and reporting.
- Pilot: test representative tickets, alerts, changes, access requests, restores, vendor escalations, and after-hours handoffs.
- Accept: compare the live result with written functional, security, recovery, documentation, and support criteria.
If the environment includes production systems, manufacturing technology, or other operational dependencies, include their owners and maintenance constraints. Rivell’s guide to IT in manufacturing shows why business systems, plant systems, vendors, data flows, and recovery sequences need explicit ownership.
Measure the operating model, not a marketing promise
Choose measures that reflect the assigned scope. Useful evidence can include ticket intake and ageing, first acknowledgement, escalation timing, reopened tickets, unresolved problem records, patch exceptions, alert disposition, failed backup response, restore-test results, access-review completion, documentation freshness, change success, incident-exercise findings, and project acceptance. A faster average is not automatically better if severity, scope, user confirmation, or reopen rates are ignored.
Review failures and boundary disputes separately. If both teams believed the other owned a task, the responsibility model failed even when a ticket eventually closed. Update the matrix, workflow, documentation, and contract when the operating reality changes.
Set an operating cadence for both teams
A responsibility matrix is useful only when the teams use it. Establish a working cadence before service begins. Daily coordination may cover urgent tickets, active incidents, planned changes, user access, and immediate vendor dependencies. A weekly operations review can cover ageing work, recurring problems, alert trends, failed jobs, upcoming maintenance, project conflicts, and documentation gaps. A monthly governance review can cover service evidence, risk exceptions, licensing, capacity, lifecycle items, recovery tests, supplier changes, and budget decisions.
Name one service owner on each side. Those owners should resolve priority conflicts, approve matrix changes, coordinate other vendors, and make sure unresolved work is visible. Record decisions in the shared system of record instead of relying on private messages or memory. When a new application, site, acquisition, policy, or vendor changes the environment, update the inventory, responsibility matrix, escalation contacts, monitoring scope, backup design, and exit records together. This cadence prevents the co-managed arrangement from becoming two separate teams with overlapping tools and incomplete accountability.
Compare total requirements and contract evidence
Co-managed IT pricing can depend on users, devices, sites, service hours, tools, security requirements, cloud platforms, backup scope, projects, travel, compliance obligations, and the work retained internally. Compare recurring fees together with onboarding, remediation, hardware, licenses, projects, after-hours work, travel, carrier costs, and internal labor. The managed IT pricing guide provides a broader quote-comparison framework.
Before selecting a provider, review Rivell’s managed IT provider comparison and questions to ask a managed IT company. Require the proposal to identify inclusions, exclusions, support hours, severity definitions, dependencies, customer duties, subcontractors, evidence, renewal terms, transition assistance, data return, and tool removal.
Questions to resolve before signing
- Which outcomes stay with the internal team, and which transfer to the provider?
- Who is accountable when a task crosses teams, vendors, sites, or support hours?
- What tools and privileged access will the provider use, and how are those controlled?
- Which alerts receive staffed response, and what happens after acknowledgement?
- What evidence proves patching, access review, backup, restore, escalation, and documentation work?
- How are projects, emergencies, travel, remediation, licenses, and after-hours work priced?
- How will the organization test onboarding, ongoing service, recovery, and eventual exit?
Bottom line: co-managed IT works when the internal team and provider operate from one documented responsibility model. Clear authority, secure access, measurable handoffs, current documentation, tested recovery, and usable exit evidence matter more than the label.
Map the co-managed service boundary
Rivell can help New Jersey organizations inventory the current environment, identify capacity and specialist gaps, define the responsibility matrix, test escalation and recovery paths, and scope an operating model around the internal team’s actual role.
Request a co-managed IT assessment or review Rivell’s managed IT services in New Jersey and IT support services.
Primary sources
- NIST Cybersecurity Framework 2.0
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- NIST SP 1326, Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide
- CISA-led joint advisory, Protecting Against Cyber Threats to Managed Service Providers and their Customers
- CISA, Risk Considerations for Managed Service Provider Customers
- CISA Cross-Sector Cybersecurity Performance Goals
