How Australian Businesses Protect IP and Data When Working With Offshore Software Development Partners

Australian organisations notified the OAIC of 1,205 data breaches in 2025 — the highest number since the scheme began in 2018 (OAIC, Notifiable Data Breach statistics). In the first half of that year, human error accounted for 37% of them. Much of that exposure is not sophisticated. It arises from ordinary handling of real information by people, systems or processes that had more access than they needed.

That matters when a development team sits outside your organisation, because the question is not whether the team is trustworthy. It is how much they need to be trusted with in the first place. Offshore delivery does not automatically mean losing control of your intellectual property or your customer data — but that control has to be designed in rather than assumed.

How can Australian businesses protect IP and data when working with offshore software development partners? By controlling five things, all of which can be checked before a contract is signed: written assignment of IP ownership, minimised data exposure, a client-controlled production environment, a clear accountability chain under Australian privacy obligations, and a security certification whose scope you have actually read.

Evaluations tend to focus on delivery capability: portfolio, stack, rates, team size. Those matter, but they do not tell you whether you will still control your own assets in two years. None of the five below is answered by a proposal — each is answered by how the delivery model is built, and each is quick to test before you sign.

"Of course the code is yours" is the answer worth interrogating, because the default may not run the way you assume.

Under the Copyright Act 1968 (Cth), copyright generally belongs to the author of a work unless ownership is otherwise assigned or a different statutory rule applies. For software written by an external contractor, that means the developer may be the copyright owner unless the agreement expressly transfers it. Employees are different: work created in the course of employment generally belongs to the employer. That default does not travel to an external team.

Transferring ownership requires an assignment in writing. Not an invoice, not an email, not the fact that it was your idea.

What to ask: does the agreement expressly assign source code, architecture and technical documentation? What is carved out? Are subcontractors bound by the same obligations? And can we pull the complete, buildable source at any time without asking permission?

What client ownership looks like: an NDA signed before the technical conversation begins; deliverables expressly assigned under the MSA and SOW with carve-outs named rather than hidden; and subcontractors bound by obligations of equal rigor. That is Shinetech's standard arrangement, and it is the shape to look for in anyone's. Since 2001 we have maintained a record with no reported IP disputes — history rather than a guarantee about your project.

One more question no contract fully covers: does the vendor build and sell its own software products? A firm competing in your market has a commercial reason to be interested in your work. Shinetech provides technology services and does not develop or sell its own software products — a structural answer rather than a promise.

Contracts allocate blame after the fact. Architecture decides whether there is anything to allocate.

The more durable approach is not adding controls around sensitive data, but reducing how much sensitive data needs to exist outside your environment at all. For a large share of development and testing work the answer to "what do you actually need?" is: none of it. Feature development, unit testing and load testing generally do not need real customer records — they need data that behaves like real customer records. Removing real records from those environments reduces both the privacy exposure and the ongoing operational burden of securing real customer information across development environments.

The same logic applies to source code. If coding standards prohibit hardcoding personal information, the codebase carries no personal data, and where it is stored becomes an asset-management question rather than a compliance one.

What to ask: for each environment — development, testing, staging, production support — what data would your team actually hold? Is real data the default, the exception, or never? "We follow strict security protocols" describes intent, not data flow. Keep asking until you get an inventory.

What reduced exposure looks like: synthetic data as the default for development and testing — non-reversible, containing no real personal information — with masked or real data used only under written consent and audit. Shinetech works this way, and coding standards prohibit hardcoding personal information so the codebase carries none either.

A vendor that hosts your production environment holds your live data, your access logs and your audit trail. A vendor that does not, cannot.

What to ask: does the provider host or back up any part of our production environment? Whose cloud account is it? How do they access it for support, and is that access logged in a way we can review?

What client-controlled production looks like: the provider hosts nothing. Shinetech does not run production environments or sell SaaS products, so control, access and audit rights stay in your cloud account. Support access runs only through methods you authorise — VPN, bastion host, jump server — and can be screen-recorded where a bastion host is in place.

This is the one factor you cannot design around, only prepare for.

