Trust Centre
Atlastix develops Atlas Automate, Atlastix Observability, Atlastix Device Intelligence, and product and custom software solutions for customers. This site explains how security responsibility is divided, how customer data is handled, and the controls governing software delivery and Atlastix-operated systems.
Assurance status: Atlastix runs a management-approved, ISO/IEC 27001-aligned ISMS with its controls mapped to the SOC 2 Trust Services Criteria, and opens the complete corpus for customer review under NDA. Both frameworks are used as references; independent certification and a SOC 2 examination are targets, not yet held. Public and NDA-controlled materials are available below.
Security
A summary of the control environment described in the Security Whitepaper (ATX-SOC-03), covering the boundaries and responsibilities most relevant to customer review.
Current delivery is generally in customer- or MSP-controlled cloud tenancies. Deployment-specific architecture, data flows, integrations and operational responsibilities follow the deployed configuration. Atlastix owns the software and customisations it delivers, its own environment and its handling of customer data it receives.
Release code and infrastructure changes use protected change paths, pull-request change control with senior review of junior-authored changes, applicable CI checks and pre-release testing. Each release version traces to the source commit and workflow run that produced it, with deployment and recovery guidance.
Customer-approved extracts or uploads, or temporary customer-tenancy access, may support development, customisation, testing, delivery and support. Processing location, content and retention are deployment- and agreement-specific. Access is approved, scoped and limited to named engagement personnel.
Approved engagement data held by Atlastix is encrypted in transit with TLS 1.2 or higher and at rest with AES-256, with keys held in cloud key services under ATX-TEC-03; current Device Intelligence engagement data uses the approved Azure service configuration. Corporate-tool encryption follows the contracted service configuration.
Single sign-on via Microsoft Entra ID with MFA is required for Atlastix work systems where supported. Access is least-privilege with unique named accounts and periodic access reviews; leaver access is revoked promptly on departure. Support access into a customer tenancy is customer-granted, temporary, scoped to the task, and logged in the customer’s environment.
AI arrangements vary by product and deployment: the customer's own provider subscription and keys, or the customer's cloud-native model service, may be used. Provider ownership, data path and location follow the approved configuration and agreement. Atlastix does not use customer data it receives to train models.
Cloud, source-control, identity and endpoint events feed documented monitoring and incident-response processes. Events are triaged by severity, response actions are recorded, and customer notification follows applicable legal and contractual requirements.
Recovery objectives, backup responsibilities and recovery procedures are documented for Atlastix systems. For in-tenancy deployments, the customer or MSP operates production availability, backup and recovery.
Atlastix applies the Australian Privacy Principles as internal policy, including breach assessment under the Notifiable Data Breaches scheme. Customer data is processed only for contracted purposes. Suppliers that process customer data are published in the subprocessor register.
Assurance
The trust package is structured for customer due diligence: public summaries for initial review, controlled internal documents for detailed assessment, and walkthroughs for deployment-specific questions.
Initial review — no login required.
Scope, architecture, shared responsibility, customer-data handling, software delivery, AI and incident response.
Seventy-seven due-diligence answers covering governance, data, identity, engineering, resilience, suppliers and support.
Atlastix-managed processing, corporate services, AI-provider modes and the current Device Intelligence data path.
Detailed assessment — access code required.
Governance, risk, technical, engineering, data, people, supplier and resilience policies and registers.
ISO/IEC 27001:2022 Statement of Applicability and SOC 2 Security and Availability criteria mapping.
Deployment boundary, data flow, credential handling, AI-provider arrangement and shared responsibilities.
Deployment-specific questions — by arrangement.
A management-led review of relevant controls and authorised records for a defined customer assessment.
Customer review: request access for the controlled corpus or contact support@atlastix.io to arrange a scope-specific walkthrough.
Terms
ATX-SOC-08 summarises security topics for contract review and states the present control position. It is not a contract and creates no standalone commitment. The executed agreement defines binding scope, responsibilities, timing and remedies.
| # | Topic | Current position | Control reference |
|---|---|---|---|
| 1 | Shipped-software security | Release changes use pull-request change control, applicable automated checks, pre-release testing and controlled delivery. Junior-authored changes require senior review before merge; senior engineers may merge their own work under the team’s testing discipline, and fuller branch-protection enforcement is a planned control. Vulnerability findings are handled through the vulnerability-management process. | ATX-ENG-01ATX-ENG-02ATX-TEC-07 |
| 2 | Release traceability | Releases carry unique versions traceable to the exact GitHub commit and GitHub Actions workflow run that produced them. | ATX-ENG-01ATX-ENG-02 |
| 3 | Shipped-software vulnerability response | Confirmed vulnerabilities are assessed, tracked and communicated to nominated contacts. | ATX-TEC-07ATX-SOC-06 |
| 4 | Customisation change control | Per-deployment customisations and custom software follow the same pull-request change control, review requirements, applicable CI checks, testing and versioned delivery as product code, with rollback or recovery procedures appropriate to the deployment. | ATX-ENG-01ATX-ENG-02 |
| 5 | Approved engagement data | Customer-approved extracts or uploads and temporary customer-tenancy access are accepted only for an approved engagement. Content, processing location and access controls follow the product, deployed configuration and applicable agreement. | ATX-ENG-05ATX-ENG-06ATX-TEC-03 |
| 6 | Data retention and deletion | Primary and backup copies are retained and deleted under product-, deployment- and agreement-specific terms; written confirmation may be provided where required. | ATX-ENG-06 |
| 7 | Current Device Intelligence example | The current Device Intelligence deployment is a staging instance undergoing user acceptance testing, with no separate ongoing product or telemetry feed to Atlastix. Approved paths are point-in-time extracts or support uploads in Azure Australia East, or temporary MSP-tenancy access. Primary copies are deleted within 30 days; storage-level replicated copies are deleted with the primary and no separate backup copies are currently retained. | ATX-ENG-05ATX-ENG-06 |
| 8 | Support-access conduct | Access into a customer or MSP tenancy occurs only as customer-granted, temporary, scoped to the task, and logged in the customer’s environment; personnel are bound by confidentiality and acceptable use obligations. | ATX-TEC-01ATX-PPL-01 |
| 9 | Incident notification | Atlastix notifies the customer’s nominated contacts where an Atlastix-side incident affects their data or the integrity of software shipped to them; timing follows the applicable agreement and legal obligations. | ATX-RES-01 |
| 10 | Data breach cooperation | Incidents involving personal information are assessed under the Notifiable Data Breaches scheme; Atlastix provides the information customers reasonably need for their own regulatory assessments. | ATX-RES-05 |
| 11 | No training on customer data | Customer data is processed only for contracted purposes and is not sold. Atlastix does not use customer data to train AI models; training settings for customer-owned provider accounts are governed by the customer's provider terms (ATX-ENG-07). | ATX-PPL-06ATX-ENG-07 |
| 12 | Processor transparency | Processors used for approved customer data are disclosed in ATX-SOC-07. AI arrangements use the customer's own provider subscription and keys or the customer's cloud-native model service; subprocessor status follows the arrangement and agreement. | ATX-PPL-05 |
| 13 | Assurance sharing | Public assurance materials are maintained on this site. Controlled documentation and future third-party assurance materials are shared subject to their confidentiality and distribution terms. | ATX-SOC-05 |
| 14 | Security review | A documentation and control walkthrough may be arranged under confidentiality. Audit rights and the scope of evidence access are governed by the applicable agreement. | ATX-SOC-04ATX-GOV-08 |
| 15 | Vulnerability disclosure | A published disclosure channel with safe harbour covers Atlastix-operated systems and shipped software versions. | ATX-SOC-06ATX-TEC-07 |
For products and custom solutions delivered into a customer’s or MSP’s tenancy, customer agreements identify complementary customer controls such as securing the tenancy, operating backups and availability, applying released updates, following deployment guidance, and granting and revoking scoped support access (ATX-SOC-08 section 4).
Subprocessors
From the Subprocessor & Hosting Register (ATX-SOC-07). The register covers Atlastix-managed processing and corporate services, deployment-specific customer-tenancy delivery, and AI-provider modes across products and custom solutions. Part D covers the current Device Intelligence deployment. Supplier assurance belongs to suppliers, not Atlastix.
| Supplier | Purpose | Data processed | Location | Supplier assurance |
|---|---|---|---|---|
| Part A — Approved data handled by AtlastixCustomer-approved extracts or uploads and temporary customer-tenancy access support defined engagements; location and retention follow the deployment and agreement | ||||
| Amazon Web Services (AWS) | Applicable Atlastix development, build, delivery or corporate workloads | Depends on the approved workload and configuration | Applicable account, region and service configuration | Assurance follows the contracted service and configuration |
| Microsoft (Azure and Entra ID) | Applicable engineering or approved engagement-data processing; identity services for Atlastix personnel | Depends on the approved Azure workload; personnel identity data in Entra ID | Applicable tenant, deployment and service configuration | Assurance follows the contracted service and configuration |
| GitHub | Source control and CI/CD for product code and customisations; carve-out subservice organisation | Source code and engineering identities — no customer datasets | GitHub.com cloud (United States) | Assurance follows the contracted GitHub service and plan |
| Microsoft 365 | Email, calendar, documents, chat | Business correspondence, customer contact details, support correspondence | Microsoft online services | Assurance follows the contracted Microsoft 365 service and configuration |
| Supporting business suppliers | Team messaging; issue tracking and documentation; payroll and accounting; CRM and marketing; independent testing if commissioned | Customer contact details, engagement and support records, billing details and, if testing is commissioned, scoped vulnerability findings; raw customer datasets are not placed in these tools | Per the register (ATX-SOC-07) | Assurance is reviewed according to supplier risk and recorded internally |
| Part B — AI model providersThe approved product or deployment uses the customer's own provider subscription and keys or the customer's cloud-native model service | ||||
| AI provider for the deployment | AI inference under the approved product or solution design | Content and controls follow the approved purpose, configuration and agreement | Provider, customer environment and agreement specific | The customer's own provider account and cloud-native model service are part of the customer's supplier arrangement and are assessed by the customer; no Atlastix-managed provider receives customer workflow content |
| Part C — In-tenancy deploymentsCurrent delivery is generally in customer- or MSP-controlled cloud tenancies | ||||
| Customer’s or MSP’s own cloud provider | Runs deployed Atlastix products and custom solutions | Production workloads and primary data generally remain under customer or MSP controls. Any extract, upload, temporary access or ongoing integration follows the deployed configuration and agreement. | Customer or MSP tenancy and chosen regions | Contracted by the customer or MSP |
| Part D — Current Device Intelligence customer annexDeployment-specific annex; customer AI provider and keys or customer cloud-native model service | ||||
| Current Device Intelligence deployment | MSP-operated staging deployment undergoing user acceptance testing, with approved engagement support paths; production deployment has not yet commenced | Deployment data stays in the MSP tenancy. Approved extracts or uploads may include personal or end-client data but exclude credentials, tokens and secrets; temporary MSP-tenancy access may be used instead. | MSP tenancy; approved Atlastix copies in Azure Australia East | MSP cloud and AI providers are customer suppliers; Microsoft Azure is the approved Atlastix processor for transferred copies |
Supplier notification and incident terms are governed by the applicable agreement. Questions and update subscriptions: support@atlastix.io.
Disclosure
Atlastix accepts vulnerability reports from customers, MSPs, security researchers and any other party under the Vulnerability Disclosure Policy (ATX-SOC-06), which includes a safe harbour for good-faith research. The policy covers Atlastix-operated systems and shipped versions of Atlas Automate, Atlastix Observability and Atlastix Device Intelligence, wherever deployed.
In scope: websites and services under atlastix.io, Atlastix’s own cloud, build and corporate systems, and reports about shipped software versions. Out of scope: AWS, Microsoft and GitHub underlying infrastructure (report to those providers); a customer’s or MSP’s own tenancy — testing a deployed instance requires the authorisation of its operator, or an instance the researcher controls; and any denial-of-service, volumetric or physical testing. Researchers must use only accounts and data they control, and must stop and report on encountering data that is not theirs.
Include a description of the issue, steps to reproduce, and assessed impact. Anonymous reports are accepted. Scope questions can be sent to the same address.
support@atlastix.ioMonitored contact for security, support and vulnerability reports.
Support, incident and vulnerability timing is governed by the applicable agreement.
Documentation
6 public documents. The remainder of the ISMS corpus is available to customers and prospects under NDA.
ATX-SOC-03 Public
Covers ISMS scope, delivery and shared responsibility, approved engagement data, secure development, AI-provider modes, incident response, and the current Device Intelligence annex.
Read documentATX-SOC-04 Public
Answers 77 supplier due diligence questions across governance, certifications, deployment model, data handling, secure development, AI, personnel, resilience and support.
Read documentATX-SOC-05 Public
Explains the available due-diligence materials, review options and status of the frameworks used as control references.
Read documentATX-SOC-06 Public
Sets out how to report a vulnerability, the response process, rules of engagement and the safe harbour for good-faith security research.
Read documentATX-SOC-07 Public
Lists Atlastix-managed processing (Part A), AI-provider modes (Part B), in-tenancy delivery (Part C) and the current Device Intelligence annex (Part D).
Read documentATX-SOC-08 Public
Summarises 15 security, notification and data-handling topics for contract review, with shared responsibilities and control references.
Read documentThe policies, procedures and registers behind this page: governance, risk, technical, engineering & data, people & supplier, and resilience, including the management-prepared SOC 2 system description and Trust Services Criteria control mapping. Available to customers and prospects under NDA. Deployment-specific walkthroughs and authorised supporting records are available for relevant customer assessments.
New here? Request access.
FAQ
See the assurance-status statement at the top of this page and ATX-SOC-05 for the available review materials.
No. Atlastix does not host customer production workloads. Delivery is into customer- or MSP-controlled cloud tenancies; development and staging instances and approved engagement-data copies run in Atlastix’s environment under development-data enclave controls. Atlastix holds customer data as customer-approved extracts or uploads, through customer-granted temporary tenancy access, or through an approved, disclosed ongoing integration where one exists.
Data location is product-, deployment- and agreement-specific. Current production workloads generally remain in customer- or MSP-controlled tenancies; customer-approved extracts or uploads and temporary tenancy access may support an engagement. The current Device Intelligence deployment is covered under “Does Atlastix access our data?” and in ATX-SOC-07 Part D.
Only through approved paths defined for the product, engagement and agreement, generally customer-approved extracts or uploads or customer-granted temporary tenancy access. Location and retention are deployment-specific. For the current Device Intelligence deployment, copies are processed in Azure Australia East, primary copies are deleted within 30 days with storage-level replicated copies deleted alongside them, no separate backup copies are currently retained, and there is no separate ongoing feed.
Atlastix does not use customer data it receives to train AI models. AI-provider arrangements vary: the customer's own provider subscription and keys, or the customer's cloud-native model service, may apply. For the current Device Intelligence deployment, the customer controls the provider, account and keys and no workflow content reaches an Atlastix-managed provider.
Under the Incident Response Plan (ATX-RES-01), using a documented severity and escalation process. Customer communication, notification and response timing is governed by the applicable agreement. Notifiable data breaches are assessed under the NDB scheme in the Privacy Act 1988 (Cth), and significant incidents conclude with a post-incident review and tracked corrective actions.
Email support@atlastix.io. A management-led documentation review, evidence samples or control walkthrough may be arranged under NDA, subject to legal, security, contractual and customer restrictions. The completed self-assessment (ATX-SOC-04) is public on this page.