Data Processing Addendum

This Data Processing Addendum ("DPA") forms part of the Terms of Service between ACADEMYSHIP PTY LTD (ACN 698 283 448, ABN 89 698 283 448) of Unit 44, 3-7 Fetherstone Street, Bankstown NSW 2200, Australia ("Academyship", "we") and the customer institution ("Customer", "you"). It governs Academyship's processing of Customer Personal Data when Customer uses the Academyship education and institution management platform and related services. This DPA takes effect through the Customer's acceptance of the Terms or an Order Form that incorporates it, and a countersigned copy or customer-specific privacy/security schedule is available on request.

Modules are available by plan and configuration, and not every Module described in this DPA is available to every Customer. A provision of this DPA that concerns a particular Module applies when Customer uses that Module.

#01Parties, roles and Australian terminology

Each party must comply with the privacy, data-protection, education, health-records, public-records and other information-handling laws applicable to it. Academyship complies with the Privacy Act 1988 (Cth) and the Australian Privacy Principles to the extent they apply to Academyship. A Customer may instead be, or may also be, subject to state or territory privacy and records legislation, including where it is a government education Institution, TAFE, public university or other public-sector body.

For Customer Data, the Customer determines the purposes for which the information is handled and controls the configuration and authorised use of its Tenant. Academyship processes Customer Data on the Customer's documented instructions to provide the service. The international terms "controller" and "processor" are used only as practical shorthand and do not displace the Australian legal framework applicable to either party.

Academyship acts independently for its own business records, including billing, account administration, sales enquiries, service security, internal governance and support records, as described in the Privacy Policy. Academyship engages approved Subprocessors to help deliver the Services, as described in section 18 and Annex III.

White-label presentation, Institution branding or an Institution-controlled domain does not alter the parties’ controller, processor, responsible-entity or service-provider roles under this DPA.

Not all processing connected with the Services is carried out on Customer's instructions. Academyship processes some information to meet its own legal obligations and to secure and operate the Services. Some other providers act for their own purposes under their own terms, such as a payment provider performing fraud-prevention, identity-verification and financial-services compliance functions, or a speech-recognition service supplied by a User's browser or device. A provider's role depends on the function it performs and the terms that govern that function. Who enables a feature does not by itself determine that role. Annex I identifies the main examples.

#02Definitions

Applicable Data Protection Laws means the privacy, data protection, data breach notification, student data, education, tax, payroll and records-management laws that apply to a party's processing of personal information under this DPA.

Customer Personal Data means personal information or personal data contained in Customer Content or otherwise processed by Academyship on Customer's behalf through the Services. In this DPA, references to "Customer Data" mean Customer Personal Data and Customer Content.

Customer Content means records, files, messages, documents, uploads, configuration, communications, AI outputs, reports, certificates, letters, exports and other content submitted to, stored in, imported into, generated within or exported from a Customer workspace.

Services means the Academyship platform, portals, APIs, modules, support and related services ordered by Customer or made available under the Terms or an Order Form.

Tenant means the logically and operationally isolated workspace and dedicated database provisioned for a Customer.

Module means a functional area of the Services, such as fees and payments, payroll, electronic signatures, credentials or library, that is available under Customer's plan and configuration. Annex I describes the processing for each Module.

External Participant means an individual who is not a User of Customer's workspace but whose personal information is processed because Customer uses a Module, such as an external signer, external reviewer, payer, visitor, enquirer or complainant.

Institution Charges means amounts Customer charges its students, payers or others, such as tuition, instalments, canteen purchases, library fines or booking fees. Institution Charges are not Academyship's fees under the Terms.

Subprocessor means a third party engaged by Academyship to process Customer Personal Data for the Services.

Security Incident means an event that compromises or may compromise the security, availability, integrity or confidentiality of the Services or Customer Personal Data.

Personal Data Breach means a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Customer Personal Data.

Usage Data / Service Data means operational logs, diagnostic events, authentication events, feature usage, device/browser metadata, performance data and support metadata generated by use of the Services. Usage Data may include personal information depending on context.

Aggregated or De-identified Data means data that has been aggregated, de-identified or anonymised so that it does not identify an individual or Customer and is not reasonably capable of re-identification by Academyship.

Order Form means an ordering document, signed proposal, customer agreement or schedule that identifies Customer, Services, commercial terms, regional terms or special privacy/security commitments.

Student Data means Customer Personal Data relating to students, learners, applicants, alumni and similar education participants, including minors.

Sensitive Information means personal information treated as sensitive or special-category information under applicable law, including health information, disability information, racial or ethnic origin, religious beliefs, sexual orientation and biometric information used for identification.

Regulated Identifiers means Tax File Numbers (TFNs), Unique Student Identifiers (USIs), state student identifiers, passport numbers, visa identifiers and similar identifiers subject to additional legal handling requirements. A superannuation fund's Unique Superannuation Identifier identifies a fund, not an individual, and is a different identifier from a Unique Student Identifier.

