AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Essential Eight monitoring, reporting, and evidence for ongoing compliance
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
November 2, 2026
October 31, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
Australian MSPs need to protect their own business as well as the environments they manage. Privacy obligations, client contracts, critical infrastructure services, and incident reporting can each create responsibilities. Which apply depends on the MSP’s business, data, assets, and services.
There is no single compliance checklist that applies to every Australian MSP. Start by separating legal obligations, contractual commitments, and security guidance.
For example, a client may require Essential Eight reporting through its contract even when no law directly requires your MSP to meet a particular maturity level. A privacy obligation may apply because of the information you hold or a Commonwealth contract. SOCI coverage depends on qualifying assets and your role in operating them.
Record each applicable requirement, the systems and services it covers, its owner, and the evidence needed. Include subcontractors and suppliers where they support the commitment. Review the record when the business adds services, changes data handling, or takes on a client with different requirements.
This also helps prevent overstatement in proposals. Explain what your service supports and what has actually been assessed before claiming that the MSP or its clients are compliant.
An MSP’s management systems can provide a route into several clients. Its remote monitoring and management (RMM) platform, technician identities, documentation system, and remote access services therefore deserve attention as part of the provider’s own security program.
The Australian Signals Directorate’s (ASD) MSP guidance and the joint international advisory emphasize secure administration, separation, monitoring, vulnerability management, and incident preparedness. Put those recommendations into the way technicians work:
Use MFA, with phishing-resistant methods where appropriate and supported, and keep privileged work separate from ordinary email and browsing.
Scope technicians and service accounts to the clients and functions they need. Avoid reusing administrator credentials across clients.
Patch management platforms and internet-facing services, address known exploited vulnerabilities, and remove obsolete access methods.
Capture relevant sign-ins, remote sessions, script execution, and changes to privileges or configuration.
Protect backups, test restoration, and exercise the response to compromise of a shared management system.
Test the access path as a whole. Separate administrator identities provide limited protection if a compromised workstation can still reach every management console. Staff departures and client offboarding should remove access from all relevant systems, including integrations and service accounts.
The Essential Eight is not a universal legal mandate for Australian MSPs. It can become a requirement through a contract, policy, or applicable regulatory arrangement. It also provides useful guidance for protecting the MSP’s own environment.
Its eight strategies should be considered against the systems staff use to administer clients, alongside the rest of the defined assessment scope.
The maturity model uses levels zero to three. A maturity claim needs evidence against the relevant requirements, with the assessed systems, exclusions, and date clearly identified. Having a policy or a dashboard does not establish that the controls work throughout the claimed scope.
ASD has evolved the Essential Eight into ASD Essentials for enterprise IT. Existing controls and assessment evidence remain useful, but maturity ratings do not automatically become effectiveness ratings under the new framework.
Use the transition guidance to map current controls and evidence, identify broader requirements, and plan the remaining work. Continue meeting contracts or regulatory obligations that specifically require Essential Eight implementation or reporting. A change in guidance does not, by itself, change those commitments.
It can. The Privacy Act 1988 generally covers businesses with annual turnover above $3 million, but smaller businesses can also be covered. Relevant circumstances include Commonwealth contracted services and subcontracts, certain corporate relationships, and other exceptions to the small-business exemption.
Use the Office of the Australian Information Commissioner’s (OAIC) small-business checklist rather than relying on turnover alone. An MSP does not become a health service provider simply because it supports a medical practice, but the actual services, relationships, and information involved still need assessment.
An otherwise exempt business may also have obligations for particular information, such as tax file numbers. Those duties do not necessarily extend to every type of personal information it holds.
Map personal information across the MSP’s own systems. Service tickets, email, documentation, backups, and investigation records may contain information about client staff and other individuals. Assess what the business possesses or controls, rather than looking only at its customer database.
For entities covered by the Australian Privacy Principles (APPs), APP 11 requires reasonable technical and organizational measures to protect personal information from misuse, interference, loss, and unauthorized access, modification, or disclosure.
It also requires reasonable steps to destroy or de-identify information no longer needed for permitted purposes, subject to exceptions such as Commonwealth records and legally required retention. Apply a deliberate retention policy to tickets, exports, attachments, and old client records.
APP 8 addresses overseas disclosure. Before disclosure, reasonable steps are generally required to ensure the overseas recipient complies with the applicable APPs, with continuing accountability subject to exceptions.
The Privacy Act does not impose a blanket Australian hosting requirement. Assess overseas hosting, support access, and subcontractors according to the actual handling arrangement, including whether it constitutes a use or disclosure. A server’s location alone does not answer that question.
Under the Notifiable Data Breaches scheme, covered entities must assess suspected eligible breaches and notify when the legal threshold is met. Particular information, such as TFN information, can bring a breach into scope even for an otherwise exempt small business.
An eligible breach generally involves unauthorized access or disclosure, or loss likely to lead to either, where serious harm is likely and remedial action has not prevented that likelihood. Not every security incident meets that test.
Where there are grounds to suspect an eligible breach, conduct a reasonable and expeditious assessment. Take all reasonable steps to finish within 30 calendar days after the day those grounds became known.
The 30-day period is not permission to delay notification. Once reasonable grounds to believe an eligible breach occurred exist, prepare and provide the required statement to the OAIC and notify individuals at risk of serious harm as soon as practicable, subject to applicable exceptions.
An MSP and client may jointly hold affected information. One entity can perform the required assessment and notification for the others, but each covered entity must ensure the requirements are met. OAIC generally favors notification by the entity closest to affected individuals.
Agree who investigates, supplies evidence, makes the assessment, and communicates. Record the outcome, including the basis for a decision that notification is not required.
Yes, where assets the MSP owns or operates meet a critical infrastructure asset definition under the Security of Critical Infrastructure Act 2018 (SOCI Act). Having a critical infrastructure client does not, by itself, make the MSP a responsible entity.
One relevant category is a critical data storage or processing asset. Under section 12F, assess whether the provider-owned or operated asset is used wholly or primarily to supply a qualifying service relating to business critical data to specified government end-users or a responsible entity for a critical infrastructure asset. Provider knowledge and other statutory conditions also matter.
Business critical data is required in both branches of that test. Check the current Act, relevant rules, other asset classifications, and exclusions against the actual arrangement.
Responsible entities must take reasonable steps to inform commercial providers when their data storage or processing service relates to business critical data, as soon as practicable. Such a notice should trigger an applicability review.
Depending on the asset and role, obligations may include registration, a critical infrastructure risk management program, and incident reporting. Where Part 2B applies, report to ASD’s Australian Cyber Security Centre (ACSC) as soon as practicable and within the applicable limit:
For an incident that has had or is having a significant impact on asset availability, meeting the statutory test.
For an incident that has had, is having, or is likely to have another relevant impact on the asset.
A significant impact involves material disruption to the availability of essential goods or services delivered by the asset. A relevant impact can concern availability, integrity, reliability, or confidentiality. Oral reports also require written follow-up under the applicable rules. An MSP outside direct coverage may still need to notify its client promptly so the client can meet its own deadline.
Mandatory ransomware and cyber extortion payment reporting under the Cyber Security Act 2024 commenced on 30 May 2025. Covered entities must report qualifying payments within 72 hours of making the payment or becoming aware that a payment was made on their behalf.
For an ordinary private business carrying on business in Australia, the turnover test generally concerns previous-financial-year turnover exceeding $3 million. A prescribed threshold calculation applies where the business operated for only part of that year. Responsible entities for critical infrastructure assets subject to SOCI Part 2B are covered separately.
The obligation concerns qualifying monetary and non-monetary benefits provided in response to cyber extortion. An extortion demand without payment does not trigger this payment-reporting requirement, though the incident may trigger other duties.
Separate the affected entity from whoever transfers the payment. If an MSP pays on a covered client’s behalf, the client’s reporting responsibility remains. A third party can submit the report with the required details. The MSP should separately assess whether the incident and payment create an obligation for its own business.
One incident can require several notifications. Telling a client, submitting a cyber incident report, and notifying the OAIC serve different purposes.
For example, compromise of a shared management platform might affect the MSP’s own records, client personal information, and a critical infrastructure customer’s services. Each affected entity must assess its position. A ransom payment later in the incident can create an additional reporting trigger.
Record when relevant facts became known, who assessed each obligation, who owns the submission, and whether it was completed. Build those records into the incident process so reporting does not depend on reconstructing email conversations afterward.
Monitoring should help establish who acted, what changed, and which clients may be affected. Prioritize management platform activity, privileged access, staff identity and endpoint events, and the paths used to administer client systems.
The joint MSP advisory recommends retaining the most important logs for at least six months. Newer ASD SIEM guidance gives organizations new to detection a starting point of at least one year for administrative and security logs and 90 days for contextual informational logs.
These are recommendations, not universal statutory retention periods. Set retention against risk, investigation needs, contracts, and applicable legal requirements, including privacy obligations governing information no longer needed.
Protect the records from alteration and test retrieval. A retention policy provides little support during an incident if expired access, missing sources, or an untested archive prevents investigators from obtaining the evidence.
Agreements should define security responsibilities, client notification, breach cooperation, approved response authority, and relevant subcontractors. Include data handling, access, return, and deletion requirements.
Translate those terms into operating procedures. The person on shift needs to know who can approve containment, which client contacts to use, and how to escalate an unanswered call. Keep statutory reporting ownership separate from routine client updates.
Exercise a scenario in which your own RMM, documentation platform, or identity service is unavailable or untrusted. Test alternative communications, protection of client access, evidence preservation, and recovery. Include the decision-makers and specialist contacts needed to carry out the plan.
Policies explain what should happen. Access reviews, configuration checks, patch records, restoration tests, and investigation records help demonstrate what actually happened.
Keep that evidence connected to each requirement, with an owner and review date. Revisit it after changes to services, suppliers, administration methods, or client commitments.
Independent assurance can support procurement and supply-chain reviews. Check the scope, services, locations, and period covered by ISO/IEC 27001 certification or a SOC 2 report. Supplier assurance supports your assessment; it does not establish that your MSP’s own controls are effective or discharge its legal duties.
ThreatDefence provides an AI SOC platform with a 24x7 SOC to monitor an MSP’s own environment and its clients’. Monitoring covers remote management tools, privileged accounts, identity and email activity, with each investigation recorded in a case.
ThreatDefence is ISO 27001 and PCI DSS certified, with a SOC 2 report, which MSPs can reference in client supply-chain assessments. Essential Eight reporting draws on platform data, service levels are guaranteed and an incident response retainer is included.
For Australian clients, data sovereignty and residency are guaranteed, the SOC team is based in Australia and AI processing stays in the same region.
Explore Essential Eight Reporting
Faster investigations. Clear evidence. Coordinated response.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
ASD guidance emphasizes secure administration, client separation, vulnerability management, monitoring, and tested incident response. Apply it to the MSP’s own systems and access paths. Check current ASD Essentials transition guidance and any requirements incorporated into contracts or applicable policies.
Yes, where applicable, particularly for systems and identities used to administer clients. Essential Eight is not a universal legal mandate for MSPs. Keep evidence against the defined scope, follow ASD’s transition guidance, and continue meeting obligations that specifically require Essential Eight reporting.
It can. Commonwealth contracted services, relevant corporate relationships, and other exceptions can bring smaller businesses into scope. Particular information, such as TFN information, may also carry specific obligations. Use the OAIC’s checklist rather than turnover alone.
Where information is jointly held, one entity can carry out the applicable assessment and notification requirements for the others. Each covered entity must ensure this happens. OAIC generally favors the entity closest to affected individuals. Agree responsibilities with the client before an incident.
An MSP can be covered where assets it owns or operates meet a critical infrastructure asset definition. For qualifying data storage or processing assets, assess the end-users, business critical data, provider knowledge, and full statutory conditions. A client’s critical infrastructure status alone is insufficient.
A covered client remains responsible for reporting a qualifying payment made on its behalf within the applicable 72-hour period. The MSP can submit the report with the required details and should assess whether it has a separate obligation for its own business.
Set retention according to risk, investigation needs, and applicable obligations. The joint MSP advisory recommends at least six months for important logs. Newer ASD SIEM guidance suggests at least one year for administrative and security logs and 90 days for contextual informational logs as a starting point.
Include decision-makers, containment authority, evidence preservation, client access protection, alternative communications, breach assessment, and reporting responsibilities. Add recovery and specialist contacts. Exercise how the business will respond if its own management systems are unavailable or compromised.
AI SOC Platform Guide: your path to AI-enabled security operations
The ThreatDefence AI SOC platform: triage, investigation, and response
What is an agentic SOC? How AI-driven security operations work