Start with responsibility, not a product list.
A managed security comparison becomes useful when the buying team can explain what it expects the provider to own. Write down the current gap, the systems in scope, the people who respond today, and the decision that needs approval. A service name alone is not a complete scope.
Describe the operating requirement.
List the locations, accounts, endpoints, cloud services, and working hours that matter to the project. Identify which information you can share at the first stage and which should wait for an appropriate agreement. Record constraints such as existing tools, internal approvals, and change windows.
Ask what happens after an alert.
Give each provider a scenario and ask it to walk through the handoffs. Who investigates? Who contacts your team? What action can be taken without separate approval? What remains outside the agreement? Capture the answers in writing so a future service review has something concrete to refer to.
Compare the full scope.
Use a shared comparison sheet with rows for coverage, onboarding, integrations, escalation, reporting, retained customer tasks, and exclusions. Add recurring costs and one-time work separately. Mark an unanswered item as unresolved rather than giving a provider the benefit of an assumption.
Bring the right people into the review.
The security owner may understand the technical requirement, while finance, procurement, operations, and legal teams see different dependencies. Identify the decision owner and the evidence each stakeholder needs. Agree which requirements are essential before looking at a shortlist.
Prepare the transition question.
Ask how service starts, how the provider validates the agreed scope, and who signs off onboarding. Establish how reporting and responsibilities will be reviewed after the initial deployment. Where contractual obligations matter, have the responsible specialists review them.
Use the checklist as a working document.
Assign an owner to every unresolved item. Take the completed requirements and open questions into the project review. The aim is to make a defensible buying decision, with the remaining responsibilities clearly understood.
Further reading: CISA recommends clearly defining provider and customer responsibilities when outsourcing IT services. Read the source ↗
Put the questions to work.
Create a brief for your own project, or explore the advisory scope.