Data Processing Agreement

1.1 This DPA forms part of the Agreement and governs Savira's handling of personal information on the Customer's behalf in delivering the Services selected in Schedule 1. It continues while Savira or its Subprocessors hold Protected Data, including after the Services end.

1.2 Protected Data means personal information Savira processes on the Customer's behalf, including identifiable or reasonably identifiable consent records, website activity, support material, logs and approved health information. Personal information, sensitive information and health information have their meanings under the Privacy Act 1988 (Cth). Pseudonymised information remains Protected Data where an individual is reasonably identifiable.

1.3 Data Protection Laws means privacy, health information, security and breach notification laws applicable to a party's processing under the Agreement, including the Privacy Act 1988 (Cth), the Australian Privacy Principles (APPs), applicable registered APP codes and, where applicable, the NSW Health Records and Information Privacy Act 2002, Victorian Health Records Act 2001 and ACT Health Records (Privacy and Access) Act 1997, as amended.

1.4 Processing means collecting, recording, using, holding, accessing, disclosing, transferring, returning, de-identifying or destroying information. A Subprocessor is a separate person or entity engaged by Savira to process Protected Data, including a contractor with access to it. A Data Breach is accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Protected Data.

2.1 Each party must comply with Data Protection Laws applicable to it and the contractual protections in this DPA. Processing on behalf of the Customer does not exempt Savira from legal duties that apply directly to it. The contractual allocation of responsibilities does not displace either party's obligations under Australian law.

2.2 The Customer determines its purposes for using the Services and gives documented instructions through the Agreement, the schedules, authorised settings and written requests from its nominated representatives. If the Customer acts for another organisation, it must have authority to give those instructions and identify the relevant organisation in the Service Order.

2.3 Savira may process Protected Data only to provide, maintain, secure and support the agreed Services under those instructions, or where legally required. Before legally required processing, Savira must notify the Customer of the requirement unless prohibited by law. Savira must promptly flag an instruction it reasonably believes is unlawful and may suspend only the affected processing while the parties resolve it.

2.4 The Customer is responsible for lawful collection and instructions, appropriate notices, consents where required or an applicable legal exception, accurate configuration and authorised users. The Customer must not submit unnecessary information or unapproved sensitive information. Savira remains responsible for its own acts, omissions and obligations under this DPA.

2.5 Savira must not sell Protected Data, use it for its own advertising, build unrelated profiles, or use it to train general-purpose or third-party AI models. Sending Protected Data to an AI service is prohibited unless the parties separately approve a specific lawful use, provider, location and safeguards in writing. A generic product-improvement or support permission is insufficient.

2.6 Savira may use genuinely de-identified statistics to operate and improve the Services only where individuals are not reasonably identifiable, including by combination with other reasonably available information. Savira must not attempt re-identification or disclose identifiable Customer information through those statistics.

2.7 Business contact and billing information used by Savira for its own account administration is handled under applicable law and Savira's privacy policy. That treatment does not extend to Customer end-user records, health-related support content or identifiable service logs, which remain protected by this DPA. Savira's privacy policy cannot expand permitted use of Protected Data.

2.8 The DPA does not add unpurchased functionality or guarantee that a consent record proves valid consent, that a scanner detects every tracker, or that a banner controls every Customer system. Savira must perform its agreed obligations with due care and skill. The Customer must verify its notices, purposes, integrations and downstream behaviour, including after material website changes.

2.9 Third-party systems selected and controlled by the Customer are not Savira Subprocessors merely because an integration is used. The Customer must authorise any data flow to them and assess their terms. Savira must follow the approved configuration and remains responsible for its own transmission and integration conduct. Savira cannot classify a provider it engages for its own delivery as Customer-controlled to avoid clause 4.

3.1 Savira must implement and maintain technical and organisational measures appropriate to the nature and sensitivity of Protected Data, the likely harm, the processing and reasonably foreseeable risks, including the binding minimum requirements in Schedule 2. Measures must protect against misuse, interference, loss and unauthorised access, modification or disclosure.

3.2 Access is restricted to personnel with a legitimate need for the agreed purpose, using least privilege. Savira must ensure personnel are bound by enforceable confidentiality duties, receive relevant privacy and security training, and have access removed promptly when no longer needed. Contractors and employees are identified separately in Schedule 4.

