Most small businesses in Australia do not have a dedicated IT person. For many, a managed service provider fills that gap — handling patching, monitoring, helpdesk support, and backups under a monthly fee. What is less well understood is that engaging an MSP does not transfer responsibility for the business's security and compliance. The ACSC has specifically flagged MSPs as a supply chain risk: when an MSP is compromised, every client it manages is potentially affected. Choosing the right provider — and putting the right contract in place — matters more than many businesses realise when they first sign up. This article covers what to look for, what to ask, and what to watch for once the relationship is underway.

What an MSP can and cannot do for your business

A managed service provider (MSP) takes on the day-to-day management of a business's IT environment — monitoring systems, applying patches, managing devices, and providing helpdesk support — under a fixed or predictable fee structure. For small businesses without dedicated IT staff, an MSP fills a significant operational gap.

What an MSP does not do is remove the business's responsibility for its own security and compliance. The ACSC, in its joint advisory on protecting against cyber threats to managed service providers and their customers, is explicit on this point: MSP-customer contracts should transparently identify the ownership of IT security roles and responsibilities. Delegating the work does not delegate the liability.

What a standard managed services agreement typically covers

The scope of a standard MSP engagement for an Australian SME generally includes:

• Helpdesk and end-user support

• Proactive monitoring of systems and networks

• Patch management and software updates

• Endpoint security management

• Backup and disaster recovery

• Cloud platform administration, including Microsoft 365

• Vendor management and licence renewals

What is typically not included in the base fee

Several categories of work commonly fall outside a standard MSP agreement and are either charged separately or require a distinct project engagement:

• Hardware procurement and replacement

• Major project work — office relocations, network rebuilds, platform migrations

• Software licence costs

• Legal, regulatory, or insurance obligations arising from a security incident

• Compliance advisory services

Understanding what is and is not included before signing is essential. An SME that assumes its MSP will handle regulatory notification obligations following a data breach may find that obligation falls entirely on the business itself. Under Part IIIC of the Privacy Act 1988 (Cth), the notification obligation rests with the APP entity — not with any third-party service provider engaged to manage IT systems.

The shared responsibility model

The ACSC advisory makes clear that when a business engages an MSP, it is trusting that provider with privileged access to its systems, data, and networks. The MSP becomes a high-value target: a single compromised MSP can provide a threat actor with access to multiple client environments simultaneously. This is why the ACSC has specifically flagged MSPs as a supply chain risk category — and why understanding what the MSP is responsible for, and what the business remains responsible for, is not a detail to leave to assumption.

What to check before signing — contract terms and security questions that matter

The ACSC's joint advisory on MSP security identifies the contract between an MSP and its customer as the primary mechanism for establishing who is responsible for what. Before signing, there are two categories of questions worth working through: the security posture of the MSP itself, and the specific terms of the agreement.

Security questions to ask before engaging an MSP

Does the MSP implement the Essential Eight in its own environment?

The Essential Eight is the ACSC's set of eight cybersecurity controls. Ask whether the MSP implements the Essential Eight in its own environment — not just for clients — and at what maturity level. The next section covers how to ask this question effectively. The remote monitoring and management tools that MSPs use to access client systems are high-value targets — if the MSP's own environment is compromised, client environments may follow.

Ask the provider directly: at what maturity level do they implement the Essential Eight in their own operations, and can they provide evidence of this?

Is MFA enforced on all staff accessing your environment?

The ACSC advisory specifically recommends that businesses enforce MFA on MSP accounts that access the customer environment. This is a non-negotiable baseline. An MSP that does not apply MFA to the accounts its technicians use to access client systems should not be trusted with privileged access to business infrastructure.

Where is data stored and processed?

If client data is stored or processed offshore, Australian Privacy Principle 8 (APP 8) applies. Under section 16C of the Privacy Act 1988 (Cth), the disclosing entity remains accountable if an overseas recipient mishandles the personal information — even where that recipient is the MSP. Ask the MSP where data is held, in which jurisdictions, and what contractual protections are in place with any subcontractors or cloud platforms used to ensure compliance with the APPs.

Contract terms to confirm before signing

Service Level Agreement (SLA)

The SLA should specify response and resolution timeframes for each priority level — typically critical, high, medium, and low. Vague commitments such as "best efforts" or "as soon as possible" provide no enforceable standard. A well-structured SLA for an Australian SME typically includes a one-hour response time for critical issues, four hours for high-priority issues, and one business day for medium-priority issues.

Incident notification obligations

The contract should specify what constitutes a security incident, how and when the MSP is required to notify the customer, and what information must be provided. Given the NDB scheme's 30-day assessment obligation and the Cyber Security Act's 72-hour ransomware payment reporting obligation, the timing of MSP-to-customer notification can directly affect the business's ability to meet its own regulatory obligations. If the contract does not address this, the business may not find out about an incident affecting its data until it is too late to act within the required timeframe.

Access management and privileged accounts

The contract should document which systems the MSP has access to, at what level of privilege, and what controls govern that access. Privileged access that is broader than necessary for service delivery represents an unnecessary risk. The agreement should also specify how access is revoked when the relationship ends.

Data handling at contract termination

What happens to the business's data when the MSP relationship ends? The contract should specify how data will be returned, in what format, within what timeframe, and whether and when it will be deleted from the MSP's systems. This is particularly important where the MSP holds backups or operates cloud services on the customer's behalf.

How to verify Essential Eight compliance

