CPS 230 offshoring review: questions beyond data location

“The data stays in Australia” is useful information, but it does not finish an offshoring review. Staff overseas may access that data, perform support work or control recovery steps while the storage location stays unchanged.

Start by mapping the work, people and access that move. Then ask the operational, prudential, contractual and privacy questions separately. They are related, but one answer does not settle all of them.

This is an educational review aid, not legal advice. The proposed workflow and example are original suggestions. Risk, legal, privacy and technology owners should assess the actual arrangement against the rules that apply to the entity.

Define the service change accurately

In a fictional example, an Australian insurer's application provider proposes moving overnight support to an overseas team. Production hosting remains in Australia. The new team will investigate incidents, view diagnostic information and request elevated access when required.

The provider describes the change as a staffing adjustment. The insurer records the tasks rather than relying on that label. Who will perform them, from where, for which legal entity and under what supervision?

Identify the proposed start date and any trial period. Ask whether subcontractors are involved and whether the new team replaces an existing capability or adds another layer. Record which facts are confirmed and which remain provisional.

All organisations and circumstances in this example are invented. No particular country or provider is being assessed.

Map four locations, not one

A practical intake distinguishes four things:

• Where the service is performed, including routine work and emergency support.
• Where the people performing it are located and employed.
• Where relevant information is stored, processed, backed up or logged.
• Where people can access that information and the systems controlling the service.

These locations may overlap, but they should not be assumed to do so. A local hosting statement might exclude diagnostic logs, support tickets or backups. A remote-support statement might omit subcontractors used outside normal hours.

Ask for a service-specific description. A provider-wide country list can be a useful starting point, but it may not explain which locations matter to this arrangement.

For the fictional insurer, the key gap is diagnostic information. The provider confirms that support tickets can include extracts from production logs. The team now needs to understand what those extracts contain and how they are handled.

Assess the prudential question early

CPS 230 requires prior APRA notification for material offshoring arrangements and proposed significant changes, including relevant offshore data or personnel. Check the current wording and applicability with the responsible owner before the decision or change proceeds.

Do not replace that assessment with a blanket statement that all overseas activity is banned or requires regulatory approval. Notification, approval and the entity's internal authorisation are different concepts. The review should identify which process applies and when it must occur.

APRA's CPG 230 guidance discusses jurisdictional risk, continuity and possible impediments to regulatory access. Use those areas to frame questions about the actual support model.

In this example, legal and risk review the arrangement while technology clarifies access. Running those enquiries together avoids discovering a timing requirement only after the operational team is ready to switch.

Keep privacy analysis separate

For entities subject to the Australian Privacy Principles, the OAIC's APP 8 guidance distinguishes overseas disclosure from use. Providing information to an overseas contractor is generally a disclosure, but limited circumstances involving effective control may be treated as use. Overseas hosting alone does not settle the question.

The privacy owner needs the facts: which personal information may be accessed, by whom, for what purpose, under which controls and with what ability to restrict further handling. Confirm the entity's applicable obligations rather than assuming APP 8 applies identically to every organisation.

A conclusion that an arrangement is a use does not mean privacy responsibilities disappear. The OAIC guidance also addresses continuing obligations where the entity retains control.

For the fictional insurer, the team reviews the diagnostic-log content and support-ticket process before deciding whether the proposed access can proceed. It does not send real claims data overseas simply to demonstrate the workflow. Testing can begin with synthetic records and a defined access design.

Examine continuity and oversight in practice

Ask what happens if the overseas support location becomes unavailable. Can another team perform the same tasks? Does it have current knowledge, access and capacity? Does the handover depend on tools or people affected by the same disruption?

Check operating hours, language requirements where relevant, escalation routes and decision authority. A longer support window is helpful only if the team can actually perform the required work or reach someone who can.

For regulatory and assurance access, ask how relevant records can be obtained in a usable form and whether legal or technical restrictions could impede access. This needs appropriate legal review; a supplier's general assurance is not a substitute for understanding the arrangement.

The insurer's fictional walkthrough finds that the overnight team can investigate an incident but cannot reach the person authorised to approve a recovery action. The service change therefore creates an unresolved escalation dependency even though hosting is unchanged.

Use decision checkpoints

A compact review can have four checkpoints.

Scope established: the tasks, entities, locations, information and access are described well enough for assessment.

Obligations assessed: legal, risk and privacy owners identify applicable contractual and regulatory steps, including timing. Record unresolved interpretations and who will resolve them.

Controls demonstrated: the proposed access, escalation, monitoring and fallback arrangements have evidence appropriate to the risk. A policy statement alone may leave important operational questions open.

Implementation authorised and verified: the decision-maker knows the conditions and remaining risks. After the change, the service owner checks that the implemented arrangement matches what was reviewed.

These are suggested checkpoints, not an APRA-issued approval sequence.

Close the specific gaps before declaring completion

In the fictional example, the provider revises the overnight escalation route and demonstrates it with a synthetic incident. The privacy and security owners review the diagnostic-data handling design. Legal and risk complete the applicable notification and contract assessment before implementation.

The final record preserves the proposed scope, evidence, decisions, conditions and post-change check. It also identifies triggers for another review, such as a new country, subcontractor, data category or permission level.

If the relocation involves a new downstream provider, the subcontractor-change review helps separate confirmed service changes from assumptions carried forward from the old arrangement.

Start the next offshoring review by asking the provider to describe a single support case from receipt to resolution. Follow the people, systems and information involved. That gives the reviewers a more reliable foundation than a statement about where the main database sits.