Skip to main content
Forms Legal

Data Processing Agreement (Australia)

Data Processing Agreement (Australia)

This Data Processing Agreement (the “Agreement” or “DPA”) is entered into on [Effective Date] (the “Effective Date”) by and between:

[Entity Name] (ABN [Entity ABN]), with its registered or principal address at [Entity Address], [Entity City] [Entity State] [Entity Postcode], Australia (the “APP Entity”); and

[Processor Name] (ABN [Processor ABN]), with its registered or principal address at [Processor Address], [Processor City] [Processor State] [Processor Postcode], Australia (the “Processor”).

The APP Entity and the Processor are referred to collectively as the “Parties” and individually as a “Party”.

BACKGROUND

A. The APP Entity and the Processor have entered into, or are entering into, the [Main Contract Name] (the “Principal Agreement”) under which the Processor provides certain services to the APP Entity.

B. In the course of providing those services, the Processor will handle Personal Information on behalf of the APP Entity within the meaning of the Privacy Act 1988 (Cth).

C. The Parties wish to set out in this DPA the terms upon which the Processor shall handle such Personal Information, in compliance with the Privacy Act 1988 (Cth), the Australian Privacy Principles (APPs), and the Notifiable Data Breaches scheme.

NOW, THEREFORE, in consideration of the mutual obligations set out herein, and for other good and valuable consideration, the Parties agree as follows:

1. DEFINITIONS

1.1 In this Agreement, the following terms have the meanings given in the Privacy Act 1988 (Cth) and OAIC guidelines unless otherwise specified:

  • “APP Entity” means an agency or organisation that is bound by the Australian Privacy Principles under s 6C or s 6D of the Privacy Act 1988 (Cth).
  • “Australian Privacy Principles” or “APPs” means the principles set out in Schedule 1 to the Privacy Act 1988 (Cth).
  • “Personal Information” has the meaning given in s 6(1) of the Privacy Act 1988 (Cth): information or an opinion about an identified individual, or an individual who is reasonably identifiable.
  • “Sensitive Information” has the meaning given in s 6(1) of the Privacy Act 1988 (Cth), and includes health information, biometric information, information about racial or ethnic origin, criminal record, and other specified categories.
  • “Eligible Data Breach” has the meaning given in s 26WE of the Privacy Act 1988 (Cth), as amended by the Privacy Amendment (Notifiable Data Breaches) Act 2017 (Cth).
  • “OAIC” means the Office of the Australian Information Commissioner.
  • “NDB Scheme” means the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth).
  • “Principal Agreement” means the [Main Contract Name] under which the Processor provides services to the APP Entity.

2. DETAILS OF PERSONAL INFORMATION HANDLING

2.1 The Processor shall handle Personal Information on behalf of the APP Entity in accordance with the following particulars:

Purpose of handling:

[Processing Purpose]

Nature of handling activities:

[Nature of Processing]

Categories of personal information:

[Data Categories]

Categories of individuals:

[Data Subjects]

Retention period:

[Retention Period]

3. APP ENTITY’S OBLIGATIONS AND INSTRUCTIONS

3.1 The APP Entity shall ensure that it has a lawful basis for collecting and handling each category of Personal Information under the APPs (including a valid collection notice under APP 5) before instructing the Processor to handle that information.

3.2 The APP Entity shall provide the Processor with documented handling instructions. The Processor shall handle Personal Information only in accordance with those instructions, unless required to do so by Australian law or a court or tribunal order.

3.3 The APP Entity warrants that all Personal Information provided to the Processor has been collected and transferred in compliance with the Privacy Act 1988 (Cth), the APPs, and all other applicable Australian privacy legislation.

4. PROCESSOR’S OBLIGATIONS

