By Dan Stark
Imagine a class ready to begin an online assessment, but several students can’t sign in. The devices turn on, the internet connection works and the testing platform reports no outage. Who checks the accounts, brings in the right vendor and confirms those students can get started?
That answer belongs in writing. Managed IT services for schools should have a defined scope covering the systems, people, support hours and handoffs the school needs. Before you compare proposals, pin down what the school keeps, what the provider handles and where another vendor comes in.
The worksheet below gives school leaders and internal IT teams a way to record those decisions before signing or renewing an agreement.
What should managed IT services for schools cover?
Start with the work that has to happen: students get to their lessons, staff join and leave, devices stay usable, office systems keep running and important data can be recovered. Then list the accounts, applications, networks and vendors each workflow depends on.
A service label like “device management” can describe very different agreements. One might cover configuration and updates but leave repairs, replacement devices and warranty claims to someone else. Spell out those boundaries.
This approach works whether a provider handles most of the technical work or shares it with school staff. If you haven’t settled the staffing model yet, our guide to internal, outsourced and co-managed IT support covers that separate decision.
For each workflow, separate four assignments:
- Approval: Who can authorize access, spending or a disruptive change?
- Execution: Which technical tasks belong to school staff, the provider or another vendor?
- Coordination: Who tracks the combined request, gets decisions and keeps people informed?
- Validation: Who confirms the affected school task works again?
One person can hold several assignments. But naming a coordinator doesn’t automatically give that person approval authority.
Follow accounts and devices beyond setup
Student enrollment, course changes, new hires and substitute assignments can trigger different access changes. For each group, identify the source record, the authorized approver and the person who corrects inaccurate information.
An automated account process still needs someone to handle exceptions. Ask who finds missing or duplicate accounts, investigates failed updates and confirms approved changes reached the right systems. Cover departures and transfers too, including who decides what happens to files, licenses and access.
Devices need the same follow-through. Consider a laptop rollout where every device was delivered, but the agreement never assigned damaged-device intake or replacement stock. Delivery is complete, but repair ownership is still undefined.
CoSN’s report on student device sustainability ties together inventory, repairability, lifecycle planning and disposal. Use that wider view when you define support:
- Name who maintains the device inventory and handles failed updates.
- Assign repairs, warranty cases, shipping and loaner devices.
- Define who recommends retirement and who approves replacement spending.
- Require a rollout handoff that shows configuration, ownership and unresolved exceptions.
These tasks can sit with different teams. The agreement should show where each handoff happens.
Define the handoff when several systems are involved
Back to the assessment problem. A working internet connection doesn’t prove an account has the right access or that a device can reach the required application.
Name the person who coordinates checks across school staff, the IT provider and the application vendor. Separately, identify who holds each vendor contract and who’s authorized to open a support case. Coordination alone doesn’t change a vendor’s obligations.
Break network management into its parts: wireless, switches, firewalls, cabling and the internet circuit. Ask when remote testing is enough, when someone has to be in the building and who arranges that visit.
Keep vendor case numbers, next actions and school communications attached to the combined issue. Decide who checks the affected classroom or office workflow once the technical work is done. Then run the same exercise for administrative work such as attendance and payroll.
Plan support around the school calendar
Give prospective providers the dates that change the work: enrollment periods, staff return, assessments, summer programs and planned building work.
If your school uses Bluebook, College Board’s readiness checklist covers network and device preparation, test administration setup and a final readiness check. Assign the tasks for the testing program your school actually uses. Don’t assume one platform’s requirements match another’s.
For each critical period, define:
- Routine coverage: Included work, hours, intake channels and escalation.
- Project work: Rollouts, migrations or other changes that need separate scope, pricing and acceptance.
- On-site work: Tasks that need someone in the building, plus site access and advance arrangements.
- Additional coverage: How work outside normal hours is requested, authorized and charged.
School breaks can still mean classes, construction or limited building access. Agree on maintenance windows, communication and rollback plans, plus a separate process for urgent security changes. A busy calendar shouldn’t leave urgent security work without an owner.
Our guide to IT support response times can help you define what a response commitment means and when its clock runs.
Make security and recovery responsibilities explicit
List the security systems included in support, who reviews their alerts and when. Identify who can take urgent containment action, who approves other disruptive changes and how school leadership is informed. Agree on any preauthorized action before an incident.
Student-data access needs its own review. Where FERPA applies, using the school official exception requires an outside provider to perform a function the school would otherwise assign to employees and remain under the school’s direct control over education-record use and maintenance. The provider must also use disclosed information only for its permitted purpose, follow redisclosure limits and meet the school or district’s annual-notice criteria for a school official with a legitimate educational interest. The school must confirm that these conditions are met before allowing the provider access under this exception. The Department of Education explains those conditions.
State law, school policy and contract terms may add requirements. Have the school’s privacy or legal contact confirm the applicable access basis and requirements, then translate them into the provider’s permissions and duties.
The NIST Cybersecurity Framework includes maintained and tested backups among its outcomes. For backup and recovery planning, identify the data and applications covered, including what cloud vendors handle. Define who authorizes a restore, who performs it, which tests are required and who checks the recovered school workflow. Ask for the results and any unresolved issues. Testing one system doesn’t prove the rest can be recovered.
Tie reporting to decisions: failed updates that need attention, unresolved access exceptions, incomplete recovery tests and corrective work with an owner. Ask for evidence that fits the task, not a generic monthly assurance that everything is healthy.
Use this school IT scope worksheet
Copy this record for each critical workflow. Start with the ones that would interrupt teaching, administration or access to important records. Ask each provider to respond to the same fields.
This is a planning tool, not a formal standard or a CTMS contract. Mark unresolved items for agreement. Don’t assume they’re included.
| Field | What to record |
|---|---|
| Workflow and impact | The school task, connected systems, affected people and consequence of disruption. |
| School responsibilities | Approval authority, source-data ownership and technical work retained internally. |
| Provider responsibilities | Specific recurring tasks, monitoring, troubleshooting and documentation. |
| Other vendors | Their technical role, who holds the contract and who can open or escalate cases. |
| Coordinator | Who tracks the combined work, follows up and reports progress. |
| Coverage and calendar | Hours, important dates, change windows, on-site arrangements and additional coverage. |
| Evidence and acceptance | Required records, test results, completion criteria and the person who validates the workflow. |
| Exclusions and project triggers | Work outside the recurring fee, dependencies, additional charges and changes requiring a separate proposal. |
| Open decisions | Unassigned work, the person resolving it and the decision date. |
Completed example: student course access
This hypothetical allocation shows the worksheet filled in. It isn’t a CTMS service commitment or a reported client incident.
- Workflow and impact: Enrollment records feed the school’s account and learning systems. An incorrect course assignment can lock a student out of lessons.
- School responsibilities: The registrar corrects enrollment records. The school’s application owner approves access exceptions. Internal IT keeps account-policy decisions.
- Provider responsibilities: The provider checks scheduled synchronization results, investigates access failures and records unresolved exceptions.
- Other vendors: The learning-platform vendor investigates errors within its application. The school holds the vendor contract and authorizes the provider to open cases.
- Coordinator: The provider’s service coordinator tracks the combined issue and updates the school’s application owner. That role can’t approve course access.
- Coverage and calendar: In this example, support runs from 7 a.m. to 4 p.m. on school days, with a scheduled access check before term starts. Additional hours and on-site attendance need separate arrangements.
- Evidence and acceptance: Synchronization results, the exception list and the vendor case record. The school’s application owner confirms affected students can reach their assigned courses.
- Exclusions and project triggers: Enrollment corrections stay with the school. Replacing the learning platform needs a separate project scope. Vendor software changes stay with the vendor.
- Open decisions: The school’s application owner will confirm additional first-day coverage with the provider before the term-start plan is approved.
Compare the work before comparing the price
Review the completed records for missing assignments, conflicting hours and dependencies nobody has accepted. Separate recurring fees from projects, vendor subscriptions, equipment and on-site or additional-hours charges so you’re comparing the same work.
A proposal can cost less because the school keeps more of the responsibility. That can work when the school has the capacity and authority to carry it. Make that choice on purpose.
CTMS provides IT support for schools and education organizations and can work alongside internal teams through its managed and co-managed IT services. Specific tasks, coverage and on-site arrangements depend on the agreed scope.
If you’re reviewing or renewing outside support, talk with CTMS about your school IT scope. Bring your list of systems, current responsibilities and upcoming school dates.
