Our service commitments for cloud hosting.

Applies to: All BaseHost service agreements unless explicitly varied in a signed Statement of Work or Master Services Agreement.

1. Purpose

This Service Level Agreement (SLA) defines the response and resolution targets BaseHost commits to in delivering its Managed Services, Security Operations, Service Request fulfilment, and Development & Maintenance services. It forms part of the agreement between BaseHost (operated by Anamorphic Creations Pty Ltd, ACN 087 351 102) and the Client.

Where a signed Master Services Agreement, Statement of Work, or Enhanced SLA Addendum specifies different targets, those documents prevail over this schedule.

2. Service Coverage

BaseHost classifies inbound tickets into one of four categories. Each category is governed by its own SLA targets, set out in Section 6.

Business Hours are defined as 8:00am to 6:00pm Australian Eastern Time (AEST/AEDT), Monday to Friday, excluding Victorian public holidays.

If a Service Request is genuinely time-critical and outside Business Hours, the Client may raise it as an Incident. BaseHost will reclassify the ticket if the impact justifies it.

3. Incident Severity Classification

The following severity scale applies to Incidents (MSP, Security, and Development). Service Requests are classified separately, see Section 4. All Incidents are classified by the BaseHost Helpdesk on receipt. Severity may be re-classified during the lifecycle of a ticket where new information emerges or impact changes; the Client will be notified of any reclassification.

Severity 1 - Critical

The ability to conduct business or service the customer has stopped.

Examples: Server down; network down; tenant-wide Microsoft 365 outage; application unusable entirely; active security incident with confirmed business impact (ransomware, data exfiltration, account takeover in progress).

Severity 2 - High

Service is seriously degraded but can continue its operation via a work-around or incremental resource for a short period of time before business stops.

Examples: Extremely slow system performance; network functionality becomes limited or has a bug; application performance is degraded for some or all users; confirmed security compromise requiring containment but not yet impacting operations.

Severity 3 - Medium

Service is lost by a single or small number of users, affecting significant business functionality. Problems or incidents where a work-around exists or can be developed with a small amount of incremental resources.

Examples: Single user unable to access a core application; suspicious security activity requiring investigation; mailbox sync failures for an individual.

Severity 4 - Low

Problem or incident where single users can operate the system activities normal, but a definite problem is identified.

Examples: Some application functionality is slow or not working for some users either because of a bug or an un-documented usage scenario that is causing an error; low-risk security alerts pending review; minor configuration drift.

4. Service Request Classification

A Service Request is any planned, predictable item of work that is not an incident, typically a request for information, access, provisioning, or a configuration change. Service Requests are classified by complexity, not severity. The BaseHost Helpdesk maintains a Service Request Catalogue that maps common requests to the tiers below; the catalogue is available on request.

SR1 - Quick

A single, well-defined action that does not require approval or scoping.

Examples: Password reset; MFA reset; mailbox quarantine release; single-user access change; information or how-to question.

SR2 - Standard

A multi-step but well-defined action that may require client authorisation.

Examples: New user provisioning; software install request; new shared mailbox or distribution list; standard device enrolment; licence assignment.

SR3 - Complex

A request that requires planning, scoping, or coordination, and may require a quote if it falls outside MSA scope.

Examples: Bulk user onboarding/offboarding; tenant-wide policy changes; new site setup; configuration changes affecting multiple users or systems; hardware procurement.

Where a Service Request requires Client authorisation, the SLA resolution clock pauses while BaseHost awaits approval and resumes once approval is received.

5. SLA Roles & Definitions

Helpdesk Response

The Helpdesk team are responsible for cataloguing and classifying tickets, determining whether a ticket is an Incident, Service Request, or Development item, and assigning the appropriate severity or tier. For Incidents, they follow the defined runbook and triage steps with the intent to remediate. For Service Requests, they fulfil the request directly where possible, or coordinate fulfilment with other teams. If runbook steps fail or the request is out of scope of Helpdesk capability, they escalate to the Security Operations or Development team.

Development Response

The Development Team are responsible for ensuring applications and platforms are working to specification. They are responsible for describing and documenting the expected triage steps and preparing any scripts for programmatic monitoring. When faults occur, they will take an escalation from the Helpdesk team with a handover indicating what has been attempted prior, to make their investigations more efficient.

Security Operations (SOC) Response

The Security Operations team are responsible for monitoring, triaging, and responding to security alerts generated by Microsoft Defender, Microsoft Sentinel, and other configured security telemetry. They are responsible for investigating alerts, containing confirmed threats (including isolating endpoints, disabling accounts, and revoking sessions where authorised), preserving evidence, and coordinating with the Helpdesk and Development teams during incidents that span multiple service lines.

Key Terms

• Response Time is the elapsed time from a ticket being received and classified by BaseHost to the first substantive human acknowledgement to the Client.
• Resolution Time is the elapsed time from classification to either (a) restoration of the affected service or fulfilment of the requested item, or (b) implementation of a documented workaround that returns the Client to operational state. Permanent fixes to underlying root causes may follow.
• Status Update is a written or verbal communication providing progress on an open ticket. Frequency is measured from the previous update.
• SLA Pause is when the SLA clock pauses because a ticket is awaiting information or action from the Client, a third-party vendor (e.g. Microsoft, Apple, ISP), an approval workflow, or is blocked by a scheduled change window. The clock resumes when BaseHost is unblocked.

