About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
An independent software vendor (ISV) should answer a residency questionnaire with a data-flow map and evidence for each claim. Identify where customer information is stored, where copies and operational records go, who can access them and which organisations provide those services. A hosting region is one part of that answer.
Separate facts you can demonstrate from contractual promises and legal conclusions. Record unknowns and assign an owner to resolve them before sales turns them into an assurance. The workflow below helps a software provider prepare answers for its customers; it does not determine legal compliance.
Establish which obligations apply
Australia's Privacy Act and Australian Privacy Principles do not apply identically to every business. OAIC chapter B explains the term APP entity and relevant exclusions. Confirm your organisation's and customer's position with qualified advisers, together with sector-specific and contractual requirements.
OAIC chapter 8 distinguishes handling within effective control from disclosure outside it. Overseas contractors generally raise disclosure obligations, although limited arrangements may constitute use. Contract terms and actual control matter. A foreign region or Australian disk location alone does not settle the analysis.
OAIC chapter 11 addresses reasonable security measures for personal information an APP entity holds. The following operational checklist is our recommendation for assembling facts, not a legal test.
Inventory the information, not only the database
Start with what your application receives, creates and exports. Map customer records, uploaded documents, audit events, support attachments, integration payloads and any analytics or diagnostic records that contain customer information.
For each class, record the purpose, owner, production location, copy destinations, retention policy and access roles. Distinguish personal information from other commercially sensitive data, while preserving protection appropriate to both.
A useful register might have these entries:
| Information class | Questions to resolve | Evidence to retain |
|---|---|---|
| Application records | Which configured region holds the active data? Is there replication? | Current configuration and provider terms |
| Attachments | Are they in the same location as the database? | Storage inventory and application configuration |
| Backups and recovery copies | Where are copies stored, and who can restore them? | Backup configuration, access scope and restore policy |
| Support material | Can tickets include exports, screenshots or log excerpts? | Ticketing workflow, access policy and supplier terms |
| Diagnostics | What fields leave the application, and where do they go? | Logging configuration, sample redacted records and destination inventory |
Record the observation date. A diagram made before a new analytics integration was added may no longer describe the service.
Trace organisations and access paths
List the supplier for each hosting, identity, email, support and monitoring component. A supplier name without the actual service and configuration is insufficient for a precise answer. Identify relevant subcontractors where the supplier's current documentation and contract disclose them.
For operational access, document who can reach production, from which authorised locations, through what approval process and with what audit trail. Distinguish ordinary support access from emergency access. Ask whether diagnostic workflows copy information to another system, not only whether an engineer can view the production screen.
Record key custody accurately. Identify who administers the key service and who can request decryption through the application or its infrastructure. Do not claim that a customer-managed key automatically prevents every provider access path. Verify the specific architecture before making an assurance.
These are factual questions for your technical and commercial teams. Whether a particular arrangement is a use, disclosure or legally acceptable transfer belongs in the separate privacy assessment.
Turn findings into a buyer-facing answer
Avoid a bare yes/no response to “Does all data stay in Australia?” Ask what the buyer means by data and which operations they are asking about. Then give a scoped answer with its evidence and limitations.
For example, an illustrative response might distinguish Australian production storage from an overseas support service that receives approved diagnostic extracts. This is a made-up example, not a description of NetLeverage or a claim that such an arrangement satisfies a particular buyer's requirements.
A practical answer pack should include:
- A dated architecture diagram showing data paths and external services.
- A location and access register with confirmed facts and outstanding questions.
- The relevant supplier and customer contract provisions.
- Retention and exit arrangements, including backups and support records.
- The review owner and the changes that trigger reassessment.
Keep supporting configuration evidence under controlled access. Buyers need enough information to assess the service, not credentials, sensitive network details or another customer's records.
Handle buyer-specific requirements explicitly
An Australian commercial customer, a health organisation and a government buyer may have different obligations and contract conditions. Do not turn a requirement from one procurement exercise into a universal rule for all hosted software.
When a buyer requires a specific location, staff-access restriction or assurance, map it to the actual component and owner. Identify whether the requirement is already met, needs a separately approved change, or cannot be supported. Avoid promising a special arrangement until operations and the responsible commercial team have accepted it.
If the customer expands internationally, repeat the assessment for the new destinations and requirements. The Australian evidence pack remains useful, but it does not by itself answer another jurisdiction's rules.
Keep the answer current
Our recommendation is to attach this register to the service's change process. A new subprocessor, support location, backup target, AI feature or diagnostic integration should prompt a check of affected customer answers and contractual commitments.
Sample the evidence after material changes. Confirm that documented destinations match configuration, that access owners remain current and that retention statements match the implemented workflow. Record exceptions with a responsible owner instead of leaving an unqualified marketing statement in circulation.
Software vendor hosting is the relevant service area for discussing hosting requirements. This article does not assert NetLeverage certification, sovereignty, supplier status or a particular data-location guarantee.
Limits and sources
This is a source-researched method for preparing evidence, not legal advice or a completed privacy assessment. No customer architecture or live access configuration was audited for this article. Government classification-specific controls are deliberately outside its general commercial scope.
- OAIC chapter B: Key concepts, version 1.4, published 21 December 2022; accessed 14 November 2026.
- OAIC chapter 8: Cross-border disclosure, updated 3 October 2025; accessed 14 November 2026.
- OAIC chapter 11: Security of personal information, updated 3 October 2025; accessed 14 November 2026.
Learning notes
Storage location, information handling and access are separate facts. A scoped answer with dated evidence is more useful than an unsupported assurance. Reassess the answer when the service or its suppliers change.
This article was originally published on .