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.
• "Sensitive information" has the meaning given in the Privacy Act 1988 (Cth), and includes information about an individual's racial or ethnic origin, health, disability, religious beliefs, political opinions, sexual orientation, and criminal record.
• "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.
• "USI" means a Unique Student Identifier issued under the Student Identifiers Act 2014 (Cth).
• "Identity document" means a document an individual supplies to evidence who they are or their status, including a passport, a driver licence, a birth certificate, a visa grant notice, a Medicare card, and a scan or photograph of any of them.
• "Telemetry" has the meaning given in clause 8.

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; and
• to create and use Telemetry, which is de-identified and which clause 8 defines and limits.

Nothing in this clause permits RTEO to use personal information to train or fine-tune an AI model. Clause 8.1 states that prohibition without qualification.

4. Data classes

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

• Private-class data: contacts, students, enrolments and enrolment forms, Unique Student Identifiers and the other student fields described in clause 9, identity documents, email content and the mobile numbers SMS is sent to, 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, via Amazon Web Services (AWS) Bedrock, using Anthropic Claude models served from Australian data centres.

RTEO calls the AWS bedrock-runtime endpoint in the Sydney region (ap-southeast-2), and requests every Australian model through an Australian geographic inference profile, which is the au. prefix carried by each model identifier RTEO uses on this lane. A geographic inference profile is AWS's own mechanism for confining a request to a defined list of destinations, fixed by AWS rather than chosen by RTEO.

The destination list depends on where the call is sourced from. For a call sourced from an Australian region, the destinations in this profile are Sydney (ap-southeast-2) and Melbourne (ap-southeast-4), and no others. The same profile also accepts New Zealand as a source region, and a call sourced in New Zealand may be served there. RTEO makes no such call: RTEO's Bedrock region is configured to Sydney, so every private-class call on this lane is Australian-sourced, and is therefore served from Sydney or Melbourne. RTEO does not choose between the two, and cannot.

Prompts and outputs may be stored, not only processed. AWS states that prompts and outputs may be stored in the opt-in regions an inference profile routes to, for abuse detection purposes. Melbourne is such a region. RTEO records this here because the rest of this clause is about where data is processed, and storage is a different thing, which a Customer assessing its own APP obligations needs to be told about. For an Australian-sourced call the destinations are both Australian, so this storage is within Australia.

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, Google and Perplexity in the United States, routed through Vercel AI Gateway. This gives the Customer access to the newest available models, and to the capabilities clause 5.4 says are unavailable in Australia only mode.

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.6.

5.4 What Australia only mode turns off. Australia only mode is a real constraint, not a preference, and the Customer should choose it knowing what it costs. Three capabilities have no Australian model configured in RTEO today, so a private-class call that needs one of them is refused in Australia only mode rather than routed overseas:

These are limitations of RTEO's current model configuration. The Customer should not read a refusal as a statement that an Australian service cannot support the capability.

These capabilities are available only when the applicable processing setting allows their route. A refused call does not fall back to a Global provider. The affected feature returns an unavailable/error result; it does not make the rest of the workspace unavailable. Selecting Global processing under clause 5.6 makes these capabilities available for private-class data, with the cross-border consequence clause 5.3 describes.

5.5 Public-class data. The Customer may choose Global or Australia where available processing for public-class AI work separately from the private-data setting in workspace settings. Existing workspaces retain the Global behavior in force before this choice was introduced. Global private processing requires public processing to be Global as well. Under Australia where available, RTEO uses an Australian-served model when one is configured for the requested role; if not, the call is refused and is not retried through a Global provider. The affected feature reports that it is unavailable in that mode; other workspace features continue to operate. Public-class subprocessors and provider regions are listed in Schedule 2.

5.6 Changing the private mode. Tightening from Global to Australia only is self-service. Loosening from Australia only to Global requires the Customer to contact RTEO support. RTEO records when the mode was last changed and by whom. Public processing may be changed by a workspace member while private processing is Australia only; RTEO records the change. If private processing becomes Global, public processing is set to Global.

