Managed Services Agreement For NZ Cybersecurity Providers

Yes, if you provide ongoing cybersecurity or managed IT services in New Zealand, you should have a written managed services agreement before you onboard a client.

The nuance is that cybersecurity work carries risks that a standard IT support agreement often doesn't deal with properly. You're not just fixing laptops or setting up email accounts. You may be monitoring threats, handling admin access, responding to incidents, using third-party security tools and making judgement calls under pressure.

A good agreement won't promise that nothing bad will ever happen. Instead, it sets clear boundaries around what you're responsible for, what the client must do, how incidents are handled and how liability works if something goes wrong.

What Should A Managed Services Agreement Cover?

A managed services agreement should clearly describe your services, the commercial deal and the rules that apply while you're supporting the client.

For cybersecurity providers and MSPs, the biggest risk is usually unclear expectations. A client may think your monthly fee includes unlimited support, 24/7 incident response, full cyber insurance-style protection and responsibility for every tool in their stack. If your agreement doesn't say otherwise, it can be much harder to push back later.

Your agreement should usually cover:

• Services: what you're actually providing, such as endpoint monitoring, firewall management, vulnerability scanning, helpdesk support, backups or Microsoft 365 security configuration.
• Service levels: response times, support hours, priority levels and any planned maintenance windows.
• Fees and payment: monthly fees, setup fees, extra charges, late payment consequences and when invoices are due.
• Client responsibilities: access, approvals, staff training, device management, backups, licences and timely decisions.
• Exclusions: what isn't included, such as legacy systems, unsupported devices, onsite work or emergency incident response outside scope.
• Third-party tools: how vendor products, licences, outages and price changes are handled.
• Privacy and data access: how you handle personal information and confidential information.
• Liability: caps, exclusions and limits for cyber events, data loss and indirect losses.
• Term and termination: how either side can end the arrangement and what happens during offboarding.

This doesn't have to be overly complex, but it does need to match how your service actually works. A template written for a generic IT support services agreement may miss the parts that matter most in cybersecurity.

How Do You Define Cybersecurity Services Without Overpromising?

You define cybersecurity services well by being specific about the tasks you perform and avoiding broad promises like guaranteed protection or complete security.

No provider can promise that a client will never suffer a breach, ransomware attack or business email compromise. Even strong security controls can fail if a user clicks a phishing link, a vendor has an outage, credentials are reused or a client ignores your recommendations.

Your agreement should describe the outcome you're working towards, but not as an absolute guarantee. For example, instead of saying you'll keep the client's systems secure, you might say you'll provide defined monitoring, alerting and configuration services under a clear cybersecurity services agreement, using agreed tools and processes.

Be Clear About What Is In Scope

List the systems, users, locations and tools your services apply to. If you're only managing the client's cloud environment, don't let the wording suggest you're responsible for every device, network and third-party platform they use.

For example, your scope might say:

• you manage Microsoft 365 security settings for up to 50 users;
• you monitor endpoint alerts for devices enrolled in your agreed security platform;
• you review critical alerts during business hours; and
• you provide monthly security reporting based on available tool data.

Avoid Absolute Security Promises

Your marketing can be confident, but your contract should be careful. Avoid words that suggest you're guaranteeing prevention, such as eliminating all threats, stopping all attacks or ensuring complete compliance.

You can still be reassuring. The key is to promise the services you control, not outcomes affected by the client's staff, systems, vendors and threat environment.

What Should Your Agreement Say About Incident Response?

Your agreement should say whether incident response is included, what level of response is included and when extra fees apply.

This is one of the most common pressure points for cybersecurity providers. A client may assume that if they pay a monthly security fee, you'll drop everything during a ransomware event, work through the night, coordinate forensic specialists and restore the business at no extra cost.

If that's not your model, your agreement needs to say so before the incident happens.

Your incident response clause should usually cover:

• Triggers: what counts as an incident for your services, such as malware detection, unauthorised access alerts or confirmed account compromise.
• Included response: triage, initial containment steps, user account lockouts, log review or escalation.
• Excluded response: digital forensics, legal advice, public relations, ransom negotiation, hardware replacement or onsite recovery if you don't provide these services.
• Availability: whether response is during business hours only, 24/7, or subject to a separate retainer.
• Client approvals: when you can take urgent action and when you need written approval.
• Extra charges: hourly rates, after-hours fees or separate statements of work for major incidents.

Say Ava runs a Christchurch cybersecurity business. Her client pays $2,000 plus GST per month for endpoint monitoring and monthly reporting. One Friday at 9pm, the client has a ransomware incident affecting 25 devices. Ava's agreement says after-hours incident response is excluded unless the client has a separate incident response retainer, and emergency work is charged at an agreed hourly rate once approved.

Because that was written into the agreement, Ava can respond professionally without accidentally turning a monthly monitoring plan into unlimited emergency recovery work. The client also knows what to approve, what it will cost and what isn't covered.

How Should SLAs Work In An MSP Contract?

SLAs should set realistic response commitments, not guarantee that every issue will be fixed within a fixed time.

A service level agreement is useful because it gives clients confidence and gives your team a clear process. The trick is to define the metric carefully. For cybersecurity and IT support, response time is usually easier to control than resolution time.

For example, you might be able to commit to responding to a critical security alert within 30 minutes during covered hours. You may not be able to promise full resolution within 30 minutes, because that may depend on vendor support, client approvals, internet outages, device availability or the complexity of the attack.

Common SLA Categories

Your SLA can classify tickets or alerts by priority. For example:

• Priority 1: confirmed or likely major compromise affecting business-critical systems.
• Priority 2: serious security issue affecting a limited number of users or systems.
• Priority 3: standard support request or non-urgent configuration change.
• Priority 4: general question, reporting request or low-risk administration task.

