Ask the questions that expose the working relationship.
Record the answer, the contract section that supports it, and who owns the next action. “We can help with that” is not the same as accepted responsibility.
-
Which users, devices, locations, systems, and vendors are inside the service?
Why it matters: support breaks down when covered assets and exclusions are implied instead of inventoried.
-
How do people request help, and how are priority and escalation decided?
Why it matters: named routes, coverage windows, and written commitments make the support model testable.
-
Who owns monitoring, approved patching, documentation, and recurring maintenance?
Why it matters: routine work needs an accountable owner and evidence that it happened.
-
Who coordinates internet, line-of-business software, copier, cabling, and other vendors?
Why it matters: users should not have to arbitrate technical vendors when the fault is unclear.
-
Where does managed IT stop and managed cybersecurity begin?
Why it matters: endpoint maintenance and helpdesk work do not automatically create a security program.
-
What reports, inventories, test results, and decision records will we receive?
Why it matters: evidence lets leadership review performance and risk without relying on memory.
Separate the service description from the proof.
A provider should be able to translate broad promises into a specific operating record.
Responsibility in writing
Covered users and assets, service routes, coverage hours, response commitments, exclusions, third-party costs, data ownership, security roles, and exit obligations.
Evidence in operation
Current inventory, ticket history, maintenance records, change documentation, backup and recovery tests, security review findings, and named owners for open work.
Judge the handoff before signing.
A responsible provider can explain both onboarding and offboarding. Your organization should retain access to its domains, tenant, data, configurations, credentials, documentation, and service records.
Inventory systems, accounts, vendors, contracts, and known risks.
Assign administrative access using named accounts and least privilege.
Document unresolved issues, accepted risks, dependencies, and priorities.
Define how credentials, records, and customer-owned data are returned at exit.
Use outcomes, not a product list, as the evaluation frame.
NIST recommends defining the cybersecurity outcomes you want, evaluating relevant experience and requirements, and documenting responsibilities and expectations in the managed-services agreement. Outsourcing work does not outsource the organization’s accountability for its information.
Decision record
For each provider, keep the proposed scope, exceptions, evidence supplied, open questions, total dependencies, and the person approving the residual risk.
Revisit the record when the environment, provider scope, regulation, insurance requirement, or business dependency materially changes.
Ask ICT Solutions to define what we would own.
Bring your current agreement, unresolved support problems, or provider shortlist. We will explain the managed IT boundary and put proposed responsibility in writing.
Or call (734) 772-9499 · A human answers