5.7 Existing workspaces. Existing workspaces retain their recorded private processing mode. Their public processing continues on the Global route until a workspace member changes that setting. New workspaces start with the private-data default recorded at creation and Global public processing unless the product flow records another permitted choice.

5.8 Where the database lives. A workspace's database region is fixed when the workspace is created and cannot be changed afterwards. Australia (Sydney) is the only region RTEO offers, and it applies in both AI processing modes: the AI processing mode governs where data may be sent for AI processing, not where it is stored.

5.9 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. They 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.

6.1 Schedule 2 is versioned on its own. Schedule 2 carries its own version number and last-updated date. Adding, replacing or removing a subprocessor is a change to Schedule 2 and is governed by this clause. It is not a material change to this DPA under clause 17, and it does not require the 28 days' notice that clause applies to a material change. This is deliberate: a vendor sometimes has to be replaced quickly, and the Customer's protection is the notice and objection process in this clause rather than a waiting period that would leave RTEO unable to act.

6.2 Notice. RTEO will give the Customer at least 15 days' notice before a new subprocessor begins processing private-class data. Notice is given by email to the workspace's registered contact, or in the application, or both. A change to a subprocessor that receives only public-class data is published in Schedule 2 without individual notice.

6.3 Objection. The Customer may object to a new private-class subprocessor, on reasonable grounds related to data protection, by telling RTEO in writing within 15 days of the notice. The parties will then work in good faith for up to 30 days to resolve the objection, for example by RTEO explaining the safeguards that apply, offering a configuration that avoids the subprocessor, or choosing a different vendor.

6.4 What happens if an objection is not resolved. If the objection is not resolved within that 30 days, the Customer may terminate the affected part of the service, or this DPA and the Terms of Service in full, by written notice given before the new subprocessor begins processing the Customer's private-class data. On a termination under this clause, RTEO will refund the unused portion of any fee the Customer has paid in advance for the period after termination, and the Customer is not liable for any early termination fee or other penalty. This is the Customer's remedy for an unresolved objection.

6.5 RTEO stays responsible. RTEO will impose on each subprocessor obligations that are, in substance, no less protective than those in this DPA to the extent they are relevant to what that subprocessor does, and remains responsible to the Customer for a subprocessor's performance of those obligations.

6.6 The Customer's own connected systems are not RTEO subprocessors. A system the Customer connects to its own workspace under its own contract with the provider, including its student management system, its own website, and its own analytics or advertising tags, is the Customer's system. RTEO routes data to and from it on the Customer's instruction and does not control its retention or security. Schedule 2 identifies these separately for transparency; listing them there does not make RTEO responsible for them.

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, and the Telemetry right in clause 8;
• 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 of any data breach affecting the Customer's data as described in clause 12;
• give the Customer the assistance described in clause 14 with a privacy impact assessment or a regulator's enquiry; and
• on termination, delete or return the Customer's data as described in Schedule 4.

8. Telemetry and de-identified learning

8.1 RTEO never trains on the Customer's data. RTEO does not use the Customer's content, personal information, enrolment data, AI output or workspace data to train, fine-tune, adapt or otherwise alter the weights of any AI model, whether RTEO's own or a third party's. RTEO does not permit a subprocessor to do so. This promise is not qualified by anything else in this clause or in this DPA.

8.2 What Telemetry is. "Telemetry" means the operational record RTEO derives from how the platform is used, and the conclusions RTEO draws from it: event logs, timings, error and failure records, counts and other summary statistics, aggregates, one-way hashes, classifications and labels, quality and performance metrics, model routing decisions, and the learnings RTEO forms from any of them.

8.3 Telemetry is de-identified, and it is not the Customer's data. Telemetry does not include personal information, the Customer's content, AI output, or the text of anything a person wrote. It is a derived artefact that RTEO creates about the operation of RTEO's own platform, not a copy of or an extract from the Customer's data, and the Customer's ownership of its own content does not extend to it. RTEO owns Telemetry and may process, retain and use it without restriction to operate, secure, measure, debug, support and improve the platform, to plan and build new features, to report on platform-wide usage and performance, and to meet its own legal and accounting obligations. RTEO may publish or share aggregate Telemetry provided it does not identify the Customer, a workspace or any individual.

