ISO-aligned · data-sovereign · audit-ready
Security & Compliance.
Every platform XCentral-Framework builds inherits the framework’s security posture — a methodology engineered to align with ISO 9001, ISO/IEC 27001, and ISO/IEC 42001; Australian data residency; a full audit trail; AI isolation between client tenants; and an architecture shaped around the controls reviewers actually ask about. This page is written for the people doing the due diligence.
Inherited security posture
The posture comes with the platform.
Security isn’t a phase you bolt on at the end. It is a property of the framework, applied the same way on every build — so the controls below are present from go-live, not promised for later.
Microsoft-native by binding rule
Identity, hosting, data, AI, and communications all run on the Microsoft cloud — Entra ID, Azure App Service, Azure SQL, Azure OpenAI, Azure Communication Services. One identity surface, one audit surface, one compliance boundary, instead of a sprawl of third-party tools to assess.
Australian data residency
Production data for Australian engagements stays in Australian-sovereign Azure regions — australiaeast (Sydney) primary, australiasoutheast (Melbourne) for disaster recovery. Residency is a default of the framework, not a per-project negotiation.
Audit trail as a byproduct
Security-sensitive operations write to a dedicated, append-only audit-log table separate from operational logs. Change history lives in Azure DevOps; pipeline-gate records live in the build artefacts. Evidence is generated by normal operation, not assembled after the fact.
AI isolation between tenants
AI runs on Azure OpenAI inside each customer’s own Azure tenant via managed identity. One client’s data is never a path to another’s — there is no shared model fine-tuned across clients, and no customer data trains a foundation model.
Built for the controls reviewers ask about
RBAC enforced at the API, encryption in transit and at rest, secrets in Key Vault, optimistic concurrency, soft-delete with retention, right-of-erasure tooling — the architecture is shaped around the questions a security reviewer actually brings to due diligence.
Inherited, not bolted on
Every platform XCentral-Framework builds starts from this posture. It is the default of the framework, applied the same way on every engagement — so the security story is consistent across the portfolio rather than reinvented per build.
Standards alignment
Aligned with ISO 9001, 27001 & 42001 — stated honestly.
We are deliberate about this wording, because it matters to a reviewer: it is a statement about how the platform is engineered, not a certification claim.
ISO 9001
Quality Management
Framework engineered to align
ISO/IEC 27001
Information Security Management
Framework engineered to align
ISO/IEC 42001:2023
AI Management Systems
Framework engineered to align
What “aligned with” means
XCentral-Framework is engineered to meet the kind of controls ISO 9001 (quality management), ISO/IEC 27001 (information security), and ISO/IEC 42001:2023 (AI management systems) describe — documented change control, access control, audit logging, risk identification, quality gates, and AI governance — built into the binding rules, the pipeline, and the architecture. The controls are real and they ship with the platform.
What it is not
XCentral Solutions Pty Ltd is not itself ISO-certified, and this page does not claim a certification. Where an XCentral platform is delivered through an ISO-certified delivery partner, the engagement runs under that partner’s certified processes and inherits those controls per engagement. Where XCentral Solutions delivers direct, the framework-aligned controls described here apply. Certification, where it is held, belongs to the delivery partner — not to the framework vendor.
Data residency
Australian data stays in Australia.
For Australian engagements, production data is deployed to Australian-sovereign Azure regions by default. The Privacy Act 1988 residency expectation is met by the framework’s default region selection, not by a one-off arrangement.
- Primary region
- australiaeast (Sydney, NSW)
- Disaster-recovery region
- australiasoutheast (Melbourne, VIC)
- Encryption at rest
- Azure SQL Transparent Data Encryption; Key Vault for field-level secrets
- Encryption in transit
- TLS across every hop; HSTS enforced at the edge
A non-Australian region is the exception, not the default — it requires an explicit, documented decision for the engagement, with a recorded lawful basis for any cross-border data flow.
Controls
Audit trail, access control, encryption.
The controls a security reviewer expects to see — enforced at the API, the data layer, and the edge.
- Authentication
- Microsoft Entra ID with OAuth 2.0 / OpenID Connect; MFA and conditional access through the directory the client already operates. JWT bearer tokens validated on every API request — issuer, audience, expiry, signature.
- Authorisation (RBAC)
- Role-based access control via Entra ID App Roles, delivered as JWT claims and enforced at the API. The API is the security boundary; frontend role checks are UX-only. There is no client-side enforcement to bypass.
- Encryption
- Encryption in transit (TLS) and at rest (Azure SQL TDE) everywhere. Tier-4 fields — credentials, tokens, account numbers, health data, government IDs — get field-level encryption via Key Vault and are not stored if they can be avoided.
- Audit logging
- A dedicated, append-only audit-log table records security-sensitive operations — separate from operational logs, with a minimum 12-month retention. Who did what, to which record, when.
- Secrets management
- All secrets resolve from Azure Key Vault references; managed identity authenticates every Azure-internal hop in staging and production. No keys in source, environment variables, or app-settings literals.
- Edge protection
- Azure Front Door with a Web Application Firewall in prevention mode, plus platform DDoS protection, fronts production deployments. CORS origins are listed explicitly per environment and per portal.
AI isolation
One tenant’s data is never a path to another’s.
AI is the question reviewers ask hardest about. The framework’s answer is architectural: the model runs in your tenant, on your data, inside your boundary.
- Models run on Azure OpenAI inside the customer’s own Azure tenant, reached via managed identity — no shared API keys.
- Inputs and outputs stay inside the customer’s Azure compliance boundary; for Australian clients, that boundary is in Australia.
- No customer data is used to train or fine-tune a foundation model. Foundation models are used as-is unless fine-tuning is separately and explicitly contracted.
- There is no model shared and tuned across clients — one tenant’s data is never a route into another’s.
- Every AI invocation is audit-logged, and mutating actions require a human approval step before the application executes them.
The full AI governance model — tier classification, the refusal doctrine, the human-in-the-loop boundary on mutating actions — is set out for technical evaluators on the architecture page.
Sub-processors & the DPA
Who else touches the data.
The platform is built on Microsoft Azure — the cloud the framework runs on for hosting, identity, data, AI, and communications. Azure is the foundational sub-processor for every platform we build, and your data resides within the Azure regions described above.
Any additional sub-processor engaged to deliver part of a platform is bound by a written data processing agreement to the same protection standards. The complete, current sub-processor list for an engagement is provided through the data processing agreement and is available on request — we do not publish an invented or out-of-date list here. Our own corporate privacy practice and disclosure terms are set out in the Privacy Policy.
Need the full sub-processor list and the DPA for a specific engagement? Ask us — due-diligence requests are exactly the conversations we want to have early.
Secure Frontier
Beyond the build: managed security.
A secure architecture is the foundation, not the whole job. Ongoing security operations — monitoring, threat detection, response, and posture management — are a discipline in their own right.
Through our Secure Frontier programme, we partner with managed-security operators so the platform we build can be wrapped in ongoing managed-security services where an engagement wants them — continuous monitoring, detection and response, and security posture management on top of the framework’s built-in controls.
If managed security is part of what you need, we’ll talk it through at discovery and connect the right operator to the engagement.
Ownership
You own your production code (mirrored to your Azure DevOps), your data, and your Azure infrastructure. We retain XCentral-Framework — the proprietary IP that built and continues to improve your platform.
Bring your security questionnaire.
We’d rather answer the hard questions early than discover them late. Send the due-diligence list, the DPA request, or the security questionnaire — it’s the start of the conversation, not the end of it.