3.3 Savira must assess its measures regularly, address identified material vulnerabilities within risk-based timeframes, and maintain incident response and recovery procedures. Changes must not materially reduce the overall protection or breach an express control. Material changes affecting Customer risk must be communicated promptly.

3.4 No certification, Australian-only access, uptime, recovery time or particular technology is represented unless expressly recorded in the Agreement or Schedule 2. Operational details in Schedule 2 must be accurate. A pending control is not an implemented control and does not waive the minimum requirements.

4.1 The Customer gives general authorisation for only the Subprocessors and processing recorded in Schedule 4. Savira must conduct proportionate due diligence and enter a written agreement imposing materially equivalent confidentiality, security, permitted-use, incident reporting, assistance, retention and transfer protections before access begins.

4.2 Savira remains responsible to the Customer for its Subprocessors' processing acts and omissions as if they were Savira's own, subject to clause 10. The same controls must flow to any further Subprocessor. The register must include further recipients that materially affect data locations or access, not only the first vendor in a chain.

4.3 Savira must give at least 30 calendar days' advance written notice before adding or replacing a Subprocessor or materially expanding its purpose, data access or country. The notice must give the provider, purpose, data and location details shown in Schedule 4. The Customer may object within that period on reasonable data protection grounds.

4.4 The parties must seek a reasonable alternative or mitigation. Savira must not introduce the contested processing of that Customer's data until the objection is resolved. If no reasonable solution is agreed within 30 calendar days after the objection, either party may terminate the affected Services without an early termination charge. Savira must refund unused prepaid fees for those Services and assist export under clause 8.

4.5 An urgent substitution necessary to contain an incident or prevent material service interruption may occur without advance notice only where equivalent safeguards are maintained and it does not add an unapproved country or health-data purpose. Savira must notify the Customer as soon as practicable, explain the urgency and permit objection and the remedies in clause 4.4. This exception does not authorise otherwise unlawful processing.

5.1 Savira hosts Protected Data on AWS infrastructure in Australia. Storage, backups, processing and personnel access, including support access, must remain within Australia.

5.2 Schedule 4 identifies the approved service providers, systems and Australian storage and access locations.

5.3 Savira must not introduce storage, processing or access outside Australia without the Customer's prior written approval and compliance with applicable Data Protection Laws. Changes to service providers remain subject to clause 4 and, for health information, Schedule 3.

6.1 Savira must promptly forward a request or complaint concerning Protected Data to the Customer's privacy contact, ordinarily within two business days. Savira must not substantively respond on the Customer's behalf without instructions, except where legally required. It must verify requester authority before disclosure and notify the Customer of legally required action unless prohibited.

6.2 Savira must provide reasonable assistance to locate, export, correct, restrict or delete relevant records and address complaints, privacy impact assessments and regulator inquiries. It must begin responding to Customer assistance requests within five business days, and sooner where the Customer identifies an imminent legal deadline or risk of harm. The parties must agree a workable completion time that permits compliance with applicable deadlines.

6.3 Consent withdrawal and data deletion are separate instructions. Savira must implement approved changes to consent records and transmission settings without undue delay within the agreed service capability. Minimal withdrawal, suppression or historical evidence may be retained only for a documented lawful purpose and defined period. A withdrawal does not validate earlier collection or require unlawful destruction of records.

6.4 Routine assistance using existing tools, initial incident cooperation and work required to remedy Savira's breach are included. For substantial additional work unrelated to Savira's breach, Savira may charge reasonable fees only after giving a scope and estimate and obtaining written approval. A fee dispute must not delay required security action or legally required cooperation.

7.1 Savira must notify the Customer without undue delay and no later than the end of the second Business Day after becoming aware of a Data Breach, or reasonable grounds to suspect a Data Breach affecting Protected Data. Business Day means Monday to Friday, excluding public holidays in Sydney, NSW; the deadline is 5 pm Sydney time on the second Business Day following the day of awareness. Savira must give earlier notice where reasonably necessary to enable compliance with Data Protection Laws or urgent action to prevent or mitigate serious harm, including outside business days. Notice must use the nominated incident contact, with reasonable escalation if receipt is not confirmed. Initial notice must not await a completed investigation, serious-harm assessment or all facts.

7.2 As information becomes available, notices must describe the incident and discovery times, nature of affected information, known or estimated individuals/records affected, likely consequences, locations or recipients involved, containment measures, recommended Customer action and the incident lead. Initial unknowns must be identified and followed by material updates without undue delay. Savira must preserve relevant evidence and provide a written findings and remediation summary when available.