Australian Privacy Principle 8 governs cross-border disclosure. Before disclosing personal information overseas, an APP entity must take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles — and remains accountable for any acts or practices of that recipient that would breach them (OAIC, APP 8 guidelines).

Contracts can allocate commercial responsibilities between you and a supplier. What they do not remove are the obligations that apply to the Australian entity under the Privacy Act when personal information is disclosed overseas — which is exactly why "we never needed that data" is a stronger position than "we protected that data carefully."

A statutory tort for serious invasions of privacy commenced on 10 June 2025 under the Privacy and Other Legislation Amendment Act 2024, giving individuals a direct right to sue and adding civil consequences to privacy incidents alongside the regulatory ones.

A second obligation turns a supplier's slowness into your legal problem. Under the Notifiable Data Breaches scheme, if you have reasonable grounds to suspect an eligible data breach, you must carry out an assessment and take all reasonable steps to complete it within 30 calendar days of becoming aware of those grounds. That window is for establishing whether a breach occurred and whether serious harm is likely — not for issuing the notification. An incident noticed by your partner early in the month but passed to you three weeks later leaves you the remainder of it to assess serious harm, in a system you do not administer, using logs you have to request. The plan existed. The clock was the problem.

What to ask: who are we contracting with, and how are privacy, security and incident obligations allocated in that contract? And what is the incident notification window, in hours, in writing?

What clear accountability looks like: the arrangement documented before work starts — named roles on both sides, a defined escalation path, and a notification window expressed in hours rather than in adjectives. Where development is performed by an overseas engineering team, which entity carries which privacy, security and incident obligations should be written down and agreed, not inferred from an organisation chart.

An ISO 27001 certificate applies to a named legal entity and named sites, not to a company as a whole. A certificate covering one office may not tell you whether the team supporting your engagement is within scope.

What to ask: which entity and which sites are inside the scope? Can you send the certificate, not the logo?

What scope transparency looks like: the scope published alongside the logo. Shinetech holds ISO 27001:2022 scoped to its Beijing headquarters and Cyber Essentials Plus scoped to its UK subsidiary — stated because a certificate whose boundaries you cannot check is a logo rather than evidence. Put the same question to everyone on your shortlist.

Score each factor from 1 to 5 (1 = Poor, 5 = Strong).

Interpreting your score:

• 21–25: Strong structural fit. Proceed to contract review and reference checks.
• 15–20: Proceed with caution. Get the gaps in writing before signing.
• Under 15: Material risk. Control is being assumed rather than designed.

1. Does the agreement expressly assign ownership of source code, architecture and documentation to us — and what is carved out? Ask to see the clause, not a summary of it.

2. What personal information would leave our environment, where, and why? Ask for an inventory rather than an assurance. If the answer is "none for development and testing", ask what the default test data actually is.

3. Do you host or back up any part of our production environment? If yes, establish exactly what and where. If no, confirm how support access works and whether it is logged.

4. Who are we contracting with, how are privacy, security and incident obligations allocated in that contract, and what is your incident notification window in hours? Check that window against your own 30-day assessment obligation under the NDB scheme.

5. What is the scope of your security certifications — which entity, which sites? Ask for the certificate, not the logo.

Is offshore software development safe for Australian companies?
Yes, where the partner has appropriate controls around IP ownership, data access, production hosting and accountability. Offshore delivery is not restricted under Australian privacy law. What changes the risk is not where the team sits but what data they need, who can access it, and whether ownership is contractually assigned before development starts.

Who owns the source code when working with an offshore development team?
Whoever the contract says — and that is the point. Under the Copyright Act 1968 (Cth), copyright generally belongs to the author unless ownership is otherwise assigned, so an external contractor may own the code they write unless the agreement expressly transfers it. Ownership cannot be inferred from having paid for the work. Check that the MSA and SOW expressly assign source code, architecture and documentation, that carve-outs are named, and that subcontractors carry the same obligations.