Academyship may use Usage Data / Service Data to operate, secure, support, monitor and improve the Services, subject to this DPA and the Privacy Policy. Aggregated or De-identified Data may be used for service improvement, analytics, benchmarking, security and business purposes, provided it does not identify Customer or individuals and is not reasonably capable of re-identification by Academyship.

#03Order of precedence

If there is a conflict between documents, a signed Order Form or customer agreement prevails for commercial terms. This DPA, or a signed privacy/security addendum, prevails for processing of Customer Personal Data to the extent of that conflict. The Terms of Service apply otherwise.

The Privacy Policy, Cookie Policy and Trust & Security page provide public descriptions of Academyship's practices. They do not reduce any contractual protections expressly agreed in this DPA, a signed Order Form or a signed privacy/security schedule.

A module-specific schedule applies only when it is identified by name and version in an Order Form or an authorised module activation, and only for that Module's subject matter. It does not override this DPA on the processing of Customer Personal Data unless it expressly says so. This DPA refers to public pages, including the Responsible AI Statement and the Subprocessor Register, for information. Later changes to those pages do not change this DPA, except that Subprocessor changes made under section 18 are recorded in the Subprocessor Register.

#04Subject matter and duration

The subject matter of processing is Academyship's provision of a configurable education and institution management platform and related services for Customer. Processing continues for the subscription term, any renewal term, support and transition period, export window and return/deletion period, unless a longer period is required by law, contract, legal hold, security investigation, dispute, backup integrity or disaster recovery requirements.

#05Nature and purpose of processing

Academyship processes Customer Data only to provide, secure, support, maintain and administer the platform, comply with applicable law and carry out the Customer's documented instructions for the duration of the Customer's subscription and the agreed wind-down period. Academyship may improve the platform using aggregated or de-identified information that is not reasonably capable of identifying the Customer or an individual, but does not repurpose identifiable Customer Data outside the Customer's instructions.

Processing includes performing admissions, enrolment, attendance, timetable, assessment, reporting, communications, finance, payroll, portal, document, integration and other configured functions, including the homework, VET and compliance, credential, booking and event, library, behaviour and wellbeing, front-office, canteen, payment and electronic-signature Modules where Customer uses them, and troubleshooting, abuse prevention and service-reliability activities carried out to operate and protect the Services.

Academyship does not use identifiable Customer Personal Data for unrelated product analytics, advertising, behavioural marketing, sale of data, or general AI model training.

Processing operations

The processing operations are collection, recording, storage, organisation, structuring, retrieval, consultation, use, display, calculation, transmission, disclosure to authorised Users, recipients and Subprocessors, restriction, export, deletion, backup, restoration and support activities. Annex I describes the operations for each Module.

Purposes of specific activities

#06Categories of data and data subjects

Data subjects may include students, including minors; parents, guardians and emergency contacts; applicants and enquiries; staff and employees, including trainers, teachers and assessors; contractors; institution administrators; alumni where configured; payers and debtors, including people who pay on behalf of someone else; external signers, approvers and copy recipients of electronic-signature documents; external reviewers and approvers of credentials; credential holders; library borrowers; booking customers and event participants; visitors; callers, enquirers and complainants; and candidates where relevant modules are used.

Categories of personal data may include identity and contact details; admissions and enrolment data; guardian relationships; attendance, timetable and calendar records; assessment, exam and academic progress data, including homework submissions, marks, feedback and individual adjustments within group work; behaviour, wellbeing, support and safety records, including incident reports, allegations, goals, interventions and evidence files; health, disability, accessibility and accommodation information, including dietary and allergy restrictions; certificates, cards, letters, documents, uploads and media, including portraits used on credentials; electronic-signature records, including documents, form answers, drawn or typed signatures, signer identity and contact details, timestamps, IP address and device data, disclosure versions, document hashes and audit events; library loans, reservations, fines, receipts, ratings and reviews; canteen orders, meal subscriptions, campus card numbers and identifiers, wallet balances, spending limits, top-ups, transfers and refunds; bookings, holds, waitlists, event RSVPs, comments, locations and meeting links; visitor records, including ID-proof details and images, and front-office enquiry, call and complaint records; finance, fees, invoices and payment metadata, including payment-provider customer and mandate identifiers, transaction, refund and dispute records, and masked card or bank details where the provider returns them; payroll, HR, timesheet, leave, bank, superannuation and STP-related records; USI, VET, AVETMISS and RTO compliance data; TFNs where payroll is used and lawful; international-student, visa and passport-related fields where configured; communications content and logs; portal invitation and sign-in records, including IP address and browser information; audit, security, device and usage logs; and AI inputs, authorised context, outputs and related usage or audit events where AI Features are enabled.

Annex I sets out the data subjects, data categories, purposes and operations for each Module.

#07Sensitive, regulated and special-category data