4.1 The Processor undertakes to comply with all applicable obligations of an APP Entity or contracted service provider under the Privacy Act 1988 (Cth), including but not limited to:

  • handling Personal Information only on documented instructions from the APP Entity and only for the purposes specified in clause 2.1;
  • ensuring that persons authorised to handle Personal Information are bound by appropriate confidentiality obligations;
  • implementing security measures consistent with APP 11 to protect Personal Information from misuse, interference, loss, unauthorised access, modification, or disclosure;
  • not disclosing Personal Information to any third party without the prior written consent of the APP Entity, except where required by law;
  • assisting the APP Entity in fulfilling its obligations under the Privacy Act 1988 (Cth), including in relation to access and correction requests under APPs 12 and 13;
  • at the direction of the APP Entity, destroying or de-identifying Personal Information that is no longer required for any purpose for which it may be used or disclosed, consistent with APP 11.2;
  • making available to the APP Entity all information reasonably necessary to demonstrate compliance with this DPA and the APPs; and
  • allowing for and contributing to audits and inspections by the APP Entity or a third-party auditor appointed by the APP Entity.

5. TECHNICAL AND ORGANISATIONAL SECURITY MEASURES (APP 11)

5.1 The Processor shall implement and maintain the following technical and organisational measures to protect Personal Information, consistent with APP 11 and the OAIC’s Guide to Securing Personal Information:

[Security Measures]

5.2 The Processor shall regularly review and update these measures to ensure they remain appropriate and effective. Any material changes to security measures shall be notified to the APP Entity in writing with reasonable advance notice.

6. SUB-PROCESSORS

6.1 The Processor shall not engage any sub-contractor to handle Personal Information on behalf of the APP Entity without the prior written consent of the APP Entity.

6.2 Where the APP Entity consents to the engagement of a sub-processor, the Processor shall: (a) enter into a written contract with each sub-processor that imposes privacy obligations equivalent to those in this DPA; (b) remain fully liable to the APP Entity for the acts and omissions of any sub-processor; and (c) notify the APP Entity of any proposed changes to sub-processors to allow the APP Entity to object before such changes take effect.

7. NOTIFIABLE DATA BREACHES (PRIVACY ACT 1988 (CTH) PART IIIC)

7.1 The Processor shall notify the APP Entity without undue delay, and in any event within [Breach Notification Period] of becoming aware of an actual or suspected Eligible Data Breach affecting any Personal Information handled under this Agreement.

7.2 Such notification shall include, to the extent available at the time of notification: (a) a description of the nature of the breach; (b) the categories and approximate number of individuals affected; (c) the categories of Personal Information involved; (d) the likely consequences; and (e) the measures taken or proposed to address the breach.

7.3 The Processor acknowledges that the APP Entity may be required to notify the OAIC and affected individuals of an Eligible Data Breach under s 26WK of the Privacy Act 1988 (Cth), and shall cooperate fully with the APP Entity in meeting this obligation.

7.4 The Processor shall not make any public statement or notification to any individual in respect of an Eligible Data Breach without the prior written consent of the APP Entity, except where required by law.

8. ACCESS AND CORRECTION REQUESTS (APPs 12 AND 13)

8.1 The Processor shall promptly notify the APP Entity of any requests received directly from individuals seeking access to or correction of their Personal Information under APPs 12 and 13, and shall not respond to such requests without the APP Entity’s prior written authorisation, except to acknowledge receipt.

8.2 The Processor shall provide reasonable assistance to the APP Entity in responding to access and correction requests within the time limits required by the Privacy Act 1988 (Cth), at the APP Entity’s reasonable cost.

9. DESTRUCTION AND DE-IDENTIFICATION OF PERSONAL INFORMATION (APP 11.2)

9.1 Upon termination or expiry of this Agreement or the Principal Agreement (or upon the APP Entity’s earlier written request), the Processor shall, at the APP Entity’s election: (a) securely return all Personal Information (and any copies) to the APP Entity in a structured, commonly used, and machine-readable format; or (b) securely destroy or de-identify all Personal Information and any copies, and provide written certification of such destruction or de-identification within [Retention Period] of the relevant event.

9.2 The Processor may retain Personal Information beyond this period solely to the extent required by applicable Australian law or a regulatory obligation, and shall notify the APP Entity of any such retention, the legal basis for it, and the data concerned.

10. AUDIT AND INSPECTION RIGHTS

10.1 The Processor shall, on reasonable written notice, allow the APP Entity (or its appointed third-party auditor) to audit the Processor’s personal information handling activities, systems, and facilities insofar as they relate to the Personal Information handled under this Agreement.