Asking an MSP whether it is Essential Eight compliant is a reasonable starting point — but the answer requires context to be meaningful. The Essential Eight is structured around four maturity levels (Maturity Level Zero through to Maturity Level Three), and compliance at Maturity Level One looks very different from compliance at Maturity Level Three. A provider that says "yes, we're Essential Eight compliant" without specifying the maturity level, or without being able to demonstrate it, has not answered the question.

Questions that produce useful answers

The following questions are designed to produce specific, verifiable responses rather than general assurances. They do not require technical expertise to ask — but an MSP that cannot answer them clearly is providing insufficient information for a meaningful evaluation.

1. At what maturity level do you implement the Essential Eight for your own environment — not just for clients?

This distinguishes between MSPs that implement controls for clients and those that hold themselves to the same standard internally. As noted in the previous section, an MSP's own environment is a high-value target. Internal compliance matters as much as client-facing compliance.

2. Can you provide documentation or evidence of your Essential Eight implementation?

A provider that has genuinely implemented the Essential Eight at any maturity level should be able to produce supporting documentation — whether an internal assessment, a third-party audit report, or an IRAP (Information Security Registered Assessors Program) assessment. IRAP is the ACSC's program for assessing whether an organisation's security controls meet Australian government standards. An MSP that holds an IRAP assessment provides a higher level of independent assurance than one relying solely on self-assessment.

3. What is your patch management SLA — specifically, how quickly are critical patches applied?

Patching operating systems and applications is one of the Essential Eight controls. The ACSC's guidance recommends that internet-facing services be patched within 48 hours for critical vulnerabilities, and within two weeks for other vulnerabilities. An MSP that cannot state a specific patching SLA — or whose SLA is materially longer than these timeframes — is not implementing patch management to an Essential Eight standard.

4. How do you manage and restrict privileged access — both to your own systems and to client environments?

Restricting administrative privileges is an Essential Eight control. The answer should describe specific technical controls — not a general policy statement.

If the answers are vague

An MSP that responds to these questions with generalities — "we take security very seriously," "we follow industry best practice," or "we can discuss that once you're onboard" — is not providing the information needed to make an informed decision. Specific, evidenced answers are a reasonable expectation from any provider being trusted with access to business systems and data.

The ACSC's Small Business Cyber Security guide recommends that businesses add a security questionnaire to their procurement process when engaging any supplier with access to their systems or data. An MSP is precisely the kind of supplier this guidance is directed at.

Signs it may be time to review your MSP arrangement

MSP relationships tend to be sticky. Changing providers involves migration effort, retraining, and operational disruption — which means many businesses stay with an underperforming MSP longer than they should. The following are the situations that warrant a formal review, rather than continuing to manage issues on a case-by-case basis.

Response times are consistently missing the contracted SLA

A pattern of missed SLA targets — not an occasional exception — indicates either that the MSP is under-resourced relative to its client load, or that the SLA was not realistic when it was agreed. Either way, the agreed standard is not being met. Where the business is losing productive time waiting for issues to be resolved, the cost of that downtime should be weighed against the cost of switching providers.

A security incident was handled without adequate notification

If the business learned about a security incident affecting its systems late, incompletely, or through a channel other than the MSP, that is a significant failure. Timely and complete notification is not a courtesy — it is a contractual obligation with direct regulatory consequences, as discussed in the contract terms section above. An MSP that does not notify promptly cannot be relied upon when notification timing matters most.

The MSP itself suffered a security incident

When an MSP is compromised, its clients are at risk. The ACSC has specifically flagged this as a supply chain threat: the remote monitoring and management tools that MSPs use to access client environments are attractive targets precisely because a single compromise can affect multiple organisations simultaneously. If an MSP has experienced a security incident — whether or not client data was affected — the business should request a full account of what occurred, what was affected, and what controls have been put in place to prevent recurrence. An MSP that is unwilling to provide this information is not operating transparently.

The business has grown or its compliance obligations have changed

An MSP engagement that was appropriate for a ten-person business may not be adequate for a fifty-person business with more complex data handling, a larger attack surface, and potentially different regulatory obligations. Similarly, if the business has moved into a sector with specific compliance requirements — healthcare, financial services, government contracting — the MSP's capabilities should be reassessed against those requirements. Growth and regulatory change are routine triggers for MSP review, not exceptional ones.

The contract no longer reflects the actual relationship

Where the services being delivered have evolved significantly from what the contract describes — whether through scope creep in either direction — the agreement is no longer an accurate record of the relationship. This creates ambiguity about responsibility when something goes wrong. A contract review does not necessarily mean a provider change, but it should result in a current, accurate agreement that both parties understand.

An MSP relationship works best when both parties are clear about who is responsible for what — and when that clarity is documented in the contract, not assumed. The questions and contract terms covered in this article are not obstacles to finding a provider. They are the basis for finding one that will genuinely reduce risk rather than simply manage infrastructure.

For businesses already working with an MSP, reviewing the contract against the checklist in this article is a worthwhile exercise — particularly if the relationship has been in place for several years without a formal review.

For advice on specific contract terms, security obligations, or assessing an MSP's Essential Eight compliance, consult a cybersecurity specialist or technology lawyer.

Official sources:

• ACSC — Protecting Against Cyber Threats to Managed Service Providers and their Customers

• ACSC — Essential Eight

• ACSC — IRAP

• ACSC — Small Business Hub

Last updated: August 2026