The Services can process Sensitive Information where Customer configures relevant modules or fields. This may include health information, disability and accessibility needs, and other information treated as sensitive or special-category information under Applicable Data Protection Laws. The Services can separately process Regulated Identifiers where Customer configures the relevant education, payroll, migration or compliance function.

Customer is responsible for lawful basis, notices, consents, minimisation, retention and access permissions for Sensitive Information. Sensitive Information should not be entered into general notes or free-text fields unless necessary, authorised and appropriate for the relevant record.

Academyship processes Sensitive Information only to provide the Services and does not use it for advertising, model training, unrelated analytics or independent commercial purposes. Access should be role-restricted and configured by Customer.

Safeguards for Sensitive Information

For Sensitive Information, Academyship will:

• process it only for the purposes described in Annex I for the relevant Module and on Customer's instructions;
• provide role-based permissions and visibility settings that let Customer limit who can see it, including in portals, notifications and exports where the Module supports those settings;
• protect it in transit and at rest in accordance with Annex II, Part A;
• not use signature images, portraits or visitor images for biometric identification or verification; and
• delete it in accordance with section 20.

Customer decides which Sensitive Information it collects and who may see it, including what guardians, External Participants and notification recipients receive. Information such as dietary requirements, behaviour notes or library borrowing history can reveal health, religious or other sensitive matters even when it is not recorded as Sensitive Information, and Customer should configure access to it with that in mind.

#08USI, TFN and regulated identifiers

Unique Student Identifiers (USIs) are processed only for lawful education, VET/RTO verification, reporting or compliance functions configured by Customer. Tax File Numbers (TFNs) are processed only where Customer uses payroll, tax or superannuation functions and is lawfully entitled to collect and process them.

USIs and TFNs are Regulated Identifiers, not Academyship account identifiers. Customer must not enter USIs, TFNs or similar Regulated Identifiers into unrelated free-text fields. Academyship applies access controls and masking or encryption controls where supported. Customer remains responsible for being a lawful recipient or collector of those identifiers and for required notices, consents and handling rules.

Storing a USI in the Services does not by itself authorise Customer to create, verify or access transcripts for a student's USI. Each of those actions requires the authority and notices that apply to it.

TFN safeguards in the payroll Module

Where Customer uses the payroll Module, Academyship will:

• display TFNs masked by default;
• allow full-TFN viewing, editing and export only by Users in roles that Customer has separately authorised for each of those actions;
• record each full-TFN view and each export containing full TFNs in an audit record;
• transmit TFNs only over encrypted connections, and only to recipients that need them for a permitted taxation, superannuation or assistance purpose on Customer's instructions;
• not use a TFN as an account identifier, or to match personal information other than as the law permits;
• not ask Customer or its Users to send a full TFN by support email or in a support ticket; and
• delete TFNs in accordance with section 20, subject to records Customer must keep by law.

Customer is responsible for collecting TFNs only for a permitted purpose, for giving the notices the law requires (including that an individual is not obliged to quote a TFN, and the consequences of not doing so), and for reviewing which roles hold full-TFN permissions. A payroll export that an authorised User downloads is in Customer's control once downloaded.

#09Processor obligations

Academyship will process Customer Personal Data only on documented instructions from Customer, including the Terms, this DPA, Order Forms, Customer configuration and authorised use of the Services. Where legally permitted, Academyship will notify Customer if it believes an instruction infringes Applicable Data Protection Laws.

Academyship will ensure authorised personnel are bound by confidentiality, restrict access on a need-to-know and least-privilege basis, maintain the technical and organisational measures in Annex II, Part A, assist with rights requests, DPIAs/PIAs, breach response and regulator enquiries as stated in this DPA, and ensure Subprocessors are bound by data-protection obligations appropriate to their processing.

Academyship will not sell Customer Personal Data, use Customer Personal Data for advertising, or use Customer Personal Data for general AI model training. Academyship will make compliance information reasonably available as described in section 19.

#10Customer responsibilities

Customer is responsible for lawful basis, notices, consents and parental or guardian consents where required; configuring roles, permissions and portal visibility; deciding what students and guardians can view; minimising Sensitive Information; and setting retention, export and deletion practices appropriate to Customer's obligations.

Customer is responsible for managing staff access and removing leavers; lawful use of payroll, TFN, USI and RTO features; payment and finance compliance; reviewing AI outputs before decisions; ensuring staff do not misuse notes or free-text fields; managing API keys, tokens and connected integrations; and responding to data subject requests where Customer is the controller or responsible entity.

Where Customer uses SMS, Customer controls message content, recipients, timing and any authorised sender identity, and is responsible for consent, other lawful authority, notices, opt-outs and communications-law compliance. Academyship uses AWS End User Messaging SMS for delivery; AWS may process recipient mobile numbers, message content and delivery metadata, and telecommunications carriers participate in delivery and may route messages through recipient-country networks. Academyship does not guarantee carrier delivery or exact sender-ID display. A sender identity does not alter the parties’ controller, processor, responsible-entity or service-provider roles under this DPA.

