Data Processing Agreement

1. Parties

This Data Processing Agreement ("this DPA") is between:

• the Customer, the organisation that operates the workspace, acting as the APP entity under the Privacy Act 1988 (Cth) responsible for the personal information it submits to or generates within RTEO; and
• ROCKHAWK PTY LTD (ABN 17 673 537 123) trading as RTEO ("we", "us"), acting as the service provider that processes that personal information on the Customer's behalf and on the Customer's instructions.

This DPA forms part of, and is incorporated into, the RTEO Terms of Service. It applies to every workspace the Customer operates on RTEO.

2. Definitions

• "Personal information" has the meaning given in the Privacy Act 1988 (Cth): information or an opinion about an identified individual, or an individual who is reasonably identifiable.
• "APP" means an Australian Privacy Principle under Schedule 1 of the Privacy Act 1988 (Cth).
• "Australian Privacy Principle entity" or "APP entity" means the Customer, as the entity that collects personal information from its own students, contacts, and enquirers and decides why and how it is used.
• "Workspace" means the Customer's tenant within RTEO, the unit of data isolation enforced at the database layer.
• "Private-class data" and "Public-class data" have the meanings given in Schedule 1.
• "Subprocessor" means a third party RTEO engages to process personal information on the Customer's behalf, as listed in Schedule 2.
• "Overseas recipient" has the meaning given in APP 8: a person or organisation located outside Australia that a Customer's personal information may be disclosed to.

3. Roles and scope

The Customer is the APP entity. RTEO acts as the Customer's service provider, processing personal information only to provide the RTEO platform in accordance with the Customer's instructions. Those instructions are given through:

• the Customer's configuration of its workspace, including the AI processing mode chosen under clause 5;
• the Customer's use of the RTEO application and its integrations; and
• this DPA.

RTEO will not use personal information for any purpose other than providing the platform to the Customer, except where required by law.

4. Data classes

RTEO recognises two classes of data, described fully in Schedule 1:

• Private-class data: contacts, students, enrolments and enrolment forms, email content, agent chat conducted over workspace data, and any other content or output that identifies or could identify a person.
• Public-class data: the Customer's own public website content, competitor public web pages, keyword and search-console data, blog research, and generated blog images and their alt text.

An AI call that is not labelled with a data class is treated as private. This is a fail-safe default, not an exception.

5. AI processing modes and cross-border disclosure (APP 8)

At workspace creation, the Customer chooses one of two AI processing modes. This choice governs where private-class data may be sent for AI processing, and it is the Customer's own instruction as the APP entity responsible for that data.

5.1 Australia only. Private-class data is processed only by AI models served from within Australia, principally via Amazon Web Services (AWS) Bedrock in Sydney and Melbourne, using Anthropic Claude models served from Australian data centres. A private-class call that cannot be routed to an Australian model is refused rather than sent overseas.

5.2 Global. Private-class data may also be processed by AI model providers located outside Australia, principally Anthropic, OpenAI and Google in the United States, routed through Vercel AI Gateway. This gives the Customer access to the newest available models.

5.3 This choice is the Customer's own APP 8 instruction. Under APP 8.1, an APP entity must take reasonable steps before disclosing personal information to an overseas recipient. Where the Customer selects Global processing, the Customer is making an informed, deliberate instruction as the APP entity that collected the personal information, to permit its processing by named overseas providers for a stated purpose (AI-assisted work on the Customer's own data). RTEO acts on that instruction. RTEO does not decide, on the Customer's behalf, whether an overseas transfer is appropriate for the Customer's students or contacts; the Customer decides that by its choice of processing mode, and may change it at any time as described in clause 5.5.

5.4 Public-class data. Public-class data may be processed by global providers in both modes. It does not carry the same disclosure risk because it is not personal information about an identifiable individual. Public-class subprocessors are listed in Schedule 2.

5.5 Changing the mode. Tightening from Global to Australia only is self-service, available to the Customer at any time from workspace settings. Loosening from Australia only to Global requires the Customer to contact RTEO support. This is a deliberate friction point so that a decision to permit overseas disclosure is never made accidentally or by a single click.

5.6 Existing workspaces. Any workspace created before this DPA takes effect is treated as Australia only from the effective date, until the Customer makes an affirmative choice to switch to Global.