8.4 RTEO will not re-identify. RTEO will not construct Telemetry in a way designed to allow an individual, or a Customer's content, to be re-identified from it, and will not attempt to re-identify an individual from Telemetry.

8.5 What this covers in practice. By way of example and without limiting clause 8.2, RTEO records how far through an enrolment form a person progressed before stopping, and how many times a part-completed enrolment was saved. These are counters kept against the enrolment record for drop-off analysis; they record the step reached and the number of saves, not the answers given. The answers themselves, including a USI, a date of birth and any sensitive information, are private-class data and are never Telemetry.

8.6 The Customer's own tracking tags are outside this DPA. The Customer may install its own measurement and advertising tags in its workspace, including a Google Tag Manager container, a Google Analytics 4 property, Google Ads conversion tracking, a Meta Pixel and a Bing UET tag, and may choose which surfaces they fire on, including its enrolment pages. Those tags are the Customer's own collection, made in the Customer's own browser session with the End User and sent to the vendor the Customer chose under the Customer's own contract with that vendor. RTEO does not control, receive, inspect or store what they collect, and RTEO is not the Customer's service provider in respect of them. Enrolment pages are pages on which a student may enter a USI, a date of birth, sensitive information and other personal information, so a tag enabled there may observe an End User's activity on those pages. The Customer is the APP entity for that collection: the APP 5 notice, any consent the law requires, and the entry in the Customer's own privacy policy are the Customer's to give. RTEO's own analytics on its own public marketing website are a separate thing and are described in RTEO's Cookie Policy.

9. Unique Student Identifiers and student records

9.1 What RTEO holds. Where the Customer uses RTEO's enrolment features, RTEO processes, on the Customer's behalf, the information the Customer's own enrolment form collects. The Customer builds that form from RTEO's field catalogue, which includes a field for a USI and fields for the student information an RTO collects for its AVETMISS reporting: date of birth, gender, country and city of birth, Aboriginal or Torres Strait Islander status, citizenship or residency status including visa type, disability status and disability type, language spoken at home and English proficiency, prior educational achievement and highest school level, labour force status, a Victorian Student Number, contact details, and an emergency contact's name, relationship and phone number. Where the Customer's form asks for a document, RTEO also stores the file the student uploads. Schedule 1 identifies these as data categories, and all of them are private-class data.

Which of these fields a given form asks for is the Customer's decision. RTEO provides the field; the Customer chooses whether to collect it.

9.2 RTEO handles a USI on the Customer's behalf only. The Customer is the entity that collects the USI from the student and that holds the authority to collect it. RTEO receives it as an answer on the Customer's enrolment form, holds it as part of that part-completed enrolment record so the student can come back to it, and passes it to the Customer's own student management system where the Customer has configured that integration. RTEO does not keep a separate register of student identifiers, and there is no student-identifier field anywhere in RTEO's database outside the enrolment record itself. The Customer's student management system is the system of record for a USI, not RTEO.

RTEO does not use a USI for its own purposes, does not disclose it to anyone other than the Customer's own connected systems, does not use it as a key or an identifier within the platform, and never includes it in Telemetry.

9.3 The Student Identifiers Act 2014 (Cth). The Student Identifiers Act 2014 (Cth) restricts the collection, use and disclosure of a USI, and treats a USI as personal information for the purposes of the Privacy Act 1988 (Cth). In relation to any USI it handles for the Customer, RTEO will:

• collect, use, store and disclose it only as necessary to provide the platform to the Customer and on the Customer's instructions;
• not use or disclose it for any other purpose, including any purpose of RTEO's own, and not sell it or make it available to any third party other than a subprocessor listed in Schedule 2 or a system the Customer has connected;
• protect it with the security measures in Schedule 3; and
• treat an unauthorised access to, loss of, or disclosure of a USI as a data breach under clause 12.

