If you provide (or buy) tech services, you’ve probably seen both an “IT Service Agreement” and an “IT Support Agreement” floating around - and it’s not always obvious why you’d need one versus the other.
The tricky part is that these documents can look similar on the surface, but they usually cover different work, different risks, and different ways you get paid. If you choose the wrong one (or try to squeeze everything into a one-page template), you can end up in disputes about scope, response times, fees, or who’s responsible when something breaks.
This guide is updated to reflect how modern IT businesses and customers typically operate now, especially with remote support, cloud services, and ongoing subscriptions becoming the norm. Let’s break down what each agreement does, where they overlap, and how to set your business up with the right legal foundations from day one.
What Is An IT Service Agreement?
An IT Service Agreement is usually the “main contract” for delivering a defined IT project or professional service.
Think of it as the agreement that answers:
- What are we building or delivering?
- When will it be delivered?
- How much will it cost, and how will payment work?
- What happens if something changes mid-project?
- Who owns the work and intellectual property?
Common examples where an IT Service Agreement makes sense include:
- website development or rebuilds
- software development or custom integrations
- cloud migration projects
- cybersecurity assessments and remediation projects
- network setup or infrastructure changes
- data migration or system implementation
Key Clauses You’ll Usually See In An IT Service Agreement
While every business is different, most IT Service Agreements will include terms around:
- Scope of services (what is included, and what is not)
- Deliverables and milestones (including acceptance testing where relevant)
- Fees and invoicing (fixed price vs time and materials, deposits, payment terms)
- Change control (how scope changes are quoted, approved, and billed)
- Customer responsibilities (access, approvals, data, timely feedback)
- Intellectual property (IP) (who owns code, configurations, documentation, and what is licensed)
- Confidentiality (especially where you handle business-sensitive information)
- Liability and risk allocation (caps, exclusions, and how consequential loss is treated)
- Warranties and what happens if the work isn’t up to standard
- Termination (what if the relationship ends early?)
If your IT business provides broader managed services, your IT Service Agreement often works best as the “umbrella” contract, with a service schedule or statement of work attached. In practice, many businesses use a tailored IT Service Agreement as the base, then swap in project schedules as needed.
What Is An IT Support Agreement?
An IT Support Agreement is usually designed for ongoing support and maintenance, rather than a one-off project.
It’s the agreement that answers questions like:
- What support do you provide day-to-day?
- What are your response times?
- How does the customer log support requests?
- What’s included in the monthly fee (and what’s extra)?
- When can the customer terminate?
Typical situations where an IT Support Agreement fits include:
- helpdesk support for staff
- remote monitoring and maintenance (RMM)
- patch management and updates
- endpoint protection and basic cybersecurity monitoring
- user account management and access control
- backup monitoring and restore support
- support for Microsoft 365 / Google Workspace environments
Why “Support” Needs Its Own Agreement
Support work has a different risk profile to project work.
In a support context, the customer is often relying on you to keep their systems working. That means the contract needs to be clear about things like:
- Service levels (response times, resolution targets, outage priorities)
- Support hours (business hours vs after-hours and emergency support)
- Exclusions (for example: third-party outages, customer hardware failures, unsupported software)
- What happens during major incidents (communication, escalation, decision-making)
- Costs for onsite visits (if applicable)
This is where a Service Level Agreement (SLA) often comes in - either built into the IT Support Agreement or attached as a schedule.
IT Service Agreement vs IT Support Agreement: What’s The Practical Difference?
The quickest way to think about it is:
- IT Service Agreement = “We will deliver this piece of work (a project or defined service).”
- IT Support Agreement = “We will support and maintain your systems over time.”
Here are the differences that usually matter most in real life.
1. Scope: Deliverables vs Ongoing Outcomes
In an IT Service Agreement, the scope is often deliverable-based (e.g. “build X integration” or “migrate Y environment”). Success is usually measured by whether the deliverables meet the agreed requirements.
In an IT Support Agreement, the scope is usually service-based (e.g. “provide remote support,” “monitor endpoints,” “apply updates”). Success is measured by performance over time, often using SLAs.
2. Pricing: Project Fees vs Subscription/Retainer
IT Service Agreements often involve:
- fixed fees per milestone
- time and materials (hourly/daily rates)
- deposits and progress payments
IT Support Agreements often involve:
- monthly recurring fees
- per-user or per-device pricing
- bundles (e.g. support + security tooling)
- overage charges for out-of-scope work
3. Timeframes: A Defined End Date vs Rolling Terms
A project-based IT Service Agreement may end on completion, or after a short warranty/defects period.
An IT Support Agreement is commonly ongoing, with:
- a fixed initial term (e.g. 12 months), then renewal
- or a month-to-month arrangement with notice
If you have staff dedicated to servicing the customer (or you’re offering discounted onboarding), the term and termination provisions become a big deal - you’ll want certainty and a fair exit process.
4. Risk And Liability: “Build” Risks vs “Keep Running” Risks
With an IT Service Agreement, disputes often arise from:
- scope creep
- unclear acceptance criteria
- delays caused by late customer feedback
- ownership of code/configurations
With an IT Support Agreement, disputes often arise from:
- downtime and business interruption
- unclear response times
- customers expecting you to fix third-party issues
- cyber incidents and responsibility for preventative controls
That’s why it’s important to draft the contract around the actual service you’re providing - not just what “sounds right.”
Do You Need Both Agreements (Or Just One)?
Sometimes you need one, sometimes you need both, and sometimes you need a combined structure with clear schedules.
A helpful way to decide is to ask: Are you being engaged for a one-off delivery, or an ongoing relationship?
When An IT Service Agreement Alone Might Be Enough
You may only need an IT Service Agreement if you:
- do primarily project work (web builds, migrations, implementations)
- don’t offer ongoing helpdesk or monitoring
- hand over deliverables and then disengage
Even then, you’ll usually want a short support/warranty clause explaining what happens if bugs are found, how long you’ll fix defects for, and what is excluded (for example, changes requested after sign-off).
When An IT Support Agreement Alone Might Be Enough
You may only need an IT Support Agreement if you:
- provide ongoing support and maintenance
- are essentially the customer’s outsourced IT department
- don’t take on major “build” or implementation projects (or you quote them separately)
In practice, many support providers still run into project-type work (e.g. onboarding, new office setup, tenant migrations). If that’s you, you’ll want your agreement to explain how project work is scoped and charged, so it doesn’t quietly eat your margins.
When You’ll Usually Need Both
You’ll commonly need both if you:
- sell managed services and also deliver project work
- provide onboarding or a “setup project” before ongoing support starts
- regularly do upgrades, implementations, or security uplift projects for existing support clients
One common structure is:
- an umbrella IT Services contract (general legal terms)
- a support schedule (pricing, SLAs, inclusions/exclusions)
- project statements of work (scope, timeline, milestones)
This structure reduces contract admin while still keeping scope and pricing clear.
What Clauses Matter Most In Each Agreement (And Where Disputes Usually Start)
Most disputes don’t start because someone is “bad” - they start because expectations weren’t written down clearly.
Here are the areas we see causing the most issues.
Scope, Scope, Scope (Yes, It’s That Important)
For project work, your contract should clearly set out:
- what is included in the fee
- assumptions (for example, “customer provides content by X date”)
- what is out of scope
- how changes are handled
For support work, your contract should clearly set out:
- what counts as a “support request”
- how requests are logged and prioritised
- what is included in the monthly fee
- what is chargeable (and at what rate)
If you’re running any kind of platform or recurring service, it can also be useful to align your support commitments with broader Managed Services Agreement style terms (even if you don’t call it that publicly), so the ongoing service obligations are properly captured.
Service Levels And Response Times
Customers often assume “support” means instant response. Providers often assume “support” means “we’ll get to it when we can.” Neither approach is fair if it was never agreed.
A good support agreement (or SLA) typically covers:
- support hours (and public holidays)
- how urgent issues are defined (priority levels)
- response time targets vs resolution time targets
- customer obligations (e.g. having a key contact available)
And importantly - it should be clear whether these are strict guarantees, targets, or best endeavours commitments.
Privacy And Data Handling (Especially For Remote Access)
IT providers frequently handle personal information (even accidentally), such as employee records, customer lists, or emails. In New Zealand, the Privacy Act 2020 is the key law you need to have on your radar, including obligations around protecting data and reporting notifiable privacy breaches where required.
If your services involve accessing customer systems, monitoring devices, or processing data on their behalf, it may make sense to document how that data is handled and secured - sometimes via a Data Processing Agreement, depending on the relationship and what information is involved.
On the customer side, if you collect any personal information (even just through a support portal), having a clear Privacy Policy helps set expectations and shows you’re taking compliance seriously.
Cybersecurity Limits: What You Do (And Don’t) Promise
Customers often expect their IT provider to prevent all cyber incidents. Realistically, no provider can promise that.
Your agreement should clearly address things like:
- what security services you provide (and what you don’t)
- whether you manage backups and what “successful backup” means
- what happens during incidents (containment steps, escalation, third-party involvement)
- what the customer must do (for example, MFA adoption, staff training, device policies)
This is also where liability wording matters. The goal isn’t to “get out of everything” - it’s to allocate risk in a way that matches the price and the service.
Most IT businesses rely on third-party vendors (cloud hosting, RMM tooling, ticketing systems, antivirus). You should be clear about:
- which third-party tools you use
- whether outages from those tools are within your control
- how third-party fees are passed on (if applicable)
If you engage other specialists (for example, cabling contractors or penetration testers), your agreement should cover subcontracting and who is responsible for their work.
Which Laws Do These Agreements Touch In New Zealand?
Even though these are “business-to-business” contracts most of the time, you can’t ignore the wider legal environment you’re operating in.
Some key legal areas that commonly come up for IT service providers in New Zealand include:
Contract Law (And Enforceability)
Your agreement is there to make expectations clear and enforceable. If the scope, payment terms, and responsibilities are vague, it becomes much harder to resolve disputes quickly.
This is why a properly drafted contract (instead of a generic template) is so important - especially when you’re dealing with complex services, multiple stakeholders, or sensitive systems.
Fair Trading And Misleading Representations
If you advertise services (on your website, proposals, or sales calls), you need to be careful not to overpromise. In New Zealand, the Fair Trading Act 1986 can apply to misleading or deceptive conduct in trade.
For example, saying “fully secure” or “guaranteed uptime” might sound good in marketing, but it can create legal risk if your contract doesn’t back it up or if it’s not realistic.
This is also why it’s worth having clear written terms that match your sales process - whether that’s a standalone service contract or broader Business Terms you use across customers.
Privacy Act 2020
As mentioned above, if you access or handle personal information (employee data, customer data, emails, IP addresses, device identifiers), you need to take reasonable steps to protect it. This usually means having clear internal processes as well as contract terms about:
- access controls
- confidentiality obligations
- secure handling and storage
- breach notification steps
Employment/Contractor Considerations (If You’re Scaling)
If you’re growing your IT business and hiring technicians, consultants, or developers, your internal documents matter too. A well-drafted Employment Contract (or contractor agreement) can help clarify IP ownership, confidentiality, and expectations - which ties directly into what you can confidently promise customers.
This might not be part of your customer agreement, but it’s a big part of being protected from day one.
Key Takeaways
- An IT Service Agreement is usually best for project-based work with defined deliverables, timelines, and change control.
- An IT Support Agreement is usually best for ongoing support and maintenance, with service levels, response times, and clear inclusions/exclusions.
- The biggest differences tend to be scope (deliverables vs ongoing services), pricing (project fees vs monthly recurring), and risk allocation (build risks vs downtime and incident risks).
- Most disputes start with unclear expectations, so strong drafting around scope, SLAs, out-of-scope work, and termination is crucial.
- If you access customer systems or handle personal information, you should consider your Privacy Act 2020 obligations and whether you need privacy-specific documents alongside your contract.
- It’s rarely a good idea to DIY these agreements - IT contracts should reflect how you actually deliver services, how you charge, and what risks you can realistically take on.
If you’d like help putting the right IT contracts in place (or reviewing what you’re currently using), you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.