Customer remains responsible for records-management and public-sector obligations, safeguarding and duty-of-care responses outside the platform, local policies, student/family communications and ensuring its instructions to Academyship comply with Applicable Data Protection Laws.

Customer is responsible for deciding which guardians, External Participants and notification recipients receive Customer Data, for confirming their authority, and for configuring custody, safeguarding and adult-learner restrictions in the Services. A family relationship or a matching email address is not by itself proof of authority. If Customer enables public credential verification, Customer is responsible for having the authority to make the verification details in Annex I available to people who hold a valid verification link or code.

#11AI-assisted features

AI Features are available by plan and configuration, and not every AI Feature is available to every Institution. Each Customer may enable, disable or restrict AI Features through its administrative configuration and role permissions. Academyship processes the related inputs, permitted Customer Data and outputs only to provide the AI Feature on the Customer’s instructions. Academyship:

• does not use Customer Data or Student Data to train general-purpose AI models;
• uses Amazon Bedrock, identified in Annex III, as its approved AI provider for Customer Data;
• will configure Amazon Bedrock for Customer Data in the AWS Asia Pacific (Sydney) Region (ap-southeast-2), with cross-region inference disabled;
• will not send Customer Data to any other AI provider unless that provider is listed in Annex III or the Subprocessor Register and any notice required by section 18 has been given;
• requires any enabled feature to apply Tenant isolation and the requesting User's roles and permissions;
• requires authorised human review for significant decisions;
• applies feature-specific administrative controls; and
• keeps institution-specific fine-tuning or model customisation disabled unless the Customer enters a separate written opt-in agreement.

Academyship's software also contains support for other AI model providers, including a fallback path that can operate where configured. No AI provider other than Amazon Bedrock is approved to process Customer Data. Academyship will not configure that fallback path, or any other provider, to receive Customer Data unless the provider has been listed and notified as described above.

AI outputs may be incomplete or inaccurate and must be reviewed before use in any decision or official record.

The AI features Academyship currently makes available are limited to the institutional AI assistant, tenant knowledge and cross-module search, summarisation, drafting, report assistance, document analysis, administrative recommendations and action previews, together with two features that apply only where they are made available to Customer, as described in the Responsible AI Statement: drafting text for electronic-signature documents, and reviewing certificate or card templates to propose fixes. The inputs to those two features can include text, template content, related learner record context and an image of a rendered document. Academyship will describe any further AI feature in the Responsible AI Statement before making it available to Customer.

Academyship will ensure that AI Features use only the requesting User’s permitted Tenant sources. Outputs are advisory; Academyship AI does not autonomously perform an action, and an authorised person must confirm any resulting platform action. Where an AI feature proposes a change to a record or template, the change is applied only after an authorised person confirms it, and confirming a template change may cause records generated from that template to be regenerated. A person's confirmation does not make an output accurate or lawful, and Customer remains responsible for reviewing it. See the Responsible AI Statement for the public inventory.

#12Razi voice typing and student-facing generative-AI status

Razi is a browser/device voice-typing input method, not an Amazon Bedrock feature and not part of Academyship’s generative-AI feature inventory. Razi uses speech-recognition capabilities supplied by the User’s browser, operating system or device to convert spoken words into text for supported Academyship fields and editors. Academyship does not receive or store raw audio through Razi, and Amazon Bedrock is not involved in Razi.

Speech recognition for Razi cannot be assumed to take place on the User's device. Depending on the browser, operating system or device, speech may be processed on the device or sent to that provider's servers, which may be outside Australia. That provider is not appointed by Academyship and is not an Academyship Subprocessor.

Once a User inserts the resulting text into an Academyship field, that text is Customer Data and Academyship processes it in the same way as text manually entered into that field, subject to this DPA and the Customer’s instructions. The Customer and its Users are responsible for their browser/device permissions and for ensuring that use of browser/device speech recognition is authorised under the Customer’s policies and applicable law. The applicable browser or device provider may process speech under its own privacy terms and technical configuration. Users must review transcribed text before saving or relying on it. Razi does not make decisions, analyse student behaviour or generate autonomous actions. The Customer can control whether Razi is available to Users where the relevant configuration exists.

No Academyship voice or transcription feature using generative AI, and no student-facing generative-AI function, is among the AI features Academyship currently makes available or listed in Annex III. Academyship will not introduce such a feature without first describing it in the Responsible AI Statement and giving any notice required by section 18.

#13Optional integrations and APIs

Customer controls which integrations and APIs it enables. Data shared with an integration depends on the integration scope, permissions and Customer configuration. Customer is responsible for the terms, privacy practices and lawful use of third-party providers where Customer chooses or authorises the integration.