The Customer remains responsible for its own obligations under that Act, including having the authority to collect and use the USI, giving the student the notice that Act and the Australian Privacy Principles require, and the Customer's own reporting.

9.4 RTEO checks the format of a USI. It does not verify it. RTEO checks that what has been typed has the shape of a USI: ten characters drawn from the restricted alphabet the USI scheme uses. That is the whole of the check.

RTEO does not connect to the USI Registry, does not verify a USI against the Registry, does not confirm that a USI has been issued, and does not confirm that a USI belongs to the person who entered it. A USI that passes RTEO's check may still be wrong, may belong to someone else, or may not exist. Nothing in the platform, its interface or its output should be read as saying otherwise, and the Customer must not represent to a student, a regulator or an auditor that RTEO has verified a USI. Verification against the USI Registry, and creating a USI for a student who does not have one, remain the Customer's own responsibility through the Registry's own channels.

9.5 AVETMISS and NCVER reporting are the Customer's. RTEO does not produce AVETMISS files, does not submit data to NCVER or to a state training authority, does not connect to any NCVER system, and does not validate data against an AVETMISS standard. The Customer's reporting obligations sit with the Customer and with its own student management system.

RTEO does render, within the Customer's enrolment form, the student privacy notice set out in Schedule 1 of the National VET Data Policy, with the Customer named as the collecting RTO. RTEO reproduces that published notice and does not write it. Four parts of it are the Customer's own wording and RTEO leaves them for the Customer to complete: the consequences of not providing the information (APP 5.2(e)), the overseas disclosure statement (APP 5.2(i) and (j)), the relevant state or territory training authority, and the Customer's own contact details. RTEO does not check what the Customer writes in them, and displaying the notice is not advice that the Customer's collection notice is sufficient.

10. Sensitive information

10.1 RTEO may hold sensitive information. Some of the fields in clause 9.1 are sensitive information as the Privacy Act 1988 (Cth) defines it, including Aboriginal or Torres Strait Islander status, disability status and disability type, and racial or ethnic origin inferable from other fields. An identity document may reveal more.

RTEO does not provide a health or medical field, and does not provide a criminal record or police check field. Health information can still reach RTEO in two ways, both of which are the Customer's own doing: through a custom field the Customer has created in its own student management system and mirrored into its form, and through a declaration or free text question the Customer writes itself. Where that happens the information is the Customer's collection, and clause 10.2 applies to it.

10.2 Consent under APP 3.3 is the Customer's to obtain. APP 3.3 generally requires an APP entity to have the individual's consent before collecting sensitive information, unless an exception applies. The Customer collects this information from the student; RTEO only stores and processes it on the Customer's instruction. Obtaining that consent, or identifying the exception the Customer relies on, is the Customer's responsibility as the APP entity, as is saying in its own privacy notice what sensitive information it collects and why.

10.3 What RTEO does with it. RTEO treats sensitive information as private-class data everywhere in the platform. It is subject to the AI processing mode in clause 5, the security measures in Schedule 3, and the retention and deletion behaviour in Schedule 4. RTEO does not use it to make any decision about an individual, and it is never Telemetry.

10.4 The Customer should not send sensitive information where it does not belong. Sensitive information, a USI, a date of birth, a government identifier and an identity document belong in the enrolment field built to hold them. The Customer must not put them into a free text field, an agent chat message, a support ticket, a brand or content prompt, or any other part of the platform that is not designed for them. RTEO's Acceptable Use Policy says the same thing.

11. 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, including any consent APP 3.3 requires for sensitive information;
• giving its own students, contacts, and enquirers the notices required by APP 5, and any consents required for its own purposes;
• its authority to collect and use a USI under the Student Identifiers Act 2014 (Cth), and any notice that Act requires;
• 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, and understanding what clause 5.4 says Australia only mode turns off;
• where the Customer is an RTO, complying with its own record-keeping obligations under the Standards for RTOs and any NVR Act requirements;
• its own tracking and advertising tags, as clause 8.6 describes; 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).