7.3 Savira must promptly contain and investigate the incident, mitigate harm, maintain an incident record and cooperate with the Customer's assessment and response. Each party must carry out assessments and notifications required of it by law. Where the NDB scheme applies, the parties must support a reasonable and expeditious assessment and all reasonable steps to complete it within 30 calendar days after the relevant statutory suspicion arises.

7.4 The parties must consult promptly on notifications to the OAIC, affected individuals and other required recipients, agree a lead where lawful, and avoid inconsistent or unnecessary duplicate notices. The Customer should lead communications with its patients and clients where reasonably practicable. Neither party may prevent or delay the other from giving a legally required notification. If consultation is impracticable within the legal timeframe, the notifying party must inform the other as soon as lawful and practicable.

7.5 The two-Business-Day limit is a contractual maximum for initial notice to the Customer, not a statutory deadline or permission to delay notice that can reasonably be given sooner. It does not postpone containment, assessment or any legally required notification. Where the Privacy Act requires notification of an eligible data breach, the statutory timing requirements, including notification as soon as practicable, apply despite weekends or public holidays. Notice or cooperation does not itself admit liability or excuse either party's duties.

7A.1 On reasonable request, Savira must provide information reasonably necessary to demonstrate compliance, including relevant control descriptions, the access register, retention arrangements and available independent reports. Confidentiality and redaction may protect other customers and security-sensitive detail, but must not make the evidence ineffective. Savira must not claim unavailable certifications.

7A.2 If that information is reasonably insufficient, the Customer may arrange a proportionate audit by an independent qualified auditor bound by confidentiality and not a direct competitor. Ordinarily this is limited to one audit per year, on 20 business days' notice during business hours, with scope limited to relevant processing and disruption minimised. Additional audits or shorter notice are allowed where reasonably necessary after a material incident, suspected material non-compliance or a regulator requirement.

7A.3 The Customer bears its auditor's costs, unless the audit establishes a material Savira breach, in which case Savira bears reasonable audit costs attributable to that breach. Savira's additional assistance charges require prior written agreement. Audit procedures must not obstruct statutory regulator powers, legally required audits or timely incident investigation. Material findings require a documented remediation plan and reasonable timeframes.

8.1 The retention table in Schedule 4 governs each data class during and after the Services. Savira must not retain Protected Data merely because storage is available. The Customer must identify applicable record-keeping duties; Savira must not assume that a clinical-record retention period automatically applies to every consent log or technical record.

8.2 Before deletion on termination, Savira must provide a reasonable opportunity to export Protected Data in the agreed usable machine-readable format, including relevant metadata and evidence within the agreed scope. The export window and active-system deletion deadline are set out in Schedule 4. If none is stated, Savira must give at least 30 calendar days' written warning and export opportunity before termination-related deletion, and complete active-system deletion within 30 calendar days after that window ends, unless law requires different treatment.

8.3 Residual backup copies must remain isolated, access-restricted and protected until the maximum expiry period in Schedule 4. If a backup is restored for recovery, previously deleted data must be deleted again before ordinary processing resumes. No indefinite backup exception applies. On request, Savira must confirm completion of active deletion and the date by which residual copies will expire.

8.4 Where retention is legally required, Savira must identify the legal basis, affected classes and period to the Customer unless prohibited. Retained data must be segregated or restricted, used only for the required purpose and deleted when the obligation ends. Billing or tax obligations do not by themselves justify keeping patient content. A requested lawful preservation hold must be documented and reviewed.

9.1 Material amendments to this DPA or its approved scope must be agreed in writing, except register changes expressly permitted by clause 4. A website update does not itself amend this DPA. Each party must inform the other of a material legal or processing change relevant to the agreed Services and cooperate on necessary adjustments.

9.2 A party may suspend only processing reasonably necessary to prevent unlawful handling or material harm, notify the other promptly and seek restoration. If a material DPA breach is not remedied within 30 calendar days after notice, or is incapable of remedy, the other party may terminate affected Services. Imminent material harm permits immediate affected suspension. Export and protection duties continue; other termination rights under the Agreement are preserved.

10.1 For data protection conflicts, Schedule 3 prevails over the core DPA, the core DPA prevails over other schedules, and this DPA prevails over the Service Order and Terms of Service. An express bilateral amendment identifying the provision varied may override it, subject to applicable law. A mandatory executed transfer instrument prevails where that instrument requires.