10.2 The Processor shall provide the APP Entity with all information reasonably necessary to demonstrate compliance with the APPs and this DPA. Where the Processor holds relevant certifications (such as ISO 27001) or third-party audit reports, it may provide these in lieu of a direct audit, subject to the APP Entity’s agreement.

11. LIABILITY AND INDEMNITY

11.1 Each Party’s liability to the other under or in connection with this DPA shall be subject to the limitations and exclusions set out in the Principal Agreement, to the extent permitted by applicable law.

11.2 Each Party shall indemnify and hold harmless the other Party in respect of any third-party claims, fines, penalties, determinations by the OAIC, or compensation claims from individuals arising from or in connection with that Party’s breach of its obligations under this DPA or applicable Australian privacy law.

11.3 Nothing in this DPA limits or excludes either Party’s liability for fraud, fraudulent misrepresentation, or any other liability that cannot be excluded or limited by law.

12. GENERAL PROVISIONS

12.1 Precedence. In the event of any conflict between this DPA and the Principal Agreement in relation to the handling of Personal Information, this DPA shall prevail.

12.2 Amendments. This DPA may not be amended except by a written instrument signed by an authorised representative of each Party.

12.3 Severability. If any provision of this DPA is held invalid or unenforceable, the remaining provisions shall continue in full force and effect.

12.4 Entire Agreement. This DPA constitutes the entire agreement between the Parties with respect to the handling of Personal Information under the Principal Agreement and supersedes all prior representations on that subject matter.

12.5 Governing Law. This DPA is governed by the laws of [Entity State], Australia, and the Parties submit to the non-exclusive jurisdiction of the courts of that state or territory and the Federal Court of Australia.

IN WITNESS WHEREOF, the Parties have executed this Data Processing Agreement as of the Effective Date first written above.

THE APP ENTITY

Name: [Entity Name]

ABN: [Entity ABN]

Address: [Entity Address], [Entity City] [Entity State] [Entity Postcode]

THE PROCESSOR

Name: [Processor Name]

ABN: [Processor ABN]

Address: [Processor Address], [Processor City] [Processor State] [Processor Postcode]

APP Entity

________________

Signature

Date: ________________

Processor

________________

Signature

Date: ________________

Maintained by Vladislav Sergienko, Founder·Template last modified: ·Report an error

What Is a Data Processing Agreement (Australia)?

A Data Processing Agreement in Australia records the personal-data processing to be provided, the fees, the service standards, and each party's obligations between the provider and the client under the Corporations Act 2001 (Cth).

Australia does not have a regulation equivalent to EU GDPR Article 28 mandating a written DPA. However, Australian Privacy Principle 11 requires APP entities to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access or disclosure. The OAIC's Guide to Securing Personal Information identifies contractual arrangements with third-party service providers — including cloud platforms, payroll processors, HR systems, and IT support companies — as a key reasonable step that APP entities must take. An APP entity that fails to contractually bind its service provider to appropriate privacy standards cannot demonstrate compliance with APP 11 and may be held liable for a breach by the service provider.

The Notifiable Data Breaches (NDB) scheme in Part IIIC of the Privacy Act 1988 (Cth), introduced by the Privacy Amendment (Notifiable Data Breaches) Act 2017 (Cth), creates a strong practical driver for written DPAs. Under s 26WA(2), personal information held by a service provider on behalf of an APP entity is deemed to be held by the APP entity. Where the service provider suffers a data breach, the APP entity bears the NDB notification obligation to the OAIC and affected individuals under ss 26WK and 26WL. A DPA that requires the Processor to notify the APP entity within a specified short timeframe — shorter than the OAIC's 'as soon as practicable' standard — gives the APP entity the window needed to assess the breach and meet its own notification obligations.

Cross-border disclosure is addressed by Australian Privacy Principle 8. Before disclosing personal information to an overseas recipient, an APP entity must take reasonable steps under APP 8.1 to requires the overseas recipient handles the information consistently with the APPs. Many Australian businesses use US-based SaaS platforms (such as Salesforce, HubSpot, AWS, Azure, and Google Cloud) that host personal information outside Australia. Without contractual protections binding these offshore processors to APP-equivalent standards, the APP entity risks breaching APP 8.1 and being held accountable for the overseas provider's mishandling of Australian individuals' personal information. A DPA addresses this gap directly.