5.7 Restricted providers. Models originating in the People's Republic of China (including DeepSeek, Qwen, Kimi, GLM, and MiniMax) may only be used where served by AWS Bedrock from within Australia. It must never be used through the vendor's own service, and never through Vercel AI Gateway. No such model is in use as at the effective date of this DPA. Any future addition of such a model will appear in Schedule 2 before it is used for any workspace.

6. Subprocessors

RTEO engages the subprocessors listed in Schedule 2 to provide the platform. The Customer's acceptance of this DPA is consent to those subprocessors. RTEO will notify the Customer before adding a new subprocessor that will process private-class data, with a reasonable opportunity to object.

7. RTEO's obligations

RTEO will:

• process personal information only in accordance with the Customer's documented instructions, including the AI processing mode the Customer selects;
• ensure personnel who can access personal information are bound by confidentiality obligations;
• implement and maintain the security measures described in Schedule 3;
• not engage a new subprocessor for private-class data without notice to the Customer under clause 6;
• assist the Customer to respond to requests from individuals exercising their rights under the Privacy Act 1988 and the Australian Privacy Principles;
• notify the Customer without undue delay of any data breach that is an eligible data breach affecting the Customer's data, as described in clause 9; and
• on termination, delete or return the Customer's data as described in Schedule 4.

8. The Customer's obligations

The Customer, as the APP entity, is responsible for:

• establishing a lawful basis for collecting and holding the personal information it submits to RTEO;
• giving its own students, contacts, and enquirers the notices required by APP 5, and any consents required for its own purposes;
• choosing an AI processing mode under clause 5 consistent with its own privacy obligations and, where the Customer is a Registered Training Organisation (RTO), its Standards for RTOs obligations;
• where the Customer is an RTO, complying with its own record-keeping obligations under the Standards for RTOs and any NVR Act requirements; and
• maintaining its own relationship, and its own contract, with any student management system or other third-party system it connects to its RTEO workspace (see Schedule 2).

9. Data breach notification

RTEO will notify the Customer without undue delay, and in any event within 72 hours of becoming aware, of a data breach that affects the Customer's data and that RTEO reasonably believes may qualify as an eligible data breach under the Notifiable Data Breaches (NDB) scheme in Part IIIC of the Privacy Act 1988. The notification will include, to the extent known at the time:

• the nature of the breach and the kinds of personal information involved;
• the Customer's workspace(s) affected;
• the steps RTEO has taken or proposes to take in response.

Where the Customer is an APP entity and reasonably concludes the breach is an eligible data breach, the Customer remains responsible for its own notification obligations to affected individuals and to the Office of the Australian Information Commissioner (OAIC) under the NDB scheme. RTEO will provide reasonable assistance with that assessment and notification on request.

10. Individual rights

RTEO will give the Customer reasonable assistance to respond to a request from an individual to access, correct, or delete their personal information, consistent with the Australian Privacy Principles. Schedule 4 describes what RTEO's platform does today for account and data deletion.

11. Audit rights

On reasonable written request, RTEO will provide the Customer with information reasonably necessary to demonstrate compliance with this DPA. An audit beyond the provision of that information is subject to agreement between the parties on scope, timing, and confidentiality.

12. Term and termination

This DPA forms part of the RTEO Terms of Service, and takes effect for a Customer when the Customer accepts those Terms: by creating a workspace, accessing RTEO, or continuing to use it. There is no separate acceptance step for this DPA. It continues for as long as RTEO processes personal information on the Customer's behalf. Schedule 4 describes what happens to the Customer's data on termination.

13. Updates to this DPA

RTEO may update this DPA. A material change, for example a new subprocessor for private-class data, a change to the data classes processed, or a change to a retention period, will be notified to the Customer at least 28 days before it takes effect, so the Customer has an opportunity to review it. A Customer who does not accept a material change may stop using RTEO and terminate before the change takes effect, as described in clause 4.2 of the Terms of Service. Continued use of RTEO after a material change has taken effect is acceptance of the updated DPA.

A non-material change, such as a correction or clarification, will be versioned and takes effect without advance notice. No version of this DPA requires a separate acceptance step: the version published at this address, with the version number and effective date at the top of this document, is the version in force.

14. Governing law