6. Service Level Targets

6.1 MSP Incident SLA

Coverage: 24x7

"Response" means the first substantive human acknowledgement to the Client (see Section 5, Key Terms). An automated acknowledgement of receipt does not satisfy the response target.

6.2 Security Operations (SOC) Incident SLA

Coverage: 24x7 triage & response; active containment 24x7 for Severity 1-2.

SOC Response means acknowledgement of the alert and commencement of triage. Containment targets apply to a threat confirmed through investigation; where investigation determines no containment is required, the containment target does not apply.

Security incidents at Severity 1-2 will trigger BaseHost's documented Incident Response runbook, including evidence preservation, stakeholder notification, and (where applicable) coordination with the Office of the Australian Information Commissioner (OAIC) for notifiable data breaches under the Privacy Act 1988 (Cth). The Client remains the data controller and is responsible for regulatory notifications.

6.3 Service Request SLA

Coverage

• Triage & Response: 24x7. The on-shift team acknowledges and classifies Service Requests at any hour.
• Fulfilment: by fulfilment class. Each request type in the Service Request Catalogue is tagged as either Anytime or Business Hours fulfilment, per the test below.

Fulfilment classes

• Anytime (24x7): self-contained actions BaseHost can complete remotely using tooling available around the clock, with no dependency on a third party, supplier, purchase, physical attendance, or client authorisation unavailable out of hours. Fulfilment targets are measured in clock time, 24x7. Examples: password reset, MFA reset, account unlock or re-enable, mailbox quarantine release, access grant or revoke, licence assignment, distribution-list change, information or how-to answer.
• Business Hours: requests that depend on something available only in business hours, procurement and hardware orders, third-party vendor coordination, onsite or physical work, purchases, or changes requiring approval or a scheduled change window. Fulfilment targets are measured in Business Hours. Examples: ordering a laptop or other hardware, new-site setup, supplier liaison, anything requiring a purchase order or external party.

Classification test (for requests not yet in the Catalogue): Can BaseHost complete the request on its own, remotely, using tooling available 24x7, without waiting on a third party, a purchase, physical attendance, or client authorisation unavailable out of hours? If yes, it is Anytime; if no, it is Business Hours. The Service Request Catalogue records the class for each request type and is available on request.

* Fulfilment targets are measured in clock time, 24x7, for Anytime-class requests, and in Business Hours for Business-Hours-class requests. Complex (SR3) requests are typically Business-Hours class.

For SR3 requests requiring quoted work outside MSA scope, the fulfilment clock pauses once BaseHost issues a scope/quote, and resumes when the Client approves.

6.4 Development & Maintenance SLA

Coverage: Helpdesk triage 24x7; Development engagement Business Hours.

6.4.1 Development Incidents

Development Severity 1 incidents that occur outside Business Hours will be triaged by the Helpdesk 24x7. If the runbook fails to restore service, an after-hours pager will engage a Development on-call resource on a best-effort basis. Guaranteed Development on-call is available under an Enhanced SLA Addendum.

6.4.2 Development Change Requests

A Change Request is a request for new functionality, enhancement, or a non-incident modification to a custom application or platform under BaseHost's care.

Change Requests do not have severity classifications because they are not service-affecting issues. They are progressed according to agreed scope and the Client's prioritisation against other work in flight.

7. Inclusions & Exclusions

7.1 What this SLA covers

• Services explicitly described in the Client's signed Master Services Agreement, Service Order, or Statement of Work.
• Applications, devices, and infrastructure under active BaseHost management with current monitoring agents installed and reporting.
• Tickets reported via BaseHost's approved channels (ticketing portal, support email, helpdesk phone line).

7.2 What this SLA does not cover

• Third-party vendor outages beyond BaseHost's control (e.g. Microsoft 365 platform outages, Apple service disruptions, ISP failures, DNS provider outages). BaseHost will respond and coordinate, but resolution time is dependent on the vendor.
• Force majeure events including natural disasters, power grid failures, civil unrest, and government action.
• Unsupported software, devices, or configurations, including end-of-life operating systems, unmanaged BYOD endpoints, and software not approved within the Client's environment.
• Client-caused delays including unavailability of authorised contacts, lack of physical or remote access, missing credentials, or refusal of recommended remediation steps.
• Scheduled maintenance windows notified in advance.
• Service Requests that fall outside the MSA scope, which may be quoted as a separate engagement.
• Issues caused by changes made by the Client or third parties without BaseHost's knowledge or approval.
• Connectivity issues at Client sites where the Internet service is not provided or managed by BaseHost.
• Equipment without current manufacturer warranty or adequate vendor support cover, where restoration depends on a vendor repair or replacement (RMA) timeframe outside BaseHost's control, including equipment whose warranty the Client has allowed to lapse or elected not to cover (see §7.3).
• Single points of failure the Client has declined to remediate: for example, a site with no backup or redundant internet connection, or no standby/spare hardware, where an incident could not be mitigated because that resilience was not in place (see §7.3).