Optional institution-selected integrations are not Academyship Subprocessors unless Academyship contracts with the provider to process Customer Personal Data for the Services. Customer must protect API keys, tokens and integration credentials. Academyship may log integration activity for security, troubleshooting and audit purposes, and may suspend or disable an integration that creates a security, privacy, legal or service reliability risk.

Calendar links chosen by Users

Booking and event features can offer links that add an appointment or event to an external calendar, such as Google Calendar, Outlook or Office 365, or Yahoo Calendar, and a downloadable calendar file (ICS). When a User chooses one of these links, the selected details, such as the title, time, location or meeting link and description, are sent to the provider the User chose under that User's own arrangement with the provider. These links are not an OAuth connection or an integration that Academyship operates, and the calendar provider is not an Academyship Subprocessor. Copies created in an external calendar are outside Academyship's control and are not removed by deletion in the Services. Customer should avoid placing unnecessary private information in booking and event details that Users can export.

Payment services

Academyship uses Stripe to collect its own fees, where Academyship is the merchant. That billing information is Academyship's own business information, not Customer Personal Data processed on Customer's behalf.

If Customer uses Academyship's payment features to collect Institution Charges, the payment is processed by Stripe for Customer. The features are designed so that Customer's Stripe account, connected to Academyship's platform, is the seller of record for the underlying charge, and Stripe provides those payment services to Customer under the terms that apply to Customer's Stripe account. Available payment methods, for example card or PayTo, depend on Customer's configuration. Academyship processes payer, payment, mandate, refund and dispute records in the Services on Customer's instructions, and exchanges with Stripe the information needed to initiate and record each payment. Card details entered in a Stripe-hosted payment page or field are collected by Stripe.

Stripe's role differs by function and is governed by Stripe's terms. For some functions, such as fraud prevention, identity verification and financial-services compliance, Stripe determines its own purposes. Stripe is not listed as an Academyship Subprocessor for the functions described in this section, and the Subprocessor Register explains the classification of each function. If Academyship engages Stripe to process Customer Personal Data on Academyship's behalf for another function, Academyship will apply section 18 to that engagement.

#14Support and personnel access

Academyship will restrict support and engineering access to Customer Personal Data by role, log that access, and limit it to support, security, debugging, legal compliance or service operation. Access may be tied to a ticket, incident or approved task where practical.

Academyship will bind its personnel by confidentiality, remove access when it is no longer needed and review access periodically. Remote access from outside Australia remains subject to APP 8 safeguards or equivalent controls where applicable.

Files, screenshots, exports and other copies of Customer Data provided for a support case are used only for that case and are deleted in accordance with section 20. Academyship will not ask Customer or its Users to send passwords, full TFNs or full payment card details for support.

#15Security measures

Academyship will implement and maintain the technical and organisational security measures set out in Annex II, Part A. Those measures form part of this DPA and apply to production Customer Data. Annex II, Part B describes the platform and Academyship's assurance position for information; it does not reduce Part A. Academyship may update the measures as technology and risk evolve, provided that the overall level of protection is not materially reduced during the Customer's subscription. Security is a shared responsibility: Academyship secures the platform and managed infrastructure, while the Customer is responsible for its Users, credentials, configuration, role assignments and Institution-selected Integrations.

Academyship will keep records sufficient to show how it meets Annex II, Part A, and will make information about them available as described in section 19. If Academyship identifies a material gap between its operations and a Part A measure, it will remediate the gap without undue delay, and will tell affected Customers where the gap has resulted in a Security Incident or materially increases the risk to their Customer Data.

Academyship does not claim its own SOC 2, ISO 27001 or equivalent certification unless and until those certifications are obtained and stated in official materials.

#16Assisting with rights, DPIAs and regulator requests

Academyship will provide reasonable assistance to Customer through self-service tools, exports, correction tools, deletion tools, logs and support where reasonable and technically feasible. If Academyship receives a direct request about Customer Personal Data, it will refer the requester to Customer unless legally required to respond otherwise.

Customer remains responsible for responding to individuals as controller or responsible entity. Assistance is subject to authentication, technical feasibility, lawful retention, confidentiality and the scope of the Services.

Academyship will provide reasonable information to help Customer with DPIAs, PIAs, public-sector privacy assessments, security questionnaires and regulator enquiries. Assistance is subject to confidentiality, scope, reasonable frequency, available information and fees for excessive or custom requests where permitted by agreement. Academyship will not provide information that compromises security or other customers.

Academyship will not charge individuals for making a privacy request. It will not charge Customer for assistance needed because of Academyship's own breach of this DPA, and it will agree any other charge for custom or excessive assistance with Customer before the work starts. Nothing in this section limits what Academyship must provide to a regulator or court, or any right of an individual that cannot be limited by contract.

#17Personal data breach notification

