Accountability does not transfer with the work
The central principle of Australian privacy law, for any organisation outsourcing work that touches personal information, is that outsourcing the function does not outsource the responsibility. Under Australian Privacy Principle 8 and section 16C of the Privacy Act 1988 (Cth), an Australian entity that discloses personal information to an overseas recipient, including an outsourcing provider, must take reasonable steps to ensure that recipient does not breach the Australian Privacy Principles. If the overseas recipient does cause a breach, section 16C treats the Australian entity as though it had breached the principle itself. The organisation, not the provider, answers to the Office of the Australian Information Commissioner and to its own customers.
This reframes the diligence exercise from a purely commercial one into a compliance one. Choosing a provider is not only a decision about capability and price. It is a decision about which entity's controls the business is effectively adopting as its own, because the business remains legally answerable for what that provider does with the data regardless of where the provider is physically located. A risk function cannot treat an outsourcing provider as a black box whose internal practices are the provider's own business. It has to be able to describe what the provider does with the data, on what basis, and under what controls, because those are the facts a regulator or an affected customer will eventually ask the business, not the provider, to account for.
This paper sets out what sound data governance requires when personal information is handled by an outsourced operation under Australian and New Zealand privacy law. It is organised around the questions a risk committee actually asks, because those questions are the operational form the law takes in practice. It is general information for buyers, not legal advice, and any organisation with specific privacy exposure should take its own advice on its obligations.
Two regimes, two different postures toward offshore processing
Australian and New Zealand privacy law take genuinely different postures toward sending personal information to an overseas provider, and a business operating across both markets has to design governance that satisfies both rather than assuming one covers the other.
The Privacy Act 1988 (Cth) is built on thirteen Australian Privacy Principles covering collection, use, disclosure, security and access, among others. Australian Privacy Principle 8, together with section 16C, is the provision that governs outsourcing directly: before disclosing personal information overseas, the Australian entity must take reasonable steps to ensure the overseas recipient will not breach the Australian Privacy Principles, and stays accountable if it does. This is an accountability-retention model. The obligation does not lighten because the work has moved offshore; if anything, it requires more documented diligence than keeping the work onshore would.
New Zealand's Privacy Act 2020 takes a more permissive position for the specific case that matters most in outsourcing. Under Information Privacy Principle 12, personal information sent overseas purely for safe custody or processing on the New Zealand agency's own behalf, where the overseas provider does not use that information for its own purposes, is not treated as a "disclosure" under the Act at all. This service-provider exception is a materially lighter compliance position than the Australian rule, provided the arrangement is genuinely a processing relationship rather than one where the provider has its own independent use for the data.
The practical consequence for a business operating in both markets is that governance has to be designed to the stricter of the two standards, which in practice means designing to the Australian APP 8 standard as the baseline and treating the New Zealand service-provider exception as a genuine, welcome simplification for New Zealand-only data rather than assuming it extends to Australian data, which it does not.
Residency: where the data lives and what crosses a border
The first governance question is the literal one: where does the personal information physically reside, what is merely accessed in session by an offshore team versus stored on the provider's own systems, and does anything cross a border that the client has not explicitly considered.
The distinction between accessed and stored matters because it changes the risk profile materially. Information that an offshore team accesses in session, through a client-controlled system, and never persists on the provider's own infrastructure carries a different exposure than information the provider holds at rest. A credible governance model states explicitly which applies to each category of data in the engagement, and a provider that cannot answer this precisely has not actually mapped its own data flows.
Cross-border flow is where Australian Privacy Principle 8 does its real work. It requires the Australian entity to take reasonable steps before that flow happens, which in practice means documenting the destination, the protections the recipient has in place, and the basis for concluding those protections are adequate. This makes the physical location of offshore delivery a deliberate, documented decision rather than an incidental detail buried in a statement of work. It is also worth being direct about a consideration beyond the strict legal test: data held in some overseas jurisdictions may be reachable by that jurisdiction's own government under its own law, independent of any contractual protection the provider offers, and a risk committee handling sensitive Australian or New Zealand customer data is entitled to weigh that fact when it decides where an engagement should be delivered from.
Access control that can be proven, not just asserted
The second governance question concerns people, and it is where many outsourcing arrangements are weakest in practice, not in policy. The question is not whether access to personal information is controlled. Almost every provider will say it is. The question is whether the business can verify that access stays controlled over time, after the initial sales conversation and the initial audit are both long past.
A sound access model has several components that a governance review should be able to check individually. Role-based access restricts each team member to what their specific function requires, not to the full dataset by default. Session-level logging records who accessed what and when, creating an audit trail rather than a promise. A documented joiner-mover-leaver process ties system access to current employment status and current role, so access changes automatically when a person's role changes rather than accumulating indefinitely. Periodic access recertification reviews existing permissions on a defined cycle and actively revokes anything no longer needed for the person's current function.
Recertification is the component that most often fails in practice and the one a sharp risk reviewer probes first, because access granted for a specific project and never subsequently revoked is the single most common finding in any real access audit. A control that exists in a policy document but is never actually reviewed is not a control a business can rely on for its own compliance. Sound governance therefore specifies not just that access is restricted at the outset, but how that restriction is verified to persist, with a named recertification cycle, a named owner, and an auditable record a client can actually request to see.
Notifiable data breaches, inspection and individual rights
Three further requirements turn a governance policy into something a risk committee can actually approve rather than merely read.
The Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth) requires notification to affected individuals and to the OAIC where an eligible data breach is likely to result in serious harm. The scheme applies to entities with annual turnover over $3 million, and separately, regardless of turnover, to specific categories including health service providers, so a business should not assume the scheme is inapplicable purely on the basis of its own size if it operates in a covered category. Because a provider's own detection and escalation speed directly determines whether the client can meet its own statutory notification obligations, governance should specify a defined notification window measured in hours, named contacts on both sides, and a documented incident protocol agreed in advance rather than improvised during an actual incident. The provider detects and escalates; the client assesses and, where required, notifies; both steps have to fit inside the statutory clock, which means the handoff between them cannot be the first time either party has thought about how it works.
Inspection is frequently the factor that actually decides whether a risk committee approves an arrangement. A right-to-audit clause, with on-site or equivalent inspection exercisable on reasonable notice, is what separates a verifiable arrangement from an unverifiable assurance. A provider unwilling to accept inspection is, in effect, asking the client to take its controls on faith, and the most common reason a risk function declines an outsourcing proposal is precisely the suspicion that no one will ever actually go and check.
Individual rights have to be operable through the provider, not just theoretically available. Where a provider holds or processes personal information, the client organisation needs that provider to be able to locate, correct or delete the relevant record within whatever timeframe the client's own obligations require. An operation that was never designed with these workflows in mind cannot support a compliant response when a customer actually exercises their rights, which makes this a governance requirement to specify up front rather than something to solve reactively.
What this means in practice, and where Corpshore fits
A consistent pattern runs through every requirement in this paper. Residency is clear when the destination and the data flow are documented before the fact, not discovered after. Access is verifiable when recertification is a real, scheduled, owned process rather than a line in a policy. Notification obligations are met when the provider's escalation speed is fast enough to fit inside the client's own statutory clock. Individual rights are operable when the provider's systems were built to support them. None of this requires exotic controls. It requires a provider that has actually thought through these questions in advance rather than one that will improvise an answer when a client first asks.
The specific things worth putting in a contract, drawn directly from the sections above: a named point of contact for privacy and security matters within the provider's account team; explicit documentation of what data is accessed versus stored, and where; role-based access with a defined, auditable recertification cycle; a right to audit with practical, exercisable inspection rights; a documented incident-response protocol with a defined notification window measured in hours; operable workflows for individual access, correction and deletion requests; and disclosure and approval rights over any sub-processor the provider itself relies on.
Corpshore Australia's contracts, access controls and reporting are built to support an Australian client's own APP 8 and section 16C obligations directly, and New Zealand engagements are structured to take advantage of the Privacy Act 2020's service-provider exception under Information Privacy Principle 12 where the arrangement genuinely qualifies for it. Corpshore's security practices align with the Essential Eight, the Australian Cyber Security Centre's prioritised mitigation framework, stated here as alignment rather than as a claim to any certified maturity level Corpshore has not independently verified. For a risk committee, the value of that is not the claim itself, it is that the specific questions this paper is organised around have short, checkable answers rather than ones that require a long, uncertain investigation. Full detail is set out on the compliance and security page, and a specific engagement's data-handling requirements can be scoped directly through a discovery call.