This DPA is governed by the laws of New South Wales, Australia, and any dispute under it is subject to the non-exclusive jurisdiction of the courts of New South Wales.

This DPA is accepted through the RTEO Terms of Service rather than by a separate signature or acceptance step: creating a workspace, accessing RTEO, or continuing to use RTEO is acceptance of the version of this DPA in force at the time. RTEO does not record a per-workspace acceptance of a particular version.

Schedule 1: Data classes and processing locations

An AI call not explicitly labelled with a data class is treated as private. A private-class call is refused, not silently routed overseas, if no Australian model is available for it in Australia only mode.

Application compute. RTEO's application servers (Vercel serverless functions) are located in Sydney, Australia.

Database. The primary database (Supabase, hosted on AWS) is created per workspace with its region locked at creation; Australia is the only region offered.

Schedule 2: Subprocessors

Notes on this schedule:

• "As published by the provider" means RTEO relies on the region the provider states publicly, rather than on an independent audit. It is not a statement that the provider is unsafe. Locations may change; this schedule is updated when they do.
• aXcelerate, and any WordPress site, are the Customer's own systems that the Customer connects to their workspace under their own separate contract with those providers. RTEO routes data to and from them only on the Customer's instruction (via the integration the Customer configures) and does not control their retention or security practices.
• No Chinese-origin AI model (DeepSeek, Qwen, Kimi, GLM, MiniMax) is a subprocessor as at the effective date of this DPA. Any future addition will appear in this schedule, restricted to the AWS Bedrock Australia route described in clause 5.7, before it is used for any workspace.

Schedule 3: Security measures

• Tenant isolation. Every workspace's data is isolated by PostgreSQL row-level security policies enforced by the database itself. Tables that store encrypted third-party credentials, such as the Customer's own student management system API keys, have those policies enabled, with direct table privileges revoked and re-granted subject to RLS policy, so a workspace member can only reach rows for their own account_id.
• Credential vault. Third-party integration credentials (for example, aXcelerate API credentials) are stored encrypted at the application layer with AES-256-GCM before being written to the database. The ciphertext is stored as iv:authTag:ciphertext; RTEO does not store these credentials in plaintext at rest. A single helper module is the sole encrypt/decrypt path.
• Encryption in transit. Application traffic is served over HTTPS/TLS by Vercel's edge network.
• Encryption at rest. The primary database (Supabase on AWS) encrypts data at rest by default as part of the underlying cloud infrastructure, which is that provider's standard behaviour.
• Access logging. Workspace-scoped events, including DPA-relevant compliance events, integration connection changes, and enrolment activity, are written to structured event/audit tables as part of the application's normal operation.
• Backups. Supabase performs automated backups of the primary database as part of its managed-Postgres offering. The specific backup retention window is set in RTEO's database provider configuration and is available to the Customer on request.

RTEO does not hold, and this agreement does not assert, any formal security certification such as ISO 27001 or SOC 2.

Schedule 4: Retention and deletion

• Personal account deletion. A user who deletes their own personal account has their authentication record permanently deleted. This is a real deletion, not a flag that hides the account while the underlying record is kept.
• Workspace (team account) deletion. Deleting a workspace permanently removes the workspace's own record. Every table in RTEO that stores data belonging to a workspace, including contacts, enrolments, and integration connections, is configured to delete its own rows for that workspace at the same time. Deleting a workspace therefore removes every record that belongs to it, immediately, because nothing in RTEO is set up to keep a workspace's data behind after the workspace itself is gone.
• Retention while a workspace is active. Data belonging to an active workspace, one the Customer has not deleted and has not terminated the agreement for, is retained for as long as that workspace exists, because the Customer is actively using it. There is no separate retention clock counting down against that data while the workspace remains active.
• Retention after deletion or termination. When a workspace is deleted, or the agreement is terminated, deletion happens immediately rather than after a retention window. The only lag is in backups: Supabase's automated backups of the primary database retain their own copies for their own retention window, described in Schedule 3, and age out on that schedule rather than on request.
• RTO record-keeping is the Customer's own obligation. Where the Customer is an RTO, its own obligations under the Standards for RTOs (including AVETMISS/NCVER-linked record retention) sit with the Customer and with its own student management system (aXcelerate), which RTEO does not control and which is outside RTEO's own retention or deletion mechanism.