Data Residency for Australian MSP SaaS

Australian MSPs and government supply chains ask where data lives-script content, audit rows, agent metadata, administrator identities, and support artifacts. Data residency is a procurement and SSP topic, not a hero banner slogan.

Trustholm launches with Australian region options documented in hosting and procurement materials. Exact residency for your contract is confirmed during commercial onboarding with subprocessors table and architecture diagram-not inferred from generic SaaS claims.

What typically resides in tenant schema

Per-tenant PostgreSQL schema holds:

• Agent registration and inventory metadata
• Script library content and versions
• Security audit rows
• Monitoring configuration when module enabled
• User and role records for portal access

Classification depends on what your technicians put in scripts-credentials should follow secrets hygiene regardless of residency.

What may leave the primary region

Subprocessors (email delivery, support tooling, analytics if enabled) may process metadata in other regions. Request the subprocessor list during trial and map to your privacy impact assessment.

Trustholm does not claim automatic sovereignty compliance for all Australian government classifications without system-specific assessment.

Dedicated vs shared infrastructure

Schema-per-tenant is logical separation on shared or dedicated database infrastructure. DedicatedDatabase connection profiles support buyers needing separate database instances. Cluster-dedicated profiles remain roadmap-state honestly in diagrams.

Encryption and keys

Transit encryption uses TLS for API and portal traffic. At-rest encryption depends on hosting environment configuration consumers validate with operator documentation. Customer-managed keys may be enterprise discussion-not assumed default.

Backup and DR geography

Backup replicas and disaster recovery targets must appear in your vendor risk review. If replicas cross borders, SSP and privacy docs must say so. Trustholm procurement packet addresses patterns; your legal review confirms sufficiency.

Contractual beats marketing

Marketing pages orient buyers; DPA, subprocessor appendix, and hosting matrix in contract define enforceable residency commitments. MSPs reselling services should flow down commitments to end-customers accurately.

Evaluation checklist for Australian buyers

1. Request AU region hosting confirmation in writing
2. Map subprocessor countries and purposes
3. Identify script content classification per agency rules
4. Document audit export storage location when copied to your GRC
5. Align with Privacy Act and agency-specific policies
6. Pair residency with isolation architecture (schema-per-tenant) and access controls

Honest positioning

We provide evidence for your control matrix including isolation and export-we do not claim IRAP, ISM, or SOC 2 attestation on residency pages alone.

Contract negotiation prompts

Ask explicitly: primary database region, backup replica regions, support personnel locations, disaster recovery failover geography, and data deletion timelines on contract termination. Require subprocessor notification periods for new vendors. Map answers to Privacy Act and agency policies with legal counsel-not sales summaries alone.

MSP reseller flow-down checklist

If you resell managed services atop Trustholm, verify end-customer DPAs accurately describe where audit exports land when copied to US GRC tools while tenant database remains in AU. Misaligned flow-down creates privacy findings independent of vendor architecture. Legal should review marketing one-pagers before customer-facing distribution.

Trust hub cross-reference

Request procurement artifacts via /trust hub and document AU region options in contract schedules-not inferred from marketing pages alone.

Appendix: evidence reproduction steps

Assign a reviewer to open trial tenant, navigate documented UI paths, and capture screenshots with timestamps. Export audit JSON for same session.

Store in immutable GRC folder. Compare results to this article quarterly.

When Shipped/Gap rows change in trust hub, re-run reproduction within ten business days. Attach limitations memo for WORM audit and Sentinel connector backlog.

Include DB operator access policy from hosting provider. Pair technical evidence with customer governance documents-policies, pentest summaries, IR runbooks.

Never substitute marketing copy for reproduced checks in front of assessors. Treat this appendix as a living runbook section owned by security engineering, not a one-time audit artifact.

Schedule annual refresh aligned with trust hub version stamps and major product releases. Link each reproduction run to a change ticket for traceability.

Distribute updated article PDFs to customer-facing teams when dateModified changes. Archive prior versions for twelve months to support assessor lookback questions.

When citing this article externally, include dateModified and pillar metadata in footnotes so readers know content freshness. Internal enablement should link pillar tags to trust hub sections for consistent customer messaging.

Add article slug to internal wiki index for sales engineering quick lookup during live questionnaire calls.