7.3 Client prerequisites & declined recommendations

BaseHost's resolution and restoration targets assume the Client maintains the conditions necessary for BaseHost to restore service within them. In particular, the Client is responsible for maintaining:

• current manufacturer warranty or vendor support cover on hardware and equipment under BaseHost's management, at a level appropriate to the equipment's role and criticality;
• supported, in-life software and operating systems; and
• reasonable resilience for business-critical services where BaseHost has recommended it, for example, redundant or backup internet connectivity, or standby/spare hardware for known single points of failure.

Where BaseHost has recommended such a measure (whether on supply of equipment or otherwise) and the Client has declined it, allowed it to lapse, or elected a lower level of cover, BaseHost's resolution and restoration targets do not apply to incidents arising from, or prolonged by, that gap. In those circumstances BaseHost will still meet the applicable response target, will keep the Client updated, and will work to restore service as quickly as the vendor and circumstances allow, but the resolution clock is suspended for any period during which BaseHost is dependent on a vendor repair or warranty replacement (RMA), or is unable to fail over because the recommended resilience was not in place. BaseHost records such recommendations and the Client's decision so the position is clear at the time an incident occurs.

8. Reporting & Review

• BaseHost maintains records of all tickets, classifications, response times, and resolution times in its PSA (HaloPSA).
• SLA performance is reported to the Client on request, and reviewed in scheduled service reviews (cadence as defined in the MSA, typically quarterly).
• Repeated or systemic SLA breaches for Incidents will trigger a Root Cause Analysis (RCA) document delivered to the Client within 5 Business Days of resolution.

9. Service Credits: Human Response Guarantee

9.1 The guarantee. BaseHost guarantees a first response by a member of its team (a genuine, substantive human acknowledgement, not an automated receipt) to every MSP Support Incident and every in-scope Service Request within the response targets set out in Sections 6.1 and 6.3 respectively.

9.2 Credit trigger. Where BaseHost fails to meet the applicable first-response target for an Incident or in-scope Service Request raised in respect of a User, that User is eligible for a service credit equal to 50% of that User's monthly Managed Service Fee for the month in which the breach occurs.

9.3 What the credit is for, and why it is contained to that User. A missed response target is a failure of one User's experience in one interaction, so the remedy is matched to that. The credit is calculated on that individual affected User's recurring Managed Service Fee only, and is applied solely to the User whose response target was missed. It is not applied to other Users, to the Managed Service line as a whole, or to the Client's wider account. It expressly excludes third-party licence fees, hardware, software, and any other pass-through or one-off charges.

9.4 One credit per User per month. A User is eligible for a maximum of one 50% credit in any calendar month, regardless of how many response targets are missed for that User in that month. Credits do not stack and do not exceed 50% of the User's monthly Managed Service Fee.

9.5 How the credit is applied. The Client does not need to submit a claim. Where a response target is missed, the breach is recorded on the ticket that suffered the fault, and that ticket is referred to the Team Leader, who applies the credit to the Client's billing account.

9.6 Response, not resolution or fulfilment. This guarantee applies to first-response time only. It does not apply to remediation, resolution, or Service Request fulfilment timeframes, which depend in part on third parties and on Client dependencies.

9.7 Scope. This guarantee applies to the first-response targets for MSP Support Incidents (Section 6.1) and in-scope Service Requests (Section 6.3). It does not apply to: Service Requests that fall outside the scope of the Client's MSA, Service Order or Statement of Work; Security Operations (SOC) incidents (Section 6.2); or Development Incidents and Change Requests (Section 6.4).

9.8 Exclusions and SLA pause. No credit arises where the missed target results from any circumstance in Section 7.2 (Exclusions), or for any period during which the SLA clock is paused under Section 5 (awaiting the Client, a third-party vendor, an approval workflow, or a scheduled change window).

9.9 Sole financial remedy. Service credits are the sole financial remedy for a missed response target under this SLA.

10. Enhanced SLA Options

The targets above are BaseHost's standard published SLA. The following enhancements are available by negotiation for Clients with elevated compliance requirements (e.g. Essential 8 Maturity Level 2 or 3, regulated industries, contractual obligations to their own customers):

• Tightened Severity 1 response and resolution targets.
• 24x7 Service Request fulfilment for time-zone or operational reasons.
• Dedicated named technical resources.
• Tightened RCA delivery timeframes.
• Design and implementation of redundant or high-availability infrastructure (such as failover connectivity, standby hardware and resilient architecture), engineered to support tighter availability and resolution targets and to avoid the SLA-breach and limited-remedy situations described in §7.3.

Enhanced SLAs are documented in a signed Addendum and priced accordingly.

11. Changes to this SLA

BaseHost may update this SLA from time to time. Material changes will be communicated to Clients in writing at least 30 days before they take effect.