12. Data breach notification

12.1 RTEO notifies on any breach, not only on an eligible one. RTEO will notify the Customer without undue delay, and in any event within 72 hours of becoming aware, of any unauthorised access to, unauthorised disclosure of, or loss of the Customer's data held by RTEO or by a subprocessor. RTEO does not wait to form a view about whether the incident is an eligible data breach before notifying: that assessment belongs to the Customer as the APP entity, and RTEO will not make it on the Customer's behalf or delay notice while it considers the question.

12.2 What the notification contains. The notification will include, to the extent known at the time, and will be supplemented as more becomes known:

• what happened, and when RTEO became aware of it;
• the kinds of personal information involved, including whether a USI, sensitive information or an identity document was involved;
• the workspaces and, where RTEO can determine it, the individuals or categories of individuals affected;
• the likely consequences as RTEO understands them; and
• the steps RTEO has taken or proposes to take to contain the incident and to prevent a recurrence.

12.3 The Customer assesses, and RTEO assists. The Customer assesses whether the incident is an eligible data breach under the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988 (Cth), and the Customer makes any notification to affected individuals and to the Office of the Australian Information Commissioner. RTEO will give the Customer the reasonable assistance it needs to carry out that assessment within the 30 days Part IIIC allows, and to make any notification, including information, logs and access to the people who dealt with the incident.

12.4 RTEO's own notification. Where RTEO is itself an APP entity in respect of an incident, RTEO will meet its own obligations. RTEO will not notify the Customer's individuals or the Commissioner on the Customer's behalf unless the Customer asks it to in writing and the parties agree what will be said.

12.5 Contact. RTEO will notify the workspace's registered contact. The Customer should keep that contact current and may nominate a dedicated privacy or security contact by telling RTEO in writing.

13. 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, including the difference between a record-level soft delete and an erasure.

Where an individual contacts RTEO directly about personal information in a Customer's workspace, RTEO will not respond to the substance of the request. RTEO will tell the individual that the Customer is the organisation responsible and will refer the request to the Customer promptly.

14. Privacy impact assessments and regulator engagement

On the Customer's reasonable written request, RTEO will give the Customer the information about RTEO's processing that the Customer reasonably needs to carry out a privacy impact assessment or data protection impact assessment, and reasonable assistance with a consultation, enquiry or investigation by the Office of the Australian Information Commissioner or by a VET regulator, to the extent it concerns RTEO's processing of the Customer's data.

RTEO will provide this without charge where it can be met from information RTEO already maintains, including this DPA and its schedules, and Schedule 3. Where a request requires materially more than that, for example bespoke documentation, a completed vendor questionnaire, or sustained engagement with a regulator, RTEO may charge its reasonable costs at its then-current professional services rates, and will tell the Customer the estimated cost before starting the work so the Customer can decide whether to proceed. RTEO will not use a fee to avoid giving assistance that this DPA or the law requires it to give.

15. Audit rights

15.1 Information first. On reasonable written request, RTEO will provide the Customer with information reasonably necessary to demonstrate compliance with this DPA. In most cases this DPA, its schedules, and RTEO's answers to the Customer's written questions will be enough.

15.2 Audit. Where they are not, the Customer may audit RTEO's compliance with this DPA on these terms:

• Frequency: once in any 12-month period.
• Notice: at least 30 days' written notice, setting out the scope.
• Timing: during RTEO's normal business hours, and in a way that does not unreasonably disrupt RTEO's business.
• Scope: limited to RTEO's processing of the Customer's own personal information and to RTEO's compliance with this DPA. It does not extend to another customer's data, to another customer's configuration, to RTEO's source code, or to anything RTEO is contractually or legally barred from disclosing.
• Who: the Customer, or an independent auditor the Customer appoints who is not a competitor of RTEO, who signs RTEO's confidentiality undertaking before the audit begins.
• Confidentiality: everything seen or learned in the audit is RTEO's Confidential Information under the Terms of Service.
• Cost: the Customer bears its own costs and RTEO's reasonable costs of supporting the audit. Where the audit finds a material breach of this DPA by RTEO, RTEO bears its own costs and refunds the Customer's reasonable audit costs.