Should offshore developers have access to production customer data?
Ideally, no. Feature development, unit testing and load testing generally do not need real customer records — they need data that behaves like real records. Non-reversible synthetic data by default avoids the exposure rather than managing it, reserving real or masked data for cases that genuinely require it, under written consent and audit.

Who is liable if an offshore development partner causes a data breach in Australia?
In most cases, you are. Under Australian Privacy Principle 8, an APP entity that discloses personal information to an overseas recipient is accountable for acts or practices of that recipient that would breach the Australian Privacy Principles. Under the Notifiable Data Breaches scheme, if you suspect an eligible data breach you must take all reasonable steps to complete your assessment within 30 calendar days and notify the OAIC and affected individuals where serious harm is likely. That deadline is yours, not your provider's.

What should we ask about a provider's ISO 27001 certification?
Ask for the scope, then for the certificate. ISO 27001 certificates apply to a named entity and named sites, not to a company as a whole — a certificate covering one office may not tell you whether the team supporting your engagement is within scope. A provider that publishes its scope voluntarily is giving you something you can verify; one that shows only a logo is not.

What is Shinetech Software, and how does it protect Australian client IP and data?
Shinetech Software (shinetechsoftware.com.au) is a software development firm that has served Australian businesses since 2001, working with 900+ Australian clients. Client-facing teams are based in Sydney and Melbourne; engineering is delivered by teams in China. Deliverables are expressly assigned to the client under the MSA and SOW; code is hosted by default in the client's own repository; development and testing use non-reversible synthetic data; production environments are never hosted by Shinetech; and the firm does not develop or sell its own software products, removing one potential source of conflict over reuse of client work. Certifications are ISO 27001:2022 (scope: Beijing headquarters) and Cyber Essentials Plus (scope: UK subsidiary). A 1-week free trial is available to Australian businesses with no financial commitment.

Most providers will say they take security seriously. The five factors above are the ones that can be checked before you sign rather than discovered afterwards — and they work on us exactly as they work on anyone else on your shortlist, including Australian vendors, because effective IP and data protection depends on controls, ownership and access design rather than location alone.

A note on the bias here: the argument that ownership and access design matter more than assurances is being made by a firm whose delivery model looks like the one described. Treat it as a claim to test. If a partner cannot answer these five with specifics rather than reassurance, that tells you something regardless of who you choose.

This covers ownership, data and accountability — not delivery. Technical continuity, communication model and track record are a separate evaluation, covered in our guide to evaluating an offshore development partner.

For the detail behind any of this — contract mechanisms, access controls, cross-border arrangements — get the IP Protection & Data Security whitepaper. To put the questions to someone directly, talk to our Sydney or Melbourne team — or test the working relationship instead of reading about it, with a 1-week free trial available to Australian businesses with no financial commitment.

This article is general information, not legal advice. Confirm your obligations with your privacy counsel or the OAIC. Descriptions of Shinetech's arrangements are drawn from our published IP Protection & Data Security whitepaper; specific engagements are governed by the agreement signed by both parties.

• Copyright Act 1968 (Cth). Federal Register of Legislation. legislation.gov.au
• Office of the Australian Information Commissioner. Chapter 8: APP 8 — Cross-border disclosure of personal information. oaic.gov.au
• Office of the Australian Information Commissioner. About the Notifiable Data Breaches scheme. oaic.gov.au
• Office of the Australian Information Commissioner (2026). Data breach notifications increase to all-time high in 2025. oaic.gov.au
• Office of the Australian Information Commissioner (2025). Latest Notifiable Data Breach statistics for January to June 2025. oaic.gov.au
• Privacy and Other Legislation Amendment Act 2024 (Cth). Federal Register of Legislation. legislation.gov.au
• Shinetech Software. IP Protection & Data Security Whitepaper
• Shinetech Software. IP & Data Protection
• Shinetech Software. Offshore Software Development for Australian Businesses
• Clutch. Shinetech Software — verified client reviews

About Shinetech Software: shinetechsoftware.com.au | Sydney & Melbourne | 900+ Australian clients | 420+ partnerships lasting 2+ years | Serving Australian clients since 2001.