APRA-regulated entities — banks, insurers, and superannuation funds regulated by the Australian Prudential Regulation Authority — must also comply with Prudential Standard CPS 234 Information Security, which requires documented security requirements for third-party service providers and the ability to audit their information security practices. For Commonwealth government agencies, the Australian Government Information Security Manual (ISM) published by the Australian Signals Directorate (ASD) and the Protective Security Policy Framework (PSPF) administered by the Attorney-General's Department impose equivalent contractual obligations on government data processors. State and territory privacy legislation — including the Privacy and Personal Information Protection Act 1998 (NSW), the Privacy and Data Protection Act 2014 (Vic), and the Information Privacy Act 2009 (Qld) — may also impose DPA-equivalent requirements on state government agencies and their contractors. Forms-legal.com provides this template as a starting point for Privacy Act 1988-compliant data processing arrangements.

When Do You Need a Data Processing Agreement (Australia)?

An Australian Data Processing Agreement should be executed before any service provider is given access to personal information held by an APP entity. The agreement is most immediately required in a number of situations that arise regularly for Australian businesses.

Cloud and SaaS platforms: Any Australian business that uses cloud-based software storing personal information — including customer data in a CRM (Salesforce, HubSpot), employee data in an HR system (Workday, Employment Hero), financial data in accounting software (Xero, MYOB), or communications data in a productivity platform (Microsoft 365, Google Workspace) — should have a DPA in place with the relevant vendor. Many major cloud providers offer standard DPA terms that must be reviewed against APP requirements.

Payroll and HR processing: Payroll bureaus and HR outsourcing providers handle some of the most sensitive employee personal information — including tax file numbers (TFNs) under the Tax File Number Guidelines 2011 issued under the Privacy Act 1988 (Cth), bank account details, superannuation fund information, and health information related to leave. The ATO's TFN guidelines impose strict restrictions on who may handle TFNs and for what purposes; a DPA must address TFN handling specifically.

IT support and managed services: IT support providers, managed security services providers, and help desk operators routinely access systems that hold personal information about customers and employees. Their access creates privacy risk that must be contractually managed through a DPA requiring APP 11-equivalent security controls, access restrictions, and breach notification obligations.

Overseas service providers: Where the service provider is based outside Australia — including in the US, UK, India, Philippines, or elsewhere — APP 8.1 requires the APP entity to requires the overseas provider handles information consistently with the APPs. A DPA that imposes APP-equivalent obligations on the overseas provider is the primary mechanism for satisfying APP 8.1. Without it, the APP entity is accountable for the overseas provider's privacy failures under APP 8.1.

Healthcare and sensitive data: Health service providers, clinical research organisations, and aged care providers that engage third-party processors to handle health information — which is sensitive information under s 6(1) of the Privacy Act 1988 (Cth) — must require that processing arrangements comply with APP 3 (collection), APP 6 (use and disclosure), and APP 11 (security). A DPA tailored to health information processing should address the specific requirements of the Australian Privacy Principles relevant to sensitive data.

What to Include in Your Data Processing Agreement (Australia)

A legally sound Australian Data Processing Agreement should include the following elements to satisfy APP 11, APP 8, the NDB scheme, and the OAIC's guidance on third-party data processing arrangements.

Party identification: Full legal names and ABNs of the APP entity and the Processor. For overseas Processors, the agreement should record the Processor's country of establishment and principal place of business.

Description of processing: A detailed schedule describing the categories of personal information to be processed, the categories of data subjects, the purposes of processing, and the duration of the processing arrangement. Sensitive information (health, biometric, racial, or other categories under s 6(1) of the Privacy Act 1988 (Cth)) must be specifically identified and subject to enhanced obligations.

Handling instructions: The APP entity's written instructions to the Processor regarding how personal information is to be handled, and a prohibition on the Processor using the information for its own purposes outside the scope of the instructions.

APP 11 security measures: Specific technical and organisational security measures the Processor must implement, consistent with the OAIC's Guide to Securing Personal Information — including encryption in transit and at rest, access controls, multi-factor authentication, vulnerability management, and incident response procedures.

Sub-processor controls: The APP entity's prior approval requirement for sub-processors, the obligation to flow down DPA obligations to approved sub-processors, and notification requirements when sub-processors change.