15.3 More often, where it is warranted. The once-in-12-months limit does not apply where an audit is required by a law or a regulator with jurisdiction over the Customer, or where the Customer audits in response to a data breach RTEO has notified under clause 12. In either case the other terms in clause 15.2 still apply.

15.4 Subprocessors. RTEO will use reasonable endeavours to obtain, from a subprocessor, the information the Customer reasonably needs about that subprocessor's processing. RTEO cannot grant a right to audit a subprocessor's own premises or systems, and does not purport to.

16. 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.

17. Updates to this DPA

RTEO may update this DPA. A material change, for example a change to the data classes processed, a change to a retention period, a change to the AI processing modes, or a change to the Telemetry right in clause 8, 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 change to Schedule 2 is not a material change and is governed by clause 6, which gives the Customer its own notice period, objection right and termination remedy for a new private-class subprocessor.

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 current version, and it is in force from its effective date; until then, the previous version stays in force. Earlier versions of this DPA stay available: version 1.

18. 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 categories and processing locations

Processing locations by data class.

Categories of data RTEO holds. All of the following are private-class data except where the table says otherwise.

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 pinned to Sydney, Australia (syd1) in RTEO's deployment configuration, which is committed to RTEO's own source repository rather than left to the hosting provider's default. No part of the application overrides that region for a particular route.

Ahead of those functions sits the hosting provider's global request routing layer, which terminates the connection nearest the visitor and forwards the request. That layer is not region-pinned and is not capable of being so. It passes requests through and does not store the Customer's data, which is why Schedule 2 records it as a pass-through rather than as a place data is held.

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

Schedule 2: Subprocessors

Schedule 2 version: v4. Last updated: 2 October 2026.

This schedule is versioned on its own and is changed under clause 6, not under clause 17.

The Customer's own connected systems. These are not RTEO subprocessors. They are listed for transparency under clause 6.6.

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.
• No Chinese-origin AI model (DeepSeek, Qwen, Kimi, GLM, MiniMax) is a subprocessor as at the date of this schedule. Any future addition will appear here, restricted to the AWS Bedrock Australia route described in clause 5.9, 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.
• Private storage. Files containing personal information, including identity documents and enrolment attachments, are held in private storage buckets that are not publicly readable. Access is gated by path-based policies that resolve the owning workspace from the object's own path, so a member of one workspace cannot read another workspace's files.
• 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.
• AI routing is enforced in code, not by policy. The data class and the workspace's AI processing mode are resolved on every AI call by a single routing module, which refuses a private-class call that has no Australian model in Australia only mode rather than falling back to a global provider.
• 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

This schedule describes RTEO's retention and deletion behaviour as at the effective date above. Where a behaviour depends on a database change that has been prepared but not yet applied to a given environment, RTEO will not publish this version of the DPA for that environment until it has been.

Workspace (team account) deletion is immediate and complete. Deleting a workspace removes the workspace's record and, in the same database transaction, every record and every stored file that belongs to it: contacts and contact records, enrolments and part-completed enrolment drafts, uploaded documents, knowledge base content, integration connections, billing and usage records, and the workspace's files across all eight of the platform's storage buckets (account images, enrolment documents, compliance documents, brand reference images, business logos, blog images, media originals and media assets).

This is enforced by the database itself, by a trigger that fires on the deletion of the workspace record, rather than by application code. It therefore holds however the deletion happens: through the application, through a direct database statement, or as a consequence of deleting the authentication user the workspace belonged to. There is no path that removes a workspace while leaving its data behind.

What is not deleted in the same instant. Four things lag, and each is cleared by a scheduled job rather than by the deletion itself:

The credential sweep will not remove a secret that is still referenced, and applies a short grace period to a newly created secret so that one written moments before its reference cannot be swept in between.

