Monday - Friday 9AM – 6PM EST
Handing support or infrastructure work to another firm puts your client's systems in someone else's hands. A few simple questions produce a document you can send out today.
Choose the state or form type you need to start.
Answer a few simple questions to customize your form.
Download or print your custom document in PDF or Word.
An IT subcontractor agreement sets terms between a service provider and another firm delivering part of the service. It records the scope, the response times, and the rules for touching client systems.
Most IT subcontracting runs on an ongoing basis rather than a project basis. Overflow tickets, after-hours cover, a specialist skill, or a site too far to drive all push work outward.
The exposure differs from a build contract. Your subcontractor holds credentials to systems you promised to protect. Access and data terms therefore carry more weight than deliverables.
Your client keeps their contract with you. Whatever the subcontractor does or fails to do, the duty to answer stays with you.
IT subcontracting takes three shapes, and the agreement shifts with each one.
Managed services cover an agreed estate for a recurring fee. Scope comes from what the subcontractor monitors and maintains, not from tickets closed.
Project work has a start, an end, and a deliverable. Migrations, rollouts, and network builds all sit here.
Break-fix gets called in as needed and billed by time. Rates, minimum charges, and travel matter far more than service levels.
Name which one you are buying before anything else. A managed rate applied to a migration loses money quickly, and a project scope will not cover a Tuesday outage.
Exclusions matter as well. End-user training, vendor liaison, and hardware procurement all get assumed into managed contracts when nobody excludes them.
Volume shapes the document too. A handful of overflow tickets a month needs less structure than a subcontractor carrying your entire after-hours queue.
Service levels are the product in managed IT. So define them precisely rather than describing them as prompt.
Agree what counts as critical, high, and routine. A shared definition stops everything arriving marked urgent.
Separate the two. Response means somebody picks it up. Resolution means the problem ends, and only one of those sits within the subcontractor’s control.
State the hours, the after-hours arrangement, and how a callout gets triggered. Say who pays for attendance outside normal cover.
Name the people and the timings. An escalation route nobody rehearsed fails at two in the morning.
Say which system of record measures performance and who reports on it. Ticket data living in the subcontractor’s own tool needs a sharing arrangement.
Decide what follows when targets slip. Service credits are common, though a written fix-it plan often serves you better than a discount. Also agree how often you review the targets themselves.
Your subcontractor will hold keys to systems you do not own. An IT subcontractor agreement should treat that as the central risk.
Grant the minimum access the work needs, then record what you granted. Blanket domain admin for a helpdesk queue is how incidents begin. Review the grant list every quarter, since access creeps upward and never downward.
Require named technicians rather than a shared login. Shared credentials remove any chance of tracing an action later.
Set the baseline: multi-factor authentication, managed endpoints, screened staff, and a password vault. Say who audits compliance and how often.
Confirm whether your subcontractor may pass work to another firm, and whether delivery may happen outside the country. Your client contract may forbid both.
Require immediate notice when a technician leaves the account. Then set a deadline for revoking every credential once the arrangement ends.
Data obligations flow down from your client contract. So read that first, then write these terms to match it rather than to match your subcontractor’s standard paper.
Cover at minimum:
Breach notice deserves its own clause. Your own reporting duties run on a clock. You cannot meet them when the subcontractor takes a week to mention an incident.
Tip: Ask which of your subcontractor’s own suppliers touch the data. A tidy agreement with a firm that quietly routes everything through a fourth party solves less than it appears to.
Privacy and breach-reporting obligations vary by jurisdiction and by sector. So confirm what applies to your client’s data before you set any notice period.
Managed arrangements end. What matters then is whether you can run the estate without the firm that just walked away.
Say which monitoring, ticketing, and backup tools apply, and who holds the licenses. Tools bought under the subcontractor’s own agreement usually leave when they do.
Name who buys per-seat licenses and whose name sits on the subscription. Licensing held inside a subcontractor’s tenancy complicates every future move.
Require network diagrams, asset inventories, and runbooks kept current rather than written at the end. Documentation produced during an exit is rarely accurate.
Configurations, scripts, and documentation built for the client should transfer on payment. The subcontractor’s own reusable tooling generally does not, so draw that line.
Set a transition period, a handover checklist, and who attends. Also say what it costs, because unpaid exit work rarely gets done well.
Ask for technology errors and omissions cover alongside general liability. A pure liability policy may not answer a data claim.
Most of this takes one planning conversation. Put the outcome into an IT subcontractor agreement template before anybody issues a credential.
One place to build, sign, and manage documents.