APP 8 cross-border disclosure safeguards: Restrictions on the Processor disclosing or transferring personal information to overseas sub-processors without the APP entity's prior written consent and confirmation that APP-equivalent protections are in place.

NDB scheme breach notification: The Processor's obligation to notify the APP entity within a specified short timeframe (typically 24–48 hours) of becoming aware of an actual or suspected eligible data breach, including prescribed information about the breach to enable the APP entity to conduct its NDB assessment under s 26WH of the Privacy Act 1988 (Cth).

Access and correction assistance: The Processor's obligation to assist the APP entity in responding to individuals' access and correction requests under APPs 12 and 13 within the timeframes required by the Privacy Act 1988 (Cth).

Data destruction and de-identification: The Processor's obligation to destroy or de-identify all personal information held on behalf of the APP entity upon termination, consistent with APP 11.2, and to provide written certification of completion.

Audit rights: The APP entity's right to audit or assess the Processor's compliance with the DPA, either directly or through an independent auditor accredited under ISO/IEC 27001:2022, at reasonable notice. Evidence of audit findings must be retained by the Processor for at least three years.

Tax file number handling: Where the Processor will handle employee or customer Tax File Numbers (TFNs) on behalf of the APP entity, the DPA must address compliance with the Tax File Number Guidelines 2011 made under s 17 of the Privacy Act 1988 (Cth), including restrictions on the collection, storage, and disclosure of TFNs beyond the authorised tax-related purposes.

State and territory privacy laws: Where the APP entity is a state government agency subject to state privacy legislation — including the Privacy and Personal Information Protection Act 1998 (NSW), the Privacy and Data Protection Act 2014 (Vic), or the Information Privacy Act 2009 (Qld) — the DPA should specify compliance with those Acts in addition to the Commonwealth Privacy Act 1988 (Cth).

Governing law and dispute resolution: Australian law (specifying the governing state or territory) and jurisdiction before the Federal Court of Australia or the relevant state Supreme Court for disputes. The OAIC has jurisdiction to investigate and conciliate privacy complaints under Part V of the Privacy Act 1988 (Cth). Forms-legal.com provides this template as a starting point for Australian data processing governance documentation.

Sources & Citations

Statutory citations link to official government sources.

  1. GDPR Article 28EU – GDPR

Cite this page

Reference this free template in an article, syllabus, or research note:

APA

Forms Legal. (2026). Data Processing Agreement (Australia) (Australia) [Legal document template]. Forms Legal. https://forms-legal.com/australia/business/policies/data-processing-agreement-australia

MLA

"Data Processing Agreement (Australia) (Australia)." Forms Legal, 2026, https://forms-legal.com/australia/business/policies/data-processing-agreement-australia.