One-time verification codes hold a student's email address. A code issued so a student can sign in to an enrolment form or resume a saved one records the address it was issued for, in plain text, alongside the code. These records sit outside the workspace, because the code has to be checkable before the person is known to belong to one. They are cleared on the timetable in the table above. This is the one place a student's email address exists outside workspace scope, and RTEO discloses it here rather than leave it implied.

RTEO keeps its own record of a sale. Where a workspace was bought through RTEO's own onboarding and payment flow, RTEO's record of that transaction, including the amount and the payment provider's references, is RTEO's own accounting record and is retained after the purchasing workspace is deleted. The link to the deleted workspace is severed, so the record no longer points at a workspace that no longer exists, but the transaction record itself remains. RTEO keeps it because it is a record of RTEO's own sale and RTEO has its own tax and accounting retention obligations, which run to seven years. Where the purchaser deletes its own workspace, everything held against that purchaser as an account owner is deleted with it; what survives is RTEO's record of the transaction, not the Customer's workspace data.

Personal account deletion. A user who deletes their own personal account has their authentication record deleted, and the workspaces they solely owned are deleted with it under the cascade described above. RTEO does not presently warrant that a personal account deletion always succeeds: some records elsewhere in the platform still reference the authentication user in a way that can block the deletion, in which case it fails rather than partially completing. Where that happens, RTEO will complete the deletion manually on request. RTEO would rather state this than publish a guarantee the platform does not yet keep.

Record-level deletion is not always erasure. Within a live workspace, "delete" on some records is a soft delete: the row is stamped with a deleted_at time, disappears from the application, and is excluded from search, AI retrieval and reporting, but the underlying row remains in the database until the workspace itself is deleted. This applies to contacts, brand profiles, contact documents, contact messages, and knowledge base sources and their extracted chunks. Other records, for example course pages, are hard-deleted. If the Customer needs a record erased rather than hidden, the Customer should ask RTEO, and RTEO will action it.

Knowledge base chunks carry a 30-day grace boundary. A soft-deleted knowledge base chunk is excluded from AI retrieval immediately, so it stops influencing any generated output straight away. The row itself is retained for a 30-day grace window from the time it was soft-deleted, so that a page removed in error can be restored, and a nightly job hard-deletes it after that.

The retention period is the life of the account. RTEO retains the Customer's data for as long as the account exists, and deletes it when the account is deleted. There is no shorter standing clock, and RTEO does not claim one. This is the retention period for the Customer's data generally, and it is stated here because two categories are most likely to prompt the question:

• a part-completed enrolment draft, which holds live personal information including any USI, date of birth and sensitive information entered so far, and the details of other people a booker is enrolling; and
• an uploaded identity document, such as a scan of a driver licence.

Both are held for the life of the account and removed when the account is deleted, under the cascade described at the top of this schedule.

What this rests on. Each of these records also carries a column reserved for an earlier, record-level purge, and the job that would use those columns is not built. Nothing therefore removes a draft or a document ahead of account deletion. The retention promise in this schedule is consequently a promise about account deletion doing its job, and the Customer should read it that way. Where the Customer needs a particular draft or document removed sooner, the Customer should ask RTEO and RTEO will action it.

A part-completed draft is never returned to a browser without passing a verification code, and is reachable only by RTEO's own server, not by a workspace member through the application.

A submitted enrolment queued for delivery is swept. Where a submitted enrolment is waiting to be delivered to the Customer's student management system, a nightly job empties the personal information held against it once it has been delivered or has reached the end of its life, and stamps the record as purged.

Deleting in RTEO does not reach the Customer's own system. Where a document or an enrolment record has already been delivered to the Customer's student management system, deleting it in RTEO deletes RTEO's copy only. That system offers no way for RTEO to delete what has been written to it, so removing the Customer's own copy is the Customer's to do there.

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, other than the scheduled jobs described above.

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. A deletion is therefore effective in the live database immediately and in the backups when they age out.

Export before you terminate. RTEO does not undertake to retrieve deleted data. The Customer should export what it needs before deleting a workspace or terminating.

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. Deleting a workspace does not delete anything that has already been written to the Customer's student management system.