Your Managed IT Renewal Needs an Incident Ownership Test
A managed IT agreement can look broad and still leave a dangerous amount of work unowned.
The scope may include monitoring, help desk, patching, backups, security tools, vendor support, and “incident response.” That sounds complete until a serious event hits and everyone starts asking the same questions.
Who decides this is an incident? Who calls the executive team? Who can isolate a device? Who contacts the cyber insurer? Who preserves evidence? Who leads recovery at 2 a.m.?
If the answer is “we’ll work together,” the answer is not clear enough.
Before you renew an MSP or managed IT agreement, run an incident ownership test. You are not trying to make the provider own every task. You are trying to prove that every important task has one accountable owner, a backup, an escalation path, and enough authority to act.
Start with the signed scope, not the relationship
A good provider relationship matters. It does not replace a clear operating model.
Pull the current master services agreement, statement of work, service descriptions, SLA, support matrix, security addendum, escalation procedure, and any side agreements created during the term. Then compare those documents with the way your team believes the service works.
Watch for phrases such as “support as needed,” “reasonable assistance,” “coordinate with customer,” or “incident response support.” Those phrases may be acceptable in context, but they do not tell you who does what under pressure.
NIST SP 800-61 Revision 3, published in April 2025, describes incident response involving third parties as a shared responsibility model. NIST says transferred responsibilities should be clearly defined in the contract. It also calls out information flows, coordination, authority to act, and restrictions on what a provider may do.
That is a useful renewal standard. The contract and the response plan should tell the same story.
Run the test across seven moments
Do not ask the provider, “Do you handle incidents?” The answer will be yes. Walk through the actual work instead.
Use a realistic scenario for your environment, such as a compromised administrator account, ransomware on a server, a suspicious cloud login, or an outage involving a critical application. For each stage, require a named owner and evidence.
1. Detection and intake
Start with how the incident enters the system.
- Which tools and services can create an alert?
- Which alerts does the MSP monitor after hours?
- Where do employee reports go?
- Who reviews a vendor breach notice or cloud security alert?
- What happens if the first ticket is categorized as normal support?
- Which systems, identities, or locations are outside the provider’s visibility?
“24/7 monitoring” is not a complete answer. Ask what is monitored, who reviews it, what creates a human escalation, and which signals remain your responsibility.
2. Classification and command
Someone has to decide that the issue is serious enough to change the operating posture.
Who assigns severity? Who becomes the incident commander? Does the provider lead, or does it support an internal leader? What happens if the primary contact is unavailable?
The provider may be the first party to spot the event and still be the wrong party to command the business response. That is fine. The gap appears when nobody has accepted command.
Write down the handoff condition. For example: the MSP triage lead classifies the technical event, then the IT Director accepts incident command for high-severity cases. Your exact model may differ. It should not depend on whoever answers the phone first.
3. Containment authority
This is where vague scope becomes expensive.
A provider may be able to disable an account, isolate an endpoint, block traffic, stop a service, revoke sessions, or shut down remote access. The question is whether it may act without waiting for approval.
Build a short authority table:
| Action | Provider may act | Customer approval required | Backup approver |
|---|---|---|---|
| Disable a standard user account | Yes or no | Name or role | Name or role |
| Isolate a managed endpoint | Yes or no | Name or role | Name or role |
| Disable an administrator account | Yes or no | Name or role | Name or role |
| Take a production system offline | Yes or no | Name or role | Name or role |
| Block external connectivity | Yes or no | Name or role | Name or role |
Do not give broad destructive authority without limits. Do not create an approval model that leaves the provider watching an active compromise while your team searches for an executive.
4. Communications and escalation
Technical response and business communication are separate jobs.
Confirm who updates executives, employees, affected business owners, outside counsel, the cyber insurance carrier, and other providers. Define how often high-severity updates occur and what each update includes.
Also test the provider’s escalation path. Your account manager may be helpful during normal business hours and useless at midnight. You need the operational contact, after-hours process, management escalation, and a way to reach someone when the ticket queue is not moving.
Ask for the same on your side. If the MSP only has one customer contact, your plan has one point of failure.
5. Evidence and investigation
The provider may control logs, tickets, endpoint telemetry, identity records, backup data, firewall events, or administrative history that your company will need later.
Ask:
- Which evidence does the provider collect and retain?
- How quickly can your team export it?
- What format will you receive?
- Who preserves relevant records after an incident is declared?
- Does the provider maintain a timeline of actions and decisions?
- How does it coordinate with outside counsel, forensics, insurance, or law enforcement when authorized?
- What happens to the records when the agreement ends?
Your company remains accountable for its legal, regulatory, insurance, and contractual obligations. Route those questions through qualified legal and risk professionals. The renewal decision should still expose whether the provider can supply the records they may need.
6. Recovery and validation
Containment is not recovery.
The agreement should show who rebuilds endpoints, restores servers, resets credentials, validates backups, coordinates application owners, checks integrations, monitors for recurrence, and approves a return to normal operation.
This is where adjacent services create confusion. The MSP may manage the backup tool while another provider owns the cloud application. An MDR provider may confirm containment while internal IT owns restoration. A software vendor may restore the service but not validate your data or downstream integrations.
Put each dependency in the response map. If work falls between providers, assign an internal owner to coordinate it.
7. Review and remediation
After the event or exercise, someone needs to turn the lesson into work.
Who produces the timeline? Who documents the root cause? Who owns corrective actions? Which improvements are included in the managed service, and which become a project or change order? How will both teams confirm that the issue is fixed?
A provider can close the ticket while the business risk stays open. Your renewal process should prevent that.
Price the work that stays with your team
Managed IT is rarely fully managed. Your company will retain business decisions, risk acceptance, executive communication, legal coordination, and work outside the provider’s scope.
That retained work needs a cost and an owner.
Look back over the current term. How much time did your staff spend chasing ticket updates, coordinating vendors, correcting asset records, fixing failed agents, reviewing low-context alerts, managing emergency changes, or rebuilding systems the agreement appeared to cover?
Do not turn this into a complaint log. Use it to calculate the actual operating model.
A lower monthly fee can be a bad deal if internal IT supplies the missing service. A higher fee can still be a bad deal if the provider has broad access but little authority or accountability. Compare the full workload, not only the invoice.
If you are deciding whether the provider should replace or augment internal staff, the broader managed IT versus co-managed IT guide can help frame the model. The renewal test here is narrower: does the division of work hold up during an incident?
Put the answer into the renewal record
Once the gaps are visible, choose a decision state.
- Renew: Ownership, authority, evidence, and service performance are clear enough for the next term.
- Renew with written remediation: The provider fits, but named gaps need deliverables, owners, dates, and acceptance evidence.
- Redesign the scope: The service boundaries no longer match the internal team, technology stack, or risk.
- Run a competitive review: The current provider cannot close material gaps, or the buyer needs evidence from other operating models.
- Do not renew yet: The provider has not supplied enough information to support the decision.
Important changes belong in the contract, statement of work, security addendum, response playbook, or another controlled document referenced by the agreement. A promise made in the renewal meeting can disappear after signature.
Update your incident response plan at the same time. If the contract says the MSP can isolate endpoints but the plan tells employees to wait for the CIO, the conflict will show up at the worst possible moment.
Ask the provider to prove the handoff
Finish the review with a tabletop exercise. Pick one scenario and walk it from the first alert through recovery. Use the real phone numbers, ticket paths, roles, tools, and approval limits.
Stop whenever someone says, “I think they handle that.” Find the answer. Record it. Assign it.
You do not need the MSP to own everything. You need the managed service, internal team, and other providers to operate as one response system when the pressure is real.
If your managed IT agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, current scope, invoices, and escalation terms. Catch Advisors will help you identify what is owned, what is missing, and what needs to change before you sign another term.