10.2 The Agreement's expressly agreed liability limitations, exclusions and claims procedures apply to contractual DPA claims, including Subprocessor acts, without duplicate recovery. This DPA creates no additional indemnity. Nothing excludes non-excludable liability, limits an individual's or regulator's statutory rights, or releases a party from its own statutory duties. A commercial cap does not cap a regulator's powers or penalties.

10.3 NSW law governs this DPA and the parties submit to NSW courts, subject to mandatory law. If a provision is unenforceable, the remainder continues. This DPA is accepted when the Customer accepts the Terms of Service, or by a signed Service Order that identifies this DPA version. It may be signed electronically and in counterparts by authorised representatives. Health authorisation must be express.

H1 Health information includes information within the statutory definition, and information about an identifiable or reasonably identifiable person's health, disability or receipt of a health service. Depending on context, an appointment reference, practice relationship, condition-specific page visit, URL, consent choice or linked identifier may reveal health information even without clinical notes. Such records must not be treated as ordinary analytics merely because they are technical data.

H2 The Customer authorises only the health-data categories, purposes and systems specified in the health authorisation form. Savira must limit processing to what is reasonably necessary for that scope. This permission is not the patient's consent, an authority to practise a health profession, or permission to process all patient records. Each party remains responsible for its applicable laws, including relevant state or territory health information requirements.

H3 The Customer must assess the lawful basis for collection, use and disclosure, including consent or an applicable exception, appropriate patient notices, children/capacity and representative authority. Consent to treatment does not automatically authorise advertising or tracker disclosures. Savira must provide reasonably required information about its data flows so the Customer can make that assessment. No consent banner or recorded preference overrides applicable law.

H4 The parties must agree and test a minimal data map before activation. Savira must avoid health content in URLs, query parameters, event labels, logs, support tickets and third-party telemetry wherever practicable. Use redacted or synthetic information for support first. Access to identifiable content must be justified, approved under the documented procedure, limited in scope and logged. Copies must be removed under the approved retention schedule.

H5 Savira must not send health information or health-revealing identifiers to advertising, audience-matching, profiling, session-replay or unrelated analytics services. A Customer instruction to do so requires a separately signed amendment identifying the lawful basis, purpose, recipient and safeguards before any such activity. This schedule does not itself authorise such a flow or override clause 2.5.

H6 Savira must restrict health information to expressly approved systems and access locations in Schedule 4. Health-data access by a separate contractor requires the precise legal entity and registration identifier, personnel relationship, country, systems, purpose and data scope. A label such as "approved provider" is insufficient. Savira must apply clause 4 to proposed changes and must not add an overseas country for health-data access without the Customer's express written approval. Transfers outside a state or territory must also satisfy applicable health privacy transfer rules, even where the recipient remains in Australia.

H7 Savira must assess and document health-specific security risks, restrict and review privileged access, maintain appropriate access logs and use the Schedule 2 controls. Ordinary support must use minimum metadata before health content. Health information must not be used in public demonstrations, general AI tools or uncontrolled development environments.

H8 The breach procedure in clause 7 applies, with priority to likely patient harm, necessary containment and evidence preservation. Customer-led patient communications remain subject to each party's independent legal duties. The parties must support applicable health regulator and individual access/correction processes. Savira must not assume a general privacy retention rule replaces an applicable health-record duty.

H9 If unapproved health information is discovered, Savira must promptly notify the Customer, restrict access and further processing, and agree lawful deletion, return or scope amendment. It may take necessary protective action while awaiting instructions. Accidental receipt is not retrospective permission for continued routine use.

Clinical records and identifiers excluded under Schedule 1 unless separately authorised. No automatic permission for advertising, research, clinical decisions, My Health Record content or healthcare identifier processing.

My Health Record content and healthcare identifiers may attract additional requirements under the My Health Records Act 2012 (Cth) and Healthcare Identifiers Act 2010 (Cth). Processing them requires a separately agreed, legally reviewed supplement and verified technical capability before activation. This schedule alone is insufficient.

These are Savira's approved providers and locations. A provider or country not listed here is not approved.

Consent records are kept for as long as the Customer's account is open, and the Customer can export them at any time during that period.

Where a period is not stated here, clause 8.2 applies. Retention must remain lawful and proportionate, and does not itself establish a legal obligation to retain.