You can then set different response targets for each priority. Make sure you define when the clock starts, such as when the client lodges a ticket through the approved channel or when your monitoring tool creates an alert.

Watch Out For SLA Credits

Some clients may ask for service credits if you miss an SLA. That's not always unreasonable, but it should be carefully drafted.

If your service level agreement includes service credits, consider whether they should be the client's sole remedy for the SLA failure. You should also exclude missed SLAs caused by the client, a third-party vendor, internet failure, scheduled maintenance or events outside your reasonable control.

Who Is Responsible For Third-Party Tools And Client Systems?

Your agreement should make it clear that you're not automatically responsible for every third-party tool, licence, outage or client system problem.

Cybersecurity providers often rely on software vendors, cloud platforms, distributors and telecommunications providers. You might resell or manage tools like endpoint detection, password management, backup platforms, email filtering or ticketing software. Those tools are essential, but you don't fully control them.

Your agreement should explain:

• whether the client contracts directly with the vendor or through you;
• who owns the licences and accounts;
• whether vendor terms also apply to the client;
• what happens if a vendor changes pricing, features or support levels;
• who is responsible for renewals, licence counts and user changes;
• how outages, bugs and vendor security issues are handled; and
• what happens to data and access when the client leaves.

Client systems matter too. If a client uses unsupported servers, shared admin passwords, old devices or unlicensed software, that can increase risk. Your agreement should let you exclude or limit responsibility for systems you haven't assessed, can't access or have warned the client about.

This is also where client responsibility clauses do a lot of work. You may need the client to maintain accurate user lists, remove departed staff, keep devices enrolled, follow your security recommendations and tell you about changes before they affect your services.

Without those obligations, you may be blamed for gaps you couldn't see or control.

How Do Privacy And Data Access Fit Into Information Security Terms?

Privacy and data access should be dealt with directly because your team may see, handle or control personal information while providing services.

In New Zealand, the Privacy Act 2020 applies to personal information. If you're accessing client systems, logs, email accounts, staff records, customer databases or security alerts, you may be handling personal information even if you're not the main business collecting it.

Your agreement should set out how you handle that access. It should usually cover:

• what data you may access to provide the services;
• how you keep client data confidential and secure;
• who in your team can access the data;
• whether data may be stored or processed outside New Zealand;
• how you deal with suspected privacy breaches;
• how long you keep logs, reports and support records; and
• what happens to data when the agreement ends.

The Privacy Act 2020 has a notifiable privacy breach regime. If a privacy breach is notifiable because it has caused, or is likely to cause, serious harm, the agency must notify the Privacy Commissioner as soon as practicable. It will usually also need to notify affected individuals, unless an exception, permitted delay or public notice option applies. Your contract should say how quickly you must notify the client if you become aware of a suspected breach involving their information, and what cooperation each side must provide.

You should also think about the Fair Trading Act 1986. If your website or proposal says your service is certified, compliant with a standard or suitable for a particular regulatory requirement, that needs to be accurate and supportable. Broad security claims can become a problem if they oversell what your service actually does.

For business clients, you may also be able to contract out of some Consumer Guarantees Act 1993 guarantees where the services are acquired in trade and the contracting out is fair and reasonable. This needs careful wording and won't suit every client or situation.

What Clauses Should You Include In Your Agreement?

Your IT services agreement should include the clauses that match your services, risk profile and client base, rather than a generic set of IT terms.

Here is a practical fill-in outline you can use to plan your document. It's not a finished legal document, and you should have it tailored before you use it with clients.

1. Parties And Background: write the legal names, NZBNs if available, and a short description of the services.
2. Service Scope: list exactly what you provide, the covered systems, users, tools and locations.
3. Service Exclusions: state what isn't included, such as after-hours response, unsupported systems or onsite work.
4. Client Responsibilities: set out access, approvals, licence management, staff conduct, backups and security hygiene.
5. SLAs And Support Process: define support hours, ticket channels, priority levels and response targets.
6. Incident Response: explain what happens during a security incident, what is included and when extra fees apply.
7. Third-Party Tools: cover vendor terms, licences, outages, price changes and data handling.
8. Fees And Payment: include monthly fees, setup fees, project fees, GST, invoice timing and late payment rights.
9. Privacy And Confidentiality: explain how you handle personal information, logs, credentials and confidential business information.
10. Intellectual Property: clarify ownership of your tools, scripts, templates, reports and pre-existing materials.
11. Liability: include appropriate caps, exclusions and limits for indirect loss, data loss and cyber events.
12. Term, Suspension And Termination: set out the contract length, renewal, suspension for non-payment and offboarding steps.

If you're contracting with larger customers, they may send you their own procurement terms. Read these carefully before signing. They may impose unlimited liability, strict security obligations, audit rights, insurance requirements or data processing terms that don't match your pricing or service model.

Key Takeaways

• A managed services agreement for cybersecurity work should define your services, exclusions, SLAs, client responsibilities and liability before onboarding starts.
• Don't promise complete security. Promise the specific monitoring, configuration, support and response services you can actually control.
• Incident response needs its own wording, especially around after-hours work, emergency approvals, exclusions and extra fees.
• Third-party tools, vendor outages and unsupported client systems should be handled clearly so you're not blamed for things outside your control.
• Privacy, confidentiality and data access clauses matter under the Privacy Act 2020, especially if you handle logs, credentials or personal information.
• Templates often miss cyber-specific risks, so your agreement should be tailored to your service model and client base.

If you'd like help with your managed services agreement, cybersecurity service terms, SLA wording or privacy and data access clauses, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.