BibTeX
@misc{formslegal-data-processing-agreement-australia,
  author       = {{Forms Legal}},
  title        = {Data Processing Agreement (Australia) (Australia)},
  year         = {2026},
  howpublished = {\url{https://forms-legal.com/australia/business/policies/data-processing-agreement-australia}},
  note         = {Free legal document template. Based on Corporations Act 2001 (Cth)}
}

Also available for these jurisdictions:

United StatesUnited StatesCanadaCanadaUnited KingdomUnited KingdomNew ZealandNew ZealandGhanaGhanaHong KongHong KongIrelandIrelandIndiaIndia

Frequently Asked Questions

Based on Corporations Act 2001 (Cth) — Template last modified June 2026Verify the source →

This template is provided for informational purposes only and does not constitute legal advice. Laws vary by jurisdiction and change over time. Consult a qualified attorney for advice specific to your situation.Full disclaimer

Found an error? Let us know

Related Documents

You may also find these documents useful:

Privacy Policy (Australia)

Create a compliant Australian Privacy Policy for your business or website. Our template is drafted in accordance with the Privacy Act 1988 (Cth) and covers all 13 Australian Privacy Principles (APPs), including APP 1 (open management), APP 5 (notification), APP 6 (use and disclosure), APP 7 (direct marketing), APP 8 (cross-border disclosure), APP 11 (security), APP 12 (access), and APP 13 (correction). Includes the Notifiable Data Breaches scheme, OAIC complaint process, and the $3 million turnover threshold explanation.

SaaS Agreement (Australia)

A Software as a Service (SaaS) agreement is the foundation of every cloud-based software subscription business. Whether you are an Australian startup offering your first B2B platform or an established provider expanding your customer base, having a professionally drafted SaaS agreement is essential to protect your intellectual property, manage your liability, ensure privacy law compliance, and set clear expectations with customers about service levels, payment, and data handling. An Australian SaaS Agreement differs in important respects from equivalent agreements used in the United Kingdom or the United States. Australian law imposes obligations that cannot be contracted out of, particularly under the Australian Consumer Law (ACL), the Privacy Act 1988 (Cth), and the Spam Act 2003 (Cth). A SaaS agreement that simply adopts a US or UK template without adapting it for the Australian legal environment may be unenforceable in key respects and may expose the provider to regulatory risk. The Australian Consumer Law (ACL), being Schedule 2 to the Competition and Consumer Act 2010 (Cth), is one of the most significant considerations for SaaS providers. Sections 23 to 28 of the ACL prohibit unfair contract terms in standard form contracts with consumers and, since November 2023, with small businesses. A term in a SaaS agreement is unfair if it would cause a significant imbalance in the parties' rights and obligations arising under the contract, is not reasonably necessary to protect the legitimate interests of the party advantaged by the term, and would cause detriment to a party if it were relied on. Commonly challenged terms include broad indemnities, unilateral variation rights, and automatic renewal clauses with short cancellation windows. Under the Treasury Laws Amendment (More Competition, Better Prices) Act 2022 (Cth), unfair terms in standard form contracts are now void and attract significant civil penalties. The Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs) govern how personal information is collected, used, disclosed, and secured by APP entities. A SaaS provider who collects personal information from customers or who processes personal information on behalf of customers must comply with the APPs. Of particular importance are APP 1 (open and transparent management of personal information), APP 3 (collection of personal information), APP 6 (use or disclosure of personal information), APP 8 (cross-border disclosure of personal information), APP 11 (security of personal information), and APPs 12 and 13 (access to and correction of personal information). The agreement should address who owns customer data, how the provider will secure it consistent with APP 11, and what happens to the data on termination. The Spam Act 2003 (Cth) prohibits the sending of unsolicited commercial electronic messages to Australian accounts. SaaS providers who send marketing emails or in-app notifications to customers must have explicit or inferred consent and must include a functioning unsubscribe mechanism. The agreement should confirm that the provider will comply with the Spam Act 2003 in relation to any electronic communications sent in connection with the service. Australia does not have an equivalent of the EU GDPR's data processing agreement regime. However, where a SaaS provider processes personal information on behalf of a customer, it is best practice to include equivalent contractual protections addressing handling instructions, security obligations, sub-processor disclosure, breach notification, and data return or deletion on termination. Service level agreements (SLAs) specifying uptime commitments are a standard feature of SaaS agreements. A meaningful SLA will specify the uptime percentage, how downtime is measured, what events are excluded (such as scheduled maintenance and factors beyond the provider's control), and what remedy is available to the customer for a breach of the SLA. A service credit regime — where the customer receives a credit against future invoices for periods of downtime exceeding the SLA threshold — is the most common remedy. Subscription pricing in AUD, GST provisions complying with the A New Tax System (Goods and Services Tax) Act 1999 (Cth), auto-renewal with appropriate notice periods, and the right to increase fees on renewal are all standard commercial terms in Australian SaaS agreements. The agreement should also address what happens to customer data on termination, including a grace period for data export before deletion. This Australian SaaS Agreement template addresses all key commercial and legal issues: ACL compliance including unfair contract terms considerations, Privacy Act 1988 (Cth) and APP obligations, Spam Act 2003 compliance, customer data ownership and security, SLA uptime commitments, AUD subscription pricing with GST, auto-renewal and cancellation, IP protection, limitation of liability, confidentiality, and governing law.

Service Agreement (Australia)

Create a comprehensive Australian Service Agreement compliant with the Australian Consumer Law (Schedule 2 of the Competition and Consumer Act 2010 (Cth)) and the common law of contract. Covers scope of services, GST-inclusive or exclusive fees, payment terms, consumer guarantees, intellectual property ownership, confidentiality, Privacy Act 1988 obligations, limitation of liability, and termination rights. Suitable for consultants, freelancers, agencies, and businesses providing services to other businesses or consumers across all Australian states and territories.

Software Development Agreement (Australia)

Commissioning bespoke software is one of the most significant investments a business can make, and getting the legal foundations right from the outset is essential. An Australian Software Development Agreement is a bespoke contract between a client and a developer that governs the creation of custom software — whether a web application, mobile app, enterprise platform, or integrated system. This agreement sets out each party's rights and obligations in legally precise terms, reducing the risk of disputes over intellectual property, payment, scope creep, and delivery timelines. In Australia, the starting point for intellectual property in software is the Copyright Act 1968 (Cth). Section 35(6) of that Act provides that where a work is made by an independent contractor (rather than an employee), copyright is owned by the contractor — not the client — unless there is a written agreement to the contrary. This default rule surprises many clients who assume they automatically own what they have paid to have built. A well-drafted software development agreement expressly addresses copyright ownership and, where the parties intend for the client to own the finished software, includes a valid assignment of copyright pursuant to s 196 of the Copyright Act 1968 (Cth). Without such a written assignment, the client receives only whatever licence the developer is willing to grant. Patentable inventions arising from software development are governed by the Patents Act 1990 (Cth). Where the software may give rise to a novel technical process or system that could be patentable, the agreement should address how any patent rights will be owned and licensed, either by express assignment or by a commitment to negotiate in good faith. The Australian Consumer Law (ACL), being Schedule 2 to the Competition and Consumer Act 2010 (Cth), imposes consumer guarantees on the supply of services in trade or commerce. A developer supplying software development services to a consumer or small business cannot exclude guarantees that the services will be rendered with due care and skill and that the result will be fit for the disclosed purpose. A professionally drafted agreement acknowledges these non-excludable rights and structures any additional limitation of liability around them. Payment disputes are one of the most common causes of conflict in software projects. An effective payment structure ties payments to defined milestones — for example, 30% on signing, 40% on design approval, and 30% on final acceptance — so that the developer is incentivised to deliver and the client does not pre-pay for work that may not be completed. The agreement should also address the developer's right to suspend work for non-payment and to charge interest on overdue amounts. Scope creep — where the client requests additional features or changes beyond what was originally agreed — is another major source of disputes. The agreement should specify that changes to scope require a written change order signed by both parties and may attract additional fees. This protects the developer from being expected to deliver a materially different product for the same fixed price. Confidentiality is critically important in software development engagements. Clients frequently share proprietary business logic, trade secrets, and sensitive commercial data to enable the developer to build the system. The agreement should impose reciprocal confidentiality obligations on both parties and should specify that these obligations survive termination. Where the software will collect, store, or process personal information about individuals, the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs) will apply. Australian Privacy Principle 11 requires APP entities to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access. The software development agreement should address how the developer will handle any personal information encountered during the project and should require the developer to implement appropriate security measures. User acceptance testing (UAT) and a formal acceptance process protect both parties by providing a defined mechanism for the client to review the software against the agreed specification before final payment is released. Without a clear acceptance process, disputes commonly arise about whether the software meets requirements. This Australian Software Development Agreement template covers all key aspects: copyright assignment under the Copyright Act 1968 (Cth), patent provisions under the Patents Act 1990 (Cth), ACL consumer guarantee acknowledgment, milestone-based payment, scope change control, background IP protection, user acceptance testing, confidentiality, privacy compliance, limitation of liability, and termination rights. It uses Australian business terminology (Pty Ltd, ABN, AUD, DD/MM/YYYY) and is governed by the laws of the relevant Australian state or territory.

Non-Disclosure Agreement (NDA) (Australia)

Protect your confidential business information under Australian common law with a legally sound Non-Disclosure Agreement (NDA). Whether you are sharing trade secrets with a prospective partner, disclosing proprietary technology to a developer, or presenting financial projections to a potential investor, a properly drafted Australian NDA keeps your sensitive information under strict legal protection. Our template complies with Australian contract law principles and includes provisions addressing the Privacy Act 1988 (Cth) and the Australian Privacy Principles.