This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Read More
Short answer: a managed IT provider handles only the systems, users, locations, support periods, security tasks, recovery tasks, and projects named in the agreement. The label does not define the scope. A useful proposal identifies what the provider operates, what the customer retains, what is shared, and what is excluded.
This FAQ was reviewed on August 18, 2026. It uses current NIST and CISA guidance and does not promise uninterrupted service, complete security, compliance, recovery, savings, or a fixed response time. NIST explains that the Cybersecurity Framework 2.0 is flexible risk-management guidance, not a one-size-fits-all service specification. Buyers should translate desired outcomes into a written responsibility matrix and acceptance evidence.
Common scope areas include the service desk, user accounts, endpoints, Microsoft 365, servers, networks, monitoring, patching, cybersecurity coordination, backup oversight, recovery planning, vendor coordination, and technology planning. Rivell’s managed IT services in New Jersey page owns the commercial service intent. Related scope may also involve business IT services, cloud hosting, VoIP services, infrastructure assessment, or video surveillance, but those services should not be assumed unless the agreement includes them.
Managed IT generally assigns a provider broad ownership of agreed day-to-day technology operations. Co-managed IT keeps an internal technology team in place and divides work between that team and the provider. Either model can be narrow or broad. The important distinction is who approves, performs, monitors, escalates, documents, and verifies each task.
CISA’s risk considerations for MSP customers recommends defining provider, customer, and shared responsibilities in the vendor agreement. A shared label without one accountable owner for each outcome creates gaps. The agreement should also define handoffs, access boundaries, support hours, evidence, and the process for resolving ownership disputes.
Use Rivell’s co-managed IT shared responsibility guide for the operating-model comparison. The separate co-managed IT service page describes the commercial path. An organization should choose the model that matches its internal authority, staffing, specialist needs, coverage requirements, and willingness to retain operational responsibility.
Require the proposal and agreement to define staffed hours, monitored hours, on-call coverage, holidays, remote and onsite boundaries, supported locations, supported systems, ticket channels, and third-party escalation. Monitoring is not the same as a staffed service desk, and an acknowledgement is not the same as a workaround or final resolution.
Severity and priority should be tied to business impact, security risk, affected users, and available workarounds. For each level, document the acknowledgement target, response target, escalation path, communication cadence, customer dependencies, and any exclusions. Ask how the clock is paused, when a ticket can be downgraded, what evidence appears in reports, and what remedy or review follows a missed commitment.
The CISA-led MSP and customer advisory recommends transparent contractual arrangements and clear responsibilities. Rivell’s 24/7 IT support coverage guide explains monitored, on-call, and staffed models. The New Jersey IT support page describes the commercial support path.
The customer retains governance and business-risk decisions even when a provider performs security tasks. The provider should identify its controls, tools, subcontractors, remote-access methods, logging boundaries, incident duties, and customer dependencies. The agreement should state who owns identity, endpoint protection, patching, email security, network controls, vulnerability handling, security awareness, incident response, and regulatory coordination.
The CISA-led MSP advisory recommends multifactor authentication, secured remote access, monitoring and logging, incident-response planning, and supply-chain risk management. Ask whether technicians use named accounts, how privileged access is approved and removed, whether customer environments are separated, how remote-management tools are protected, where logs are retained, and how the provider reports incidents that affect its systems or subcontractors.
Security language should describe evidence, not absolutes. Request current reports or attestations that match the proposed service, documented access reviews, incident exercises, remediation tracking, and a shared-responsibility matrix. Rivell’s cybersecurity services page is the commercial owner for security services. A managed IT agreement should not be treated as proof of compliance or complete protection.
List every protected workload, data owner, backup method, schedule, retention rule, storage location, encryption expectation, monitoring duty, failure-response path, and restore-test cadence. Define who approves deletions and retention changes, who can start a recovery, and who confirms that restored systems are usable. A successful backup job does not by itself prove that an application, identity service, or business process can be recovered.
Recovery time objective and recovery point objective are planning inputs, not universal guarantees. They should be set by workload and validated against architecture, dependencies, connectivity, staffing, vendor limits, and test evidence. NIST SP 800-34 Rev. 1 provides contingency-planning guidance covering business impact analysis, recovery strategies, plans, testing, training, and maintenance.
Ask for recent restore-test evidence, unresolved failures, escalation records, dependency maps, recovery runbooks, and the conditions that can extend a recovery. Rivell’s data backup service and disaster recovery service describe the related commercial paths. Contract language should distinguish backup operations from full business recovery.
Onboarding should create an agreed operational baseline before routine ownership transfers. Typical work includes inventorying users, devices, servers, networks, cloud tenants, applications, vendors, licenses, domains, certificates, backups, security tools, support channels, privileged accounts, and existing documentation. The provider and customer should identify unknowns, expired access, unsupported systems, urgent risks, and business-critical dependencies.
The plan should name owners, milestones, customer duties, change windows, communication paths, acceptance checks, and a rollback or escalation path for each material transition. Ticket routing, monitoring coverage, backup alerts, access approvals, vendor contacts, and after-hours procedures should be tested. If another provider is involved, document credential transfer, tool removal, data return, open tickets, unresolved risks, and the date each responsibility changes hands.
NIST SP 800-161 Rev. 1 provides current cybersecurity supply-chain risk guidance. NIST SP 1326 adds a supplier due-diligence quick-start guide covering ownership, provenance, resilience, foundational practices, and supply-chain tiers. Apply that due diligence to the provider, its core platforms, remote-management tools, security products, cloud dependencies, and subcontractors.
Compare proposals using the same inventory and requested outcomes. Pricing can be per user, per device, per site, tiered, or custom. The model matters less than the exact scope behind it. Record included users, devices, locations, tools, licenses, support hours, onsite work, projects, procurement, security tasks, backup operations, recovery work, onboarding, documentation, reporting, and vendor coordination.
Then list exclusions and variable charges. Common differences include after-hours labor, travel, hardware, licensing, project work, security incidents, recovery events, major upgrades, unsupported systems, custom applications, third-party vendor work, and contract transition. Review renewal, price-change, minimum-term, termination, data-return, tool-removal, transition-assistance, confidentiality, subcontractor, incident-notification, and liability language with qualified advisors.
Use Rivell’s managed IT pricing guide to structure quote inputs. The MSP versus MSA guide explains the difference between the provider and the contract documents. Do not assume that a flat fee includes every service or that a lower monthly price produces a lower total operating cost.
Request proof that matches the proposed scope. Useful evidence can include a sample service description, responsibility matrix, escalation model, onboarding plan, reporting example, access-control process, incident-response duties, backup and recovery test evidence, subcontractor list, current certification or assessment reports, insurance evidence, and references for comparable environments. Redacted examples are reasonable when customer confidentiality applies.
NIST’s supplier due-diligence guidance supports researching ownership, provenance, resilience, foundational cyber practices, and supply-chain tiers. Ask who owns the provider, where services are delivered, which platforms and subcontractors can reach customer systems, how resilience is tested, how material changes are communicated, and what happens to customer data and tools at contract exit.
Rivell publishes a managed IT provider comparison, a deeper list of questions to ask a managed IT company, case studies, and partner and certification evidence. Confirm that any proof is current, applies to the proposed service and delivery team, and has not expired or changed. Use the evidence to narrow the next conversation, then document unresolved assumptions in the proposal and agreement.
