You have received a draft IT services agreement from a supplier, or you are about to send one out. Either way, the contract sitting on your desk will govern what you actually receive, what happens when things go wrong, and who is responsible if your customers' data is mishandled. The supplier's standard form is written to protect the supplier. Your job — or your lawyer's job — is to make it work for you.
IT services contracts cover a wide spectrum: a one-off software build, a long-term SaaS subscription, managed infrastructure, or a combination of all three. What they share is a set of recurring clause types that, drafted well, give you genuine remedies; drafted poorly, they leave you absorbing risk you did not knowingly accept.
The essential clauses
What you are actually receiving
Before anything else, the contract must precisely describe the services or deliverables. Vague scope descriptions are the single most common source of IT contract disputes. If the supplier is providing access to software, the licence clause should state:
- who within your organisation can use it (named users, concurrent users, or enterprise-wide)
- whether sub-contractors or related entities are included
- any restrictions on use — territory, purpose, volume
- what happens to access if you end the contract early
Where a third-party platform underpins the services — cloud hosting, a payment gateway, a mapping API — the contract should name it and address what the supplier is responsible for if that third party fails, discontinues the product, or changes its pricing. A clause that broadly excludes supplier liability for third-party components is a significant red flag if those components are central to what you are buying.
Harmful code warranty
Any time a supplier's software or code will be integrated into your systems, or delivered to you as a standalone product, you want an express warranty that the deliverables are free from harmful code. This covers viruses, malware, spyware, code that enables unauthorised access, and anything designed to corrupt or destroy data.
The clause should include:
- a warranty from the supplier that no harmful code will be introduced into your systems or deliverables
- the security procedures the supplier must maintain to prevent it
- an obligation to notify you immediately if harmful code is discovered
- an obligation to remediate at the supplier's cost, including reversing any damage caused
Supplier-drafted contracts rarely include this clause unprompted. You will need to negotiate it in.
Service levels and service credits
A service level agreement (SLA) transforms a supplier's aspiration into a contractual obligation. Watch for softening language: "the supplier will endeavour to maintain 99% uptime" is not an obligation — it is a best-efforts qualifier that is practically unenforceable. The clause should read as a firm commitment: "the supplier will maintain 99% uptime."
Key elements to negotiate into a service level clause:
- Uptime percentage — defined and calculated consistently (check whether scheduled maintenance windows are excluded from the calculation; some formulas inflate the apparent uptime figure)
- Response times — tiered by severity, so a critical outage triggers a faster response than a minor glitch
- Restoration times — the maximum time within which service must be restored after an incident
- Service credits — a discount mechanism that kicks in automatically when the supplier misses a service level, without requiring you to litigate
Service credits are commercially useful but they are not a complete remedy. You should also negotiate a right to terminate for cause if the supplier repeatedly misses service levels — credits alone do not solve the problem of a supplier who consistently cannot perform.
Acceptance testing
Where the supplier is building or delivering something — a bespoke software application, a configured platform, an integrated data solution — you need a right to test it before you are treated as having accepted it.
The acceptance testing clause should specify:
- what tests you will run and against what documented specifications
- the timeframe you have to conduct testing after delivery
- what happens if the deliverables fail: the supplier's obligation to rectify at no additional charge, the timeframe for rectification, and your right to re-test
- your right to terminate and seek a refund if the deliverables repeatedly fail to meet specifications
Without this clause, a supplier can argue that your silence or continued use of a defective product constitutes acceptance. Do not let that gap exist.
Warranty against defects
Acceptance testing gets you past the delivery point; a warranty against defects covers what happens after. Suppliers typically offer a warranty period — often three months from acceptance — during which they will fix defects at no charge. Three months is a short window for complex software; negotiate a longer period where the contract value warrants it.
Things to check in a defects warranty:
- Exclusions — most warranties void if you modify the deliverable without the supplier's consent; confirm whether minor configuration changes trigger the exclusion
- What counts as a defect — is it limited to non-conformance with the documented specification, or does it cover fitness for purpose more broadly?
- Claim process — what information must you provide, within what timeframe, and what access must you give the supplier (remote access, on-site access) to investigate?
Where the Australian Consumer Law (Schedule 2 of the Competition and Consumer Act 2010 (Cth)) applies, statutory guarantees about the quality of services and fitness of goods operate independently of the contractual warranty. A contractual warranty that purports to replace or limit those statutory guarantees is unenforceable to the extent it does so.
Ongoing support obligations
For SaaS and managed services engagements, support is not optional — it is part of what you are paying for. The contract should define:
- the support channels available (phone, email, ticketing system, dedicated account manager)
- the hours during which support is available — particularly relevant if your business operates outside standard business hours or across time zones
- the service levels that apply to support requests (tied to the severity framework in the SLA)
- the supplier's obligation to provide support in a professional and timely manner
If support is covered by a separate schedule or order form, confirm that it is incorporated into the main agreement by reference and that it is enforceable.
Privacy and data handling
If the IT services involve the supplier accessing, storing, or processing personal information that you hold, privacy is not optional — it is legally mandated. Under the Australian Privacy Principles (APPs) set out in the Privacy Act 1988 (Cth), APP entities must take reasonable steps to ensure that third parties handling personal information on their behalf do so in accordance with the APPs. A contract clause is one of those steps.
A comprehensive privacy clause should address six things:
Access controls. The contract should specify on what basis the supplier and its staff — including sub-contractors — may access personal information. A "need to know" limitation, combined with a requirement for prior written approval for any new personnel, gives you ongoing control.
Security standards. The supplier should be required to implement and maintain appropriate technical and organisational security measures. You can reference your own internal security standards, or require compliance with a recognised framework such as ISO/IEC 27001. Where sensitive personal information is involved, requiring data to be stored in an encrypted or pseudonymised form reduces exposure in the event of a breach.
Legal compliance. The contract should require the supplier to comply with all privacy laws applicable to you, not just those applicable to the supplier's own business. This matters because you may be bound by the APPs even if the supplier, as a sub-$3 million turnover business, is not. The clause should make the supplier responsible as if it were an APP entity for the purpose of handling your data.
Cross-border disclosure. If the services involve storing or processing data offshore — including on servers in the United States or elsewhere — the contract should specify approved locations and prohibit disclosure or storage outside those locations without your written consent. APP 8 imposes obligations on APP entities when personal information is disclosed overseas; your contract should give you the means to manage that risk.
Notifiable data breach obligations. Under Part IIIC of the Privacy Act 1988 (Cth), entities covered by the Act must notify the Office of the Australian Information Commissioner (OAIC) and affected individuals of an eligible data breach. Your contract should require the supplier to:
- notify you immediately of any actual or suspected data breach, whether or not it meets the threshold for mandatory notification
- cooperate with your assessment of whether notification is required
- clarify who is responsible for notifying the OAIC and affected individuals
- implement a disaster recovery or incident response plan to limit service disruption
Consequences of breach. The contract should include an indemnity from the supplier for losses you suffer as a result of the supplier's failure to comply with its privacy obligations — including any regulatory penalties, legal costs, and reputational remediation costs. Ideally, this indemnity is not subject to the general liability cap in the contract and does not exclude consequential loss, because privacy breaches tend to produce consequences — regulatory fines, class actions, reputational damage — that are difficult to classify as direct losses.
Your own obligations
Supplier-drafted contracts often include obligations on you that are easy to overlook. Common ones:
- providing materials, data, or system access that the supplier needs to perform the services
- giving warranties about your ownership of any intellectual property in materials you supply and that use of those materials will not infringe third-party rights
- paying invoices within a fixed period, with interest on late payment
- indemnifying the supplier against third-party claims arising from your materials
Review these carefully. Where you are required to supply materials, push for language that limits the obligation to materials "reasonably necessary" for the services, and resist warranties that go beyond your actual knowledge. Indemnities you accept for your own materials should be limited to the extent caused by your own breach, capped, and should exclude consequential loss.
Optional clauses worth considering
- Termination for convenience — the right to exit the contract without cause on reasonable notice, particularly important for long-term SaaS arrangements where your needs may change
- Step-in rights — the right to take over part of the supplier's work yourself, or engage a replacement supplier, if the supplier is in default and time is critical
- Data portability and return — an obligation on the supplier to return or delete your data in a specified format within a specified period after termination
- Liability cap — a ceiling on the total liability of either party, typically expressed as a multiple of the fees paid in a period, with agreed carve-outs for privacy breaches and wilful misconduct
- Change management process — a formal mechanism for varying the scope, timeline, or price, to prevent scope creep or unilateral changes that advantage the supplier
How Artificer Legal can assist
IT services contracts are often presented to buyers on a "standard terms" basis with an implicit expectation that they will be signed quickly. That framing is commercially motivated — not legally correct. Every significant term in an IT contract is negotiable.
At Artificer Legal, we review IT services agreements with a focus on the clauses that actually decide outcomes in disputes: how service levels are calculated, whether privacy obligations are fit for purpose, whether acceptance testing gives you a genuine right to reject defective work, and whether the liability framework reflects the real risks in the arrangement.
Specifically, we would push back on:
- uptime clauses with maintenance exclusions that inflate the effective downtime permitted
- privacy clauses that require compliance only with laws applicable to the supplier
- liability caps that cover privacy indemnities when they should not
- acceptance clauses that deem acceptance after a period of silence
If you are the party receiving the supplier's standard form, we negotiate from your position. If you are supplying IT services and want your own agreement reviewed or drafted, we work from your commercial and risk requirements.
The privacy indemnity clause
The privacy indemnity clause is consistently the most consequential clause in an IT services contract — and the one most often drafted in a way that defeats its own purpose. A capped indemnity that excludes consequential loss does not protect you when a supplier-caused data breach results in regulatory action, class proceedings, or both. The costs in those scenarios are precisely the consequential losses the cap excludes.
The rest of the contract also matters. An IT services agreement that works for your business makes clear what you are receiving, holds the supplier to measurable performance standards, gives you genuine remedies when those standards are not met, and allocates data handling obligations in a way that lets you discharge your own legal duties. Review it as if the supplier will fail at some point — because understanding what happens when things go wrong is the real purpose of getting the contract right before you sign.