Academyship will maintain a documented incident-response and data-breach process. Where a Personal Data Breach affects Customer Data, Academyship will notify the affected Customer without undue delay and no later than 72 hours after Academyship becomes aware that Customer Data has been affected, unless the information available at that time does not reasonably permit identification of the affected Customer. Academyship may provide information in stages as the investigation progresses.

The notice will include, to the extent reasonably available:

• the nature of the incident;
• the categories of information and data subjects affected;
• the likely consequences;
• the containment and remediation actions taken or proposed;
• recommended actions for the Customer; and
• an Academyship contact for further information.

Each party remains responsible for its own statutory assessment and notification obligations. Where both parties hold affected personal information, the parties will coordinate promptly and agree which party will lead communications with affected individuals and regulators. Unless otherwise agreed or required by law, the Customer will ordinarily lead communications concerning its data subjects, with Academyship providing reasonable assistance.

An agreement about who leads communications is coordination only. It does not allow either party to prevent or delay a notification that the other party is required by law to make. Where practicable and lawful, a party making a legally required notification will tell the other party beforehand.

Nothing in this DPA prevents Academyship from notifying a regulator, affected person or other party where Academyship is independently required or permitted to do so by law. Customer must notify Academyship promptly if Customer becomes aware of security issues caused by its users, integrations, credentials, devices, configurations or third-party providers.

Relationship with the Notifiable Data Breaches scheme

The 72-hour notice in this section is a contractual commitment to Customer. It is separate from the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988 (Cth), and from other breach-notification laws, which each party must comply with to the extent they apply to it. Under that scheme, an entity that suspects an eligible data breach must take reasonable steps to complete an assessment expeditiously and within 30 days, and must notify the Office of the Australian Information Commissioner and affected individuals as soon as practicable once it has reasonable grounds to believe an eligible data breach has occurred. The 30-day assessment period does not permit either party to delay containment or the notice owed to Customer under this section. Where both parties hold the affected information, the law may allow one party's assessment or notification to satisfy both parties' obligations, and the parties will confirm in writing which party will do so.

#18Subprocessors

Customer gives general authorisation for Academyship to engage the active approved Subprocessors listed in Annex III, and new or replacement Subprocessors added in accordance with this section. Academyship will impose data-protection obligations on each Subprocessor appropriate to its processing and remains responsible to Customer for Subprocessors engaged by Academyship.

Notice of new or replacement Subprocessors

Academyship will give Customer written notice of a new or replacement Subprocessor that will process Customer Data at least 30 days before that Subprocessor begins processing Customer Data, except in the emergency case described below. Academyship will send the notice by email to Customer's account contacts, or to a privacy or security contact Customer nominates, and will record the change in the Subprocessor Register. Customer does not need to subscribe to or request these notices. Each notice will identify the provider's legal entity, the service, the purpose, the categories of data and data subjects, the processing locations and the proposed effective date.

Objections and emergency replacements

Customer may object in writing on reasonable data-protection grounds within 30 days after receiving a notice. The parties will discuss the objection in good faith, and Academyship may propose a reasonable alternative, such as a configuration change or providing the affected Services without the new Subprocessor. If the parties cannot resolve an objection, Customer may terminate the affected Services according to the Terms or this DPA.

Emergency replacement Subprocessors may be used where needed for security, continuity or legal reasons, but will be limited to the affected service and notified as soon as reasonably practicable. Customer's 30-day objection period for an emergency replacement runs from that notice.

Annex III and the Subprocessor Register

Annex III is the Subprocessor snapshot at the effective date of this version of the DPA. Changes made under this section after that date are recorded in the Subprocessor Register, which keeps the effective date of each entry and a change history. Only providers shown as Active in Annex III, as updated through the Subprocessor Register under this section, are authorised to process Customer Data under this DPA. At the effective date of this version, no AI provider other than Amazon Bedrock, and no provider that would lodge Single Touch Payroll reports, is authorised.

Other people can ask to be told of updates to the Subprocessor Register by contacting legal@academyship.com.au. Those updates are in addition to, and do not replace, the notices due to Customer under this section.

Optional Customer-selected integrations are not Academyship Subprocessors unless Academyship contracts with the provider to process Customer Personal Data for the Services.

#19Audits and compliance

Academyship will make information reasonably necessary to demonstrate compliance with this DPA available to Customer. Customers may review Academyship security documentation, this DPA, the Privacy Policy, Trust & Security page, security questionnaire responses and relevant infrastructure-provider reports where available.

AWS compliance reports may be referenced as AWS infrastructure-provider reports, not Academyship certifications. Academyship does not represent AWS reports as Academyship SOC 2, ISO 27001 or similar certification.

Customer audit rights are subject to reasonable notice, confidentiality, scope, security controls, no disruption to Academyship or other customers, no access to other customers' data, and no more than annually unless following a material breach or regulator requirement. Academyship may satisfy audit requests through independent reports, questionnaires or documentation where sufficient.

Any Customer-led audit must be conducted by Customer personnel or an independent auditor bound by confidentiality and appropriate security obligations. Customer is responsible for its own audit costs unless otherwise agreed.

Academyship is not required to provide access to source code, production systems, other customers' data, highly sensitive security details or information that would increase security risk.

Nothing in this section limits the powers of a regulator or other authority with jurisdiction over either party, or any right of Customer or an individual that cannot be limited by contract. The annual limit and the restrictions above do not prevent Academyship from giving a regulator, court or other authority what the law requires. Where a regulator requires Customer to provide information about Academyship's processing of Customer Data, Academyship will give Customer reasonable assistance to respond.

#20Return and deletion

During the subscription, the Customer can export Customer Data through Academyship's authorised export functions. Following termination, Academyship will make Customer Data available for authorised export for at least 60 days unless a different period is agreed in an Order Form or required by law. During that period, access may be restricted to export and transition functions.

Supported export scope

The supported export scope is:

• structured records that each Module's export functions provide, in the formats those functions offer, such as CSV or PDF;
• uploaded files and generated documents, such as certificates, letters and completed signed documents, that the Services allow authorised Users to download; and
• electronic-signature evidence, audit records and reports, where the relevant Module provides them for export or download.

A Module's export functions cover the records that Module makes available for export. A single package containing every record, attachment, relationship and history, a data dictionary, and migration to another system are not part of the standard export. If Customer needs Customer Data that the export functions do not cover in order to meet a legal obligation, Academyship will provide reasonable assistance to extract it in a commonly used format during the export period. Other transition assistance can be agreed in writing as described in the Terms. Academyship will not withhold an otherwise available export solely because of a good-faith billing dispute, as provided in the Terms.

Generated download links expire. Expiry of a link ends access through that link; it does not delete the export file or the underlying records, and a new export can be generated while export access remains available.

Deletion after the export period

After the export period, Academyship will delete Customer Data from active systems in the ordinary course and will cause backup copies to expire through the documented backup lifecycle: daily backups, 30 daily recovery points, 15 weekly recovery points and 7 monthly recovery points. This remains subject to legal holds and legal retention requirements. On written request, Academyship will provide confirmation of deletion. A specific certified-deletion process or shorter timeframe may be agreed in an Order Form.

Deletion covers Customer Data held by Academyship or on its behalf, where it exists, in:

• Tenant databases and their replicas;
• uploaded and generated files, including drafts, previews and other derived files, generated certificates, cards and letters, and stored versions of those files;
• search indexes and AI-related indexes;
• caches;
• queued, failed or retried job records that contain Customer Data;
• copies made for a support case; and
• copies held by Subprocessors for the Services, through each Subprocessor's deletion processes.

Archiving, deactivating or soft-deleting a record within a Module is not deletion.

Exceptions, backups and restoration

Academyship may keep Customer Data after the export period only:

• in backups, until they expire through the backup lifecycle;
• where a legal hold applies or the law requires Academyship to keep it;
• where needed to investigate a Security Incident or to establish, exercise or defend a legal claim, limited to the data needed for that purpose; or
• as Aggregated or De-identified Data.

Customer Data kept under an exception remains protected by this DPA and is used only for the purpose for which it is kept. Backup expiry is not deletion from active systems: deleted Customer Data can remain in a backup until that backup expires. If Academyship restores Customer Data from a backup, it will re-apply the deletions made after that backup was taken, including deletions made by Customer and deletions required by this section, so that a restore does not return deleted Customer Data to use.

Copies that Customer or its Users have exported, downloaded, emailed or added to an external calendar, messages already delivered to recipients, and copies held by Customer-selected Integrations or by providers acting for their own purposes, such as Stripe, are outside Academyship's deletion control. This does not limit Academyship's obligation to delete the copies it controls.

Log and record types

Different records have different retention positions. The 30-day period applies only to the infrastructure and security logs and AI usage, security and audit events described below. On request, Academyship will tell Customer the retention period that currently applies to any record type in this table.

If an account is suspended, terminated for non-payment or trial access expires, export and deletion rights follow the Terms, Order Form and applicable law.

#21International transfers

Academyship hosts its core production platform and Customer Data in Sydney, Australia (ap-southeast-2). Limited processing outside Australia may occur through disclosed telecommunications delivery, Stripe-hosted payment services, Customer-selected Integrations or authorised access, subject to applicable privacy, contractual and security safeguards.

Hosting Customer Data in Sydney does not mean that all information stays in Australia. In addition to the routes above, information may be handled outside Australia by the browser, operating-system or device provider that supplies speech recognition for Razi (section 12) and by external calendar providers a User chooses (section 13).

Customer-selected Integrations transfer data according to Customer configuration and third-party terms.

Where Academyship discloses personal information outside Australia through a Customer-selected Integration or another disclosed recipient, APP 8 safeguards apply. This public DPA does not include or execute Standard Contractual Clauses, the UK International Data Transfer Agreement (IDTA) or the UK Addendum, and it is not by itself a complete transfer instrument under EU or UK law. EU/UK GDPR transfers use those transfer terms only where they are agreed and executed in an Order Form or regional addendum.

#22Legal requests

Academyship will notify Customer of legal, regulatory or law-enforcement requests for Customer Personal Data unless prohibited by law or the request's terms. Where appropriate, Academyship may challenge, narrow or redirect requests. Customer is responsible for responding to requests directed to Customer.

#23Government and public-sector Institutions

Public-sector customers may require additional privacy, security, data residency, records-management or departmental-policy terms through Order Forms, security schedules or procurement documents. Academyship supports those requirements through agreed contractual schedules, security documentation, access controls, audit logs and data-residency commitments where agreed.

Customer remains responsible for records management, notices, consents, local policies, student and family communications and public-sector obligations that apply to Customer.

#24Safeguarding and emergency-response limitation

Academyship may store wellbeing, behaviour, support or safety records where Customer configures those modules. Academyship is not an emergency response, safeguarding monitoring or clinical service. Automated notifications, including behaviour-threshold alerts, depend on Customer's configuration and on message delivery, and are not an emergency or safeguarding alert system.

Customer is responsible for reviewing records and responding under its duty-of-care, safeguarding, mandatory reporting, emergency and escalation procedures. Nothing in the Services replaces Customer's mandatory reporting, child-safety, wellbeing, clinical, emergency or legal obligations.

#25Liability, governing law and acceptance

Each party's liability under this DPA remains subject to the limitations and exclusions of liability in the Terms of Service, unless a signed agreement says otherwise. Nothing in this DPA limits rights or obligations that cannot be limited under applicable law.

This DPA is governed by the laws of New South Wales, Australia, and otherwise forms part of, and is subject to, the Terms.

This DPA takes effect through the Customer's acceptance of the Terms or an Order Form that incorporates it, and does not require separate signature. Enterprise and public-sector customers that require a countersigned copy may request one from legal@academyship.com.au.

#26Versions of this DPA

Academyship keeps a copy of each version of this DPA, including its Annexes, and of each version of the Subprocessor Register. Customer can obtain the version that applied to it on a particular date from legal@academyship.com.au. A new version of this DPA applies to an existing Customer only in accordance with the change provisions of the Terms, and does not apply retrospectively.

#A1Annex I — Processing details

Annex I has two parts: general processing details, and a schedule for each Module. A Module's entry applies only when Customer uses that Module.

Module schedule

This schedule describes the processing for each Module when Customer uses it. Listing a Module does not mean it is available to every Customer.

#A2Annex II — Technical and organisational measures

Annex II has two parts. Part A sets out the technical and organisational measures that Academyship commits to implement and maintain for production Customer Data; it forms part of this DPA. Part B describes the platform and Academyship's assurance position for information; it is not an additional warranty and does not reduce Part A. Both parts are stated at a control level and intentionally omit sensitive implementation details.

Part A — Security measures Academyship commits to

Part B — Platform description and assurance (for information)

These control statements omit sensitive implementation details and do not assert that Academyship holds SOC 2, ISO 27001 or similar certification.

#A3Annex III — Subprocessors

Annex III records the contractual subprocessor snapshot applicable to this DPA, as at the effective date of this version. It lists the same Active Subprocessors as version 2.0 of the Subprocessor Register. Changes after that date are made under section 18 and recorded in the current public register on the Subprocessor Register page. Academyship will give Customer written notice of a new or replacement subprocessor that will process Customer Data, and Customer may object, as described in section 18. Customer receives those notices without needing to request them. Other people can ask to be told of register updates by contacting legal@academyship.com.au.

For Academyship's Australian AWS account, the AWS Customer Agreement identifies Amazon Web Services Australia Pty Ltd (ABN 63 605 345 891) as the AWS contracting party. SMS messages are handed to telecommunications carriers for delivery and may be routed through carrier networks in the recipient's country. Customer Personal Data is not used to train general-purpose AI models. Academyship configures Amazon Bedrock for Customer Data in Sydney, Australia (ap-southeast-2), with cross-region inference disabled, and Amazon Bedrock is the only AI provider authorised under this DPA at the effective date of this version.

Providers not listed as Subprocessors

The following are not Academyship Subprocessors under this DPA: Stripe, for the payment functions described in section 13; telecommunications carriers that deliver SMS; browser, operating-system or device providers that supply speech recognition for Razi (section 12); calendar providers a User chooses through a calendar link (section 13); and Customer-selected Integrations. No AI provider other than Amazon Bedrock, and no provider that would lodge Single Touch Payroll reports, is authorised under this Annex. The Subprocessor Register explains these classifications.

For questions about this DPA or the subprocessor list, contact legal@academyship.com.au. See also the Privacy Policy, Cookie Policy and Terms of Service.