Privacy Policy

#01Privacy snapshot and scope

ACADEMYSHIP PTY LTD (ACN 698 283 448, ABN 89 698 283 448) ("Academyship", "we", "us", "our") provides ACADEMYSHIP, a multi-tenant education and institution management platform for universities, colleges, registered training organisations, schools and training organisations. Modules are available by plan and configuration, and not every module is available to, or used by, every institution. This Privacy Policy explains how we handle personal information in accordance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs).

Academyship is sold to institutions and organisations, not to individual students or parents. Most information in the platform belongs to, and is controlled by, the institution that operates the workspace. This policy covers the ACADEMYSHIP web application, the student and guardian portals, our APIs, generated documents, and our marketing website at academyship.com.au (including its enquiry, signup, partner and program-application forms).

#02Who we are and how to contact us

Academyship is the entity responsible for the personal information described in this policy, except where an institution is the responsible entity for the records in its own workspace (see section 3). You can contact us at:

If a specialised address is not the right fit for your enquiry, you may use team@academyship.com.au and we will route it appropriately.

#03Our privacy roles

Academyship handles personal information in two distinct ways, and it is important to understand the difference.

Information we handle for institutions (institution-controlled data). When an institution uses Academyship, it decides what information goes into its workspace, who may access it, the purposes for which it is used, and how long it is kept. For that information, the institution is the entity that determines the purposes and means of handling, and Academyship acts on the institution's documented instructions to provide the service. Our handling of that information is also governed by our Data Processing Addendum (DPA).

Information we handle for our own business. Separately, Academyship handles limited personal information as the responsible entity in its own right — for example, business-contact details of the people who enquire, sign up, administer accounts, are billed, raise support tickets, or apply to our partner and program pathways; and information we generate for security, fraud prevention, billing, legal compliance, measuring the use of our public website (see section 16) and improving our service. For that information, Academyship decides the purposes and means.

An Institution may use Academyship’s optional white-label or branding features to display its own name, logo, colours or approved service identity. This branding does not change the Institution’s responsibility for its records, Academyship’s role in providing and processing information through the platform, or the rights described in this Privacy Policy. Users should read both the Institution’s privacy information and Academyship’s applicable privacy information.

Academyship complies with the Privacy Act 1988 (Cth) and the Australian Privacy Principles to the extent they apply to Academyship. Each Institution must comply with the privacy, education, public-records, health-records and other data-protection laws applicable to it. Government and public-sector Institutions may be subject to state or territory privacy and records legislation instead of, or in addition to, the federal Privacy Act. Where this policy or our contracts use the international terms "controller" and "processor", those terms are practical shorthand only and do not displace the Australian legal framework applicable to either party. A contractual label does not remove any obligation that Australian privacy law places directly on Academyship, and Academyship's obligations are assessed under that framework.

Employee records handled for an employer

Where an Institution uses payroll, HR or timesheet features, the Institution is the employer. In some circumstances an employer's handling of its own employee records is exempt from the Privacy Act. That exemption belongs to the employer. Academyship does not rely on it for Academyship's own handling of those records, which is covered by this policy and the DPA. Staff of an Institution can therefore contact Academyship about Academyship's handling of their information, as well as contacting their employer.

#04Who this policy covers

This policy covers everyone whose personal information we may handle, including: institutional administrators and account owners; staff, teachers, trainers and assessors; students and applicants; parents, guardians and emergency contacts; employees and contractors of institutions (including where payroll or HR features are used); alumni and former users; partners and referrers; and visitors to our marketing website. Depending on the modules an institution uses, it also covers people who visit an institution's premises, make an enquiry, call or complaint to an institution, book an appointment or respond to an event, borrow from a library, sign or review a document, pay an amount charged by an institution, or check a credential using a verification link.

Because student, parent and other end-user accounts are created, invited or authorised by an institution, individuals should also read the privacy notice or policy provided by their own institution, which governs how that institution uses Academyship.

#05Information we handle

The categories below describe information that may be handled through the platform. The actual information present in any workspace depends on the modules an institution enables and the fields it chooses to use.

• Identity and contact information — names, dates of birth, student or staff identifiers assigned by the institution, email addresses, phone numbers, postal addresses and emergency-contact details.
• Enrolment and academic information — applications, enrolments, courses, classes, attendance, timetables, assessment results, progress, certification and academic history.
• Behaviour, wellbeing and support information — where an institution enables these modules: behaviour records, wellbeing notes, pastoral care, and support or adjustment records.
• Sensitive information — where an institution chooses to record it: health information, disability and adjustment needs, medical or dietary needs, and other information that is "sensitive information" under the Privacy Act. See section 12.
• Employment, payroll and finance information — where HR, timesheet, payroll or finance features are used: employment details, pay and leave information, tax and superannuation details, bank details, fees, invoices and payment status. Payroll features support an employer's own payroll processes. Academyship is not the employer, a registered tax or BAS agent, or endorsed by the Australian Taxation Office, and preparing payroll information in Academyship does not by itself report it to any authority. See sections 13 and 17 and our DPA.
• Payment information — where Academyship's own fees are paid, or an institution uses payment features to collect amounts it charges: payer details, transaction records and the payment information described in section 17.
• Records from other modules — where an institution uses them: canteen, library, front-office and visitor, homework, events, bookings, electronic-signature, credential, and portal access records. The table later in this section describes each one.
• Communications and content — messages, notices, uploaded documents and files, form responses, and content created within the platform.
• Voice-input text — where a User uses Razi voice typing, the resulting text after it is inserted into a supported Academyship field or editor. Academyship does not receive or store raw audio through Razi.
• Support information — the details of enquiries, tickets and correspondence with our team.
• Technical and usage information — information generated automatically when the service is used, such as log records, IP address, device and browser information, and audit records of key actions. See sections 16 and 21.
• AI-feature information — where AI-assisted features are enabled: the prompts, inputs and generated outputs associated with those features. See section 15.

Razi voice typing

Razi converts spoken words into text for entry into supported Academyship fields and editors. Speech recognition is provided by the User’s browser, operating system or device; the provider may process speech under its own privacy terms and technical configuration. Academyship does not receive or store raw audio through Razi. Academyship receives and handles only the resulting text after it is inserted into an Academyship field, in the same way as text manually entered into that field. Availability and accuracy depend on the User’s browser, device, language, permissions and network conditions, and Users must review the transcription before saving or relying on it. Razi does not make decisions, analyse student behaviour or generate autonomous actions. An Institution can control whether Razi is available to Users where the relevant configuration exists.

Information handled by module

The table below explains how information is handled in common modules. Each row applies only if the Institution uses that module and the fields described. The Institution decides which modules it uses, which fields are required, who can see each record and how long records are kept. Its own privacy policy or collection notice explains its purposes in more detail. "Section 26" in the last column refers to the retention rules for the type of record named there.

#06Mandatory and optional information

On forms that Academyship itself controls (for example, website enquiry and signup forms), required fields are visibly marked. If required information is not provided on those forms, we may be unable to set up an account, respond to an enquiry, or provide part of the service.

Within an institution's workspace, the institution decides which fields are required for its own processes. Where a field is optional and left blank, the related feature may simply not be available for that record. Institutions are responsible for configuring their forms and fields lawfully and for telling their own users which information is required and why. Section 12 explains, for sensitive collections, why the information may be needed and what can happen if it is not provided.

#07How we collect information

We collect information in the following ways:

• Directly from you — when you enquire, sign up, administer an account, contact support, or apply to a partner or program pathway.
• From institutions — when an institution enters, imports or uploads records into its workspace, or invites users.
• From authorised users — when staff, students or guardians use the platform and its portals.
• From integrations selected by an institution — where an institution connects an approved third-party service (see section 20).
• From other people — for example, when a staff member records an incident or a visit, a guardian books an appointment for a student, or someone makes a complaint that mentions you.
• From payment providers — when Stripe returns information about a payment, refund, dispute or payment agreement (see section 17).
• Automatically — through the normal operation of the service, including logs, session and security records, and audit trails, and through measurement of visits to our public website (see section 16).

Where it is reasonable and practicable, we collect personal information about an individual from that individual. In the education context, however, much information is collected from the institution or from authorised users acting on the institution's behalf.

#08Why we use information

We use institution-controlled data only to provide, secure, support and maintain the service on the institution's instructions, to meet our legal obligations, and as otherwise permitted by the Terms and DPA.

We use the business information we handle in our own right to: create and administer accounts; communicate with customers about the service; process billing and payments; provide support; protect the security and integrity of the platform; detect and prevent fraud or misuse; comply with law; measure how our public website is used; and improve and develop our products and services using appropriate safeguards. We do not use student data for advertising, do not sell personal information, and do not use customer or student data to train general-purpose AI models.

These commitments describe Academyship's own use of information. A payment provider such as Stripe also processes payment information for its own legal and operational purposes, such as fraud prevention and financial-crime compliance, under its own terms (see section 17).

#09Consent and dealing with us anonymously

Where the Privacy Act requires consent — for example, to collect sensitive information — that consent is generally obtained and managed by the institution as part of its enrolment and record-keeping processes, because the institution controls those records and its relationship with the individual. Where Academyship collects information directly for its own purposes, we rely on consent or another lawful basis as appropriate.

This Privacy Policy is a notice, not a consent form. Reading it, or confirming that you have read it, is not consent to any optional use of your information. Where Academyship or an Institution needs your consent, for example for an optional feature, for sensitive information that requires consent, or for marketing, it is asked for separately and specifically for that purpose.

You may deal with us anonymously or by pseudonym where it is lawful and practicable — for example, when making a general enquiry. This is usually not practicable for account administration, billing, support that requires identity verification, or use of an institution's workspace, where identification is necessary to provide the service.

#10Collection notices

At or before the point we collect personal information through our own forms, we provide a collection notice or link to this policy so you understand who is collecting the information, why, and how to contact us. Institutions are responsible for providing their own collection notices to their students, staff and guardians for information collected within their workspace.

Where an Institution decides to disclose information, for example to a regulator, a guardian or a provider it has chosen, the Institution's own privacy policy and collection notice explain that disclosure. If you are not sure which notice applies to you, ask the Institution, or contact us and we will help you find the right contact.

#11Children and student information

Academyship is built for institutional use and does not contract directly with minors through ordinary use of the platform. Student and guardian accounts are created, invited or authorised by the institution, which is responsible for obtaining any consents required under its own policies and applicable law, and for managing student access and meeting its educational, safeguarding and duty-of-care responsibilities where applicable.

We handle student information (including information about children) on the institution's instructions and protect it with the safeguards described in this policy and our DPA. Requests concerning a student's information are generally directed to and handled by the institution that controls the record (see section 27).

A linked guardian sees only what the Institution has authorised for that relationship. A family relationship or a matching email address is not, on its own, proof of authority to see a record or to receive a notification. Adult learners have their own privacy rights, and custody, court-order and safeguarding restrictions can limit what a guardian may see.

#12Data minimisation and sensitive fields

Academyship provides role-based permissions and field-level configuration tools that allow Institutions to restrict access to sensitive information. Institutions must enable sensitive fields only where necessary, assign access only to authorised roles and regularly review those permissions.

The institution remains responsible for deciding what information it collects in its workspace and for configuring sensitive fields appropriately.

Sensitive collections explained

Some modules can hold information that is sensitive, or that needs particular care, if the Institution chooses to collect it. The table below explains why such information may be needed, what authority is involved, who should see it and what can happen if it is not provided. The Institution makes these decisions for its own records and should explain them in its own collection notice. If you want to know why an Institution needs a particular item, ask the Institution. You can also contact us.

#13Government identifiers

Regulated Identifiers — such as the Unique Student Identifier (USI), a state student number (for example, a VSN), passport numbers, visa details and tax file numbers (TFNs) — may be recorded where an institution's processes and legal obligations require it. They are not classified as Sensitive Information solely because they are Regulated Identifiers.

Academyship does not use government identifiers as its own internal primary identifier for records. Internal records are keyed to identifiers that Academyship or the institution assigns. Government identifiers are handled in accordance with applicable law, including the specific protections that apply to TFNs, and access is controlled through roles and permissions.

Three identifiers that are easy to confuse

The abbreviation "USI" is used for two different identifiers, and both are different from a tax file number. Academyship treats them as separate identifiers.

#14Photos, image metadata and location

Device location. Academyship does not collect precise device geolocation as part of ordinary platform use. Where an Institution enables a specific feature that requires location information, Academyship displays an appropriate notice and the Institution is responsible for establishing the lawful authority and any required consent.

Uploaded images and metadata. Academyship removes embedded GPS location metadata from supported uploaded image formats while preserving orientation information required to display the image correctly. Institutions remain responsible for obtaining any consent required to collect, store or publish images.

#15AI-assisted features

AI Features are available by plan and configuration, and not every AI Feature is available to every Institution. Each Institution may enable, disable or restrict AI Features through its administrative configuration and role permissions. Academyship processes information for an AI Feature only to provide that feature within the Institution’s workspace. The following conditions apply:

• Academyship does not sell the information involved and does not use it for advertising;
• Academyship does not use Customer Data or Student Data to train general-purpose AI models;
• AI processing is restricted to the relevant Institution's Tenant and is subject to the requesting User's roles and permissions;
• Academyship's approved AI provider for Customer Data is Amazon Bedrock, which Academyship configures in the AWS Asia Pacific (Sydney) Region (ap-southeast-2) with cross-region inference disabled. Academyship's software also contains support for other model providers, including a fallback path that can operate where configured. No other AI provider is approved to process Customer Data unless it is listed in the Subprocessor Register and any notice required by the DPA has been given;
• AI outputs are suggestions and may be incomplete or inaccurate; and
• significant educational, disciplinary, admission, employment, financial or wellbeing decisions must be reviewed and made by an authorised person and must not be based solely on an AI output.

The AI features Academyship currently makes available cover the institutional AI assistant, tenant knowledge and cross-module search, summarisation, drafting, report assistance, document analysis, administrative recommendations and human-confirmed action previews. These features use only the requesting User’s authorised Tenant sources and produce an answer, summary, proposed text, analysis, recommendation or preview for authorised human review. They do not autonomously perform an action. Where they are made available to an Institution, AI features can also help compose documents for electronic signature and propose fixes to certificate or card templates. A proposed template fix is applied only when an authorised person confirms it, and confirming it may regenerate the affected certificates or cards. AI does not change records without a person's confirmation where that confirmation step applies. A person's confirmation does not guarantee that the output is accurate or suitable, so the Institution remains responsible for checking it. No Academyship voice or transcription feature using generative AI, or student-facing generative-AI function, is represented in the current public inventory. Razi voice typing is separate browser/device speech recognition, not an Amazon Bedrock feature or an AI-inventory entry. The detailed role, source, output, action and logging position is in the Responsible AI Statement.

AI Features include Institution controls and role-permission implementation appropriate to the feature. Any institution-specific model customisation or fine-tuning using Customer Data requires a separate written agreement and explicit opt-in and is disabled by default.

#16Cookies, browser storage and third-party services

Marketing website technologies

Academyship's review of its production homepage, pricing page and login page, and the scripts those pages loaded, published in September 2026, identified no analytics technology, advertising pixel, session-replay technology or support-chat widget. Academyship has since added its own first-party measurement of visits to its public website, described below. Academyship does not use Student Data for advertising.

In that review, the production homepage automatically loaded Google Fonts (Bricolage Grotesque, Manrope and Urbanist) and Google Maps JavaScript API with Places Autocomplete, and the production /login page automatically loaded Google Fonts (Inter). Public pages change over time, and some other public pages load fonts from Google or video images from YouTube. These services receive standard technical request information, such as IP address and browser headers. When a visitor uses homepage address autocomplete, the typed address query and selected address are sent to Google to provide that function. Google Fonts do not receive sign-in form entries merely by loading the font. The Cookie Policy contains the detailed Google-service disclosure and the current scope of the browser-storage inventory.

Academyship uses the first-party laravel_session and XSRF-TOKEN cookies for sessions and CSRF protection. The public website code uses hpScrollY and academyship_signup_source in sessionStorage for functional homepage behaviour and sign-up source attribution. The login page offers optional, 30-day remembered-username items: acsh.remember.staff, acsh.remember.student and acsh.remember.sub. These items are described in the Cookie Policy; they do not contain passwords, authentication credentials, TFNs or full payment-card details.

Academyship uses Stripe for subscription-payment processing. Where a visitor or Institution proceeds to Stripe Checkout, payment-card details are entered on Stripe’s hosted service rather than in Academyship browser storage. For the inventory, attributes, durations, affected pages and browser controls, see the Cookie Policy.

Website measurement

Academyship measures visits to its public website pages, other than its sign-in pages, using its own first-party script. The script stores random identifiers in a first-party cookie and in browser storage so that visits and returning browsers can be counted. It records which pages are viewed, where a visit came from (including campaign labels in the link), general device and browser characteristics, use of the links and buttons Academyship has chosen to measure, downloads and links followed to other websites, how far a page is scrolled, active time on a page, page loading performance and technical errors, and whether a form was started, failed or completed. It does not record what you type into a form. The information is sent only to Academyship's own measurement service. That service also receives your IP address and browser details with each request and may use them to estimate approximate location and device type and to filter out automated traffic. Academyship uses this information to understand and improve its website. It is not used for advertising and is not shared with advertisers or third-party analytics providers.

The Privacy Choices panel does not currently switch this measurement on or off. You can exclude your browser at any time as explained in the Cookie Policy, which also lists the cookie and storage items involved.

Application and portals

The Academyship application and portals also use browser storage, depending on the modules an Institution uses. This can include interface preferences, such as table columns, filters, tabs, theme and sidebar settings; a selected campus or branch; short-lived handoffs between the steps of a multi-step form, which can briefly hold details you entered, such as an email address, in session storage until the next step; and display preferences and drafts on payment screens. Session storage is not always cleared when a tab is closed, because browsers can restore tabs, and local storage remains until it is cleared, so take care on shared devices. The Privacy Choices panel on Academyship's website may not govern storage on Institution or tenant domains, or on pages hosted by other providers. See section 06 of the Cookie Policy.

#17Payment information

Academyship uses Stripe for two different kinds of payment, and the parties are different in each.

Academyship's own fees

Academyship uses Stripe Payments Australia Pty Ltd (A.C.N. 160 180 343) to collect its own fees, such as subscription charges. For those payments, Academyship is the merchant. Visitors who select card payment in the homepage sign-up flow are redirected to Stripe Checkout. Payment-card details are entered on the hosted Stripe Checkout page, not in the Academyship homepage. In Academyship's review of its public pages published in September 2026, the homepage did not load Stripe payment code before that visitor-initiated redirect, and no Stripe cookie or browser-storage key was observed on Academyship’s public pages before it. Stripe controls browser processing on its hosted domain.

Payments to an Institution

If an Institution uses Academyship's payment features to collect amounts it charges, such as tuition fees, instalments, canteen purchases or library fines ("Institution Charges"), the payment is processed by Stripe for the Institution. The features are designed so that the Institution's Stripe account, connected to Academyship's platform, is the seller of record for the underlying charge. The payment methods available, for example card or PayTo, depend on the Institution's configuration. Paying an Institution Charge does not make you a customer of Academyship's software. Questions about the amount charged, a refund or a payment plan should go to the Institution first.

The Payments and Wallets page explains these payments, PayTo agreements, wallets and refunds in more detail, including a guide for payers.

If an Institution offers PayTo and you set up a payment agreement, you approve it through your own bank. Academyship's records can then include the agreement's identifier, its status and the terms you approved, such as the purpose, amount or limit and frequency.

What Academyship receives and keeps

For both kinds of payment, Academyship's records can include:

• the payer's name and contact details and, where the Institution records it, the student or account the payment relates to;
• invoices, receipts and transaction history, including the amount, currency, date, purpose and status of each payment (for example, pending, successful, failed, refunded or disputed);
• identifiers that Stripe returns for the customer, payment, refund, dispute or payment agreement;
• refund and dispute information; and
• masked payment details where Stripe provides them, such as a card brand and the last four digits, or a partly hidden bank account number.

We use this information to show payment status, issue receipts, reconcile payments, process refunds, respond to disputes, prevent fraud and meet legal obligations. For Institution Charges, the Institution's authorised finance staff can see the payment records for its own charges.

Card and bank details

When you enter card details on Stripe's hosted checkout, you enter them on Stripe's service, not on an Academyship page. Do not send full card numbers, card security codes, banking passwords or one-time banking codes to Academyship or an Institution by email, chat or support ticket. Academyship will not ask for them that way.

Stripe's own role

Stripe handles payment information under its own terms and privacy policy. Its role differs by function. For some functions it provides a service to Academyship or the Institution. For others, such as fraud prevention, identity verification and meeting its financial-services obligations, it acts on its own account. Stripe Payments Australia Pty Ltd processes information in Australia, and Stripe's international processing operations may also involve other countries, including the United States and India, as described in Stripe's privacy policy. See the Stripe Privacy Policy for Stripe’s handling of information and browser technologies on its hosted service.

#18Data hosting and residency

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.

Institution-selected Integrations are controlled by the Institution and are subject to the provider's own terms and privacy practices.

Where personal information is disclosed outside Australia through a Customer-selected Integration or another disclosed recipient, Academyship takes reasonable steps required by applicable law to ensure that the recipient handles it consistently with applicable privacy protections.

Where information may be handled

Hosting Customer Data in Sydney does not mean that every part of every service takes place in Australia. The table below separates storage from other kinds of handling. Academyship does not ask you to agree to an overseas disclosure in place of the steps the law requires it to take.

#19Subprocessors

A subprocessor is a service provider that Academyship appoints to help process personal information on our behalf as part of delivering the service — for example, cloud hosting, email, SMS or AI providers. Subprocessors are required to protect the information and to use it only to provide their service to us.

A summary appears below. The current canonical register is available on the Subprocessor Register page. Under section 18 of the Data Processing Addendum, Academyship gives its Institution customers written notice at least 30 days before a new or replacement subprocessor begins processing Customer Data, except in a limited emergency, and Institutions may object.

Academyship uses AWS End User Messaging SMS for SMS 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. Institutions control message content, recipients, timing and any authorised sender identity, and are responsible for consent, other lawful authority, notices, opt-outs and communications-law compliance. Academyship does not guarantee carrier delivery or exact sender-ID display. A sender identity does not change the Institution’s control of its records or Academyship’s privacy and data-processing role.

#20Customer-selected integrations

An institution may choose to connect Academyship to third-party services it controls (for example, its own accounting or identity service). Those services are not Academyship subprocessors; they are the institution's own service providers. When an institution enables an integration, the institution is responsible for that service's terms and privacy practices and for authorising the data flow. Information shared with such a service is handled under that provider's terms, not this policy.

Calendar exports you start

Some booking and event screens let you add an appointment or event to an external calendar, for example Google Calendar, Outlook or Office 365, or Yahoo Calendar, or download a calendar file. When you choose to do this, the details of that appointment or event, such as its title, time, location, description or meeting link, are sent to or saved in the calendar service you chose. The calendar provider then holds its copy under its own terms. A calendar link is not a connection between Academyship and your calendar account, and the calendar provider is not an Academyship subprocessor. Academyship cannot change or delete the copy held in your calendar. Anyone you share a calendar file or link with may be able to see the details it contains.

#21Security safeguards

Academyship maintains technical and organisational safeguards appropriate to the sensitivity and risk of the information it handles. HTTPS is enforced and TLS 1.2 or later is required. Production RDS and internal services are private and not publicly accessible; S3 public access is blocked except for deliberately public assets; and AWS-managed KMS keys protect configured encrypted services. Each Institution receives a dedicated tenant database. Infrastructure and security logs are retained for 30 days. That period applies to those logs only. It does not apply to records kept in an Institution's workspace, such as portal sign-in history, audit trails and signing evidence (see section 26). Further contractual details are set out in Annex II of the Data Processing Addendum.

The backup lifecycle includes daily backups, 30 daily recovery points, 15 weekly recovery points and 7 monthly recovery points. Backups support platform recovery and do not replace an Institution's own records-management obligations.

No online service can be completely secure, and we describe our controls at a level that does not expose exploitable detail. Additional detail is available to institutional customers and prospects on request; see our Trust & Security page and DPA.

#22Tenant isolation

Each Institution is provisioned with a logically and operationally isolated Tenant and a dedicated tenant database for its workspace records. Academyship enforces tenant context throughout application, API, reporting, file-access and AI-processing paths. A User from one Institution cannot search for, view, retrieve or discover another Institution's Users or Customer Data unless an expressly authorised cross-organisation arrangement is created under a separate written agreement.

#23Our personnel access to data

Academyship personnel may access Customer Data only where reasonably necessary to provide authorised support, investigate a security or service incident, maintain the service, comply with law or carry out another documented authorised purpose. Access is restricted by role, limited to the minimum necessary scope and duration, and logged. Personnel with access are subject to confidentiality obligations. Academyship does not permit personnel to browse Customer Data for curiosity, personal use or unrelated product development.

#24Data sharing and disclosure

We do not sell personal information. We disclose personal information only: to subprocessors that help us provide the service (section 19); to payment service providers to process payments (section 17); as directed by the institution that controls the relevant records; when you ask us to, or take an action that sends it, such as adding an event to an external calendar (section 20); where required or authorised by law, or to respond to a lawful request from an authority; to protect the safety, rights or property of individuals, the institution, Academyship or the public; and in connection with a business transaction (such as a merger or sale), subject to appropriate confidentiality and to this policy.

Who may receive information

A copy that has been downloaded, emailed, printed or added to a calendar can remain with its recipient after the original record is changed or removed from the platform.

Public credential verification

Where an Institution enables it, a certificate or card can carry a verification link or code, such as a QR code. Anyone holding a valid verification link or code can see limited credential details without signing in: the holder's name, the credential number and type, the course, the issue date, the issuing Institution and the credential's current status. This is not a searchable public profile. Verification shows those limited details, not the full credential or other information held in the Institution's workspace. A copy of the credential document itself, if the holder or Institution shares it, shows whatever the Institution printed on it.

The Institution decides whether to offer verification and is responsible for having authority to disclose these details. If the Institution replaces or withdraws a credential, verification shows its current status. Share a verification link or code only with people who need to check the credential. To correct a credential or ask about its verification, contact the issuing Institution.

#25Government and public-sector Institutions

Institutions in the government sector, and institutions in particular states and territories, may be subject to additional privacy, records and child-safety requirements, and may be governed by state or territory privacy and records legislation instead of, or in addition to, the federal Privacy Act (see section 3). Where a government customer requires additional or overriding terms, those may be agreed in a signed Order Form or schedule as described in our Terms and DPA. Institutions remain responsible for meeting the specific legal obligations that apply to them.

#26Retention, deletion and de-identification

Institution-controlled data is retained while the institution's workspace is active and as directed by the institution, subject to the Terms and any legal holds. During the subscription, and for at least 60 days following termination, institutions can export Customer Data using Academyship's authorised export functions, consistent with the Terms of Service (section 23) and the DPA (section 20).

The Data Retention page sets out, by type of record, who decides how long it is kept, what ends that period, and how export, deletion and backups work.

After the export period, Academyship deletes Customer Data from active systems in the ordinary course, and backup copies expire through the documented backup lifecycle rather than being erased instantly. Deletion workflows include associated uploaded files, derived previews and thumbnails, search indexes and AI-related indexes where applicable. Legal holds and legal retention requirements override deletion. On written request, Academyship provides confirmation of deletion.

We retain the business information we handle in our own right for as long as needed for the purposes described in this policy and to meet legal, tax and record-keeping obligations, after which we take reasonable steps to delete it or de-identify it.

Retention by type of record

Different records follow different rules. Each period in this policy applies only to the type of record it names.

#27Your rights

You may request access to, and correction of, the personal information we hold about you, and you may ask about deletion. Because institutions control the records in their workspaces, requests about student, staff or other workspace records are generally directed to the relevant institution, which decides on the request as the controlling entity; we assist the institution as needed. For information Academyship holds in its own right (for example, your business-contact or support information), contact privacy@academyship.com.au.

We will verify identity before acting on a request, respond within the timeframes required by the Privacy Act, and, if we decline a request, explain why and how you can complain.

How requests are handled

• Access and correction. You can ask to see the personal information held about you and to have it corrected if it is inaccurate, out of date, incomplete, irrelevant or misleading. If a record contains an allegation or opinion that you dispute and it is not corrected, you can ask for a statement of your view to be associated with the record.
• Deletion. You can ask for information to be deleted. Australian privacy law does not give an unconditional right to have information deleted. Information is deleted or de-identified when it is no longer needed for a permitted purpose, unless the law, a legal hold or an Institution's record-keeping obligations require it to be kept. We will tell you if we cannot delete something and why.
• Institution-held records. If you ask us about a record an Institution controls, we will tell you which Institution to contact, pass your request on where appropriate and help the Institution respond. This does not remove obligations Academyship has under privacy law for its own handling of your information.
• Proportionate identity checks. We ask only for what is reasonably needed to confirm who you are, and your authority if you are acting for someone else, in proportion to the request. We do not ask for identity documents to answer a general enquiry.

#28Charges for privacy requests

We do not charge you to make a privacy request. If a lawful charge applies to giving access to information, any such charge will be reasonable, will not be excessive, and will be notified to you in advance so you can decide whether to proceed.

#29Automated decision-making

Academyship's AI-assisted features produce suggestions to support people doing their work; they do not make significant decisions about individuals on their own. Significant educational, disciplinary, admission, employment, financial or wellbeing decisions require authorised human review, as described in section 15 and our Terms.

Automated processing is not limited to AI. Academyship also runs rules that an Institution sets up, and some of those rules can produce an outcome for a person automatically, or produce a result that a person then relies on. A person being involved somewhere in the process does not mean the rule has no effect. The table below describes the main kinds of rule-based processing, where an Institution uses the relevant module.

Rule-based processing

The Institution is responsible for the rules it sets and for the decisions it makes using them. Academyship is responsible for the software applying the configured rules as described. If you think an automated outcome is wrong, you can ask the Institution to review it and to correct the information it was based on (section 27). Payment providers may also apply their own automated checks, such as fraud screening, under their own terms (section 17).

#30Direct marketing and preferences

We may send service and account communications to institutional contacts, which are necessary to administer the relationship. Any marketing communications we send comply with the Privacy Act and the Spam Act 2003 (Cth); you can opt out at any time using the unsubscribe function or by contacting us. We do not use student data for marketing.

#31Data breach response

Academyship maintains a documented process to detect, assess, contain, investigate and respond to Security Incidents and Personal Data Breaches.

Where a Personal Data Breach affects Institution-controlled Customer Data, Academyship will notify the affected Institution 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 Institution. Academyship may provide information in stages as its investigation progresses.

Each party remains responsible for its own statutory breach-assessment and notification obligations. Where Academyship and an Institution both hold affected personal information, they will coordinate promptly and determine which party will lead communications with affected individuals, the OAIC or another regulator. Unless otherwise agreed or required by law, the Institution will ordinarily lead communications concerning its students, staff and other data subjects, and Academyship will provide reasonable assistance and relevant information.

Nothing in this section prevents Academyship from notifying a regulator, affected individual or other person where Academyship is independently required or permitted to do so by law.

The 72-hour notice and the Notifiable Data Breaches scheme

The 72-hour notice described above is a contractual commitment that Academyship makes to Institutions. It is separate from the Notifiable Data Breaches scheme under the Privacy Act. Under that scheme, an entity that suspects an eligible data breach must carry out a reasonable and prompt assessment and take all reasonable steps to complete it within 30 days. The 30-day limit is not a reason to wait before acting. Where an eligible data breach has occurred, the entity must notify the Office of the Australian Information Commissioner and affected individuals as soon as practicable, unless an exception applies. Each of Academyship and the Institution assesses its own obligations under the scheme. Agreeing which party leads communications is a matter of coordination. It does not allow either party to delay or prevent a notification the law requires.

#32Complaints and the OAIC

If you have a privacy concern, please contact complaints@academyship.com.au or privacy@academyship.com.au. We will acknowledge your complaint, investigate it, and respond within a reasonable time. If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au. If your concern relates to records controlled by an institution, we may direct you to that institution and assist it to respond.

#33Changes and review

We review this policy at least annually and whenever a material legal, product, security, hosting, AI, vendor or business change affects our handling of personal information. If we make a material change, we will update the effective date and take reasonable steps to notify affected institutional customers and Users. This Privacy Policy is an informational privacy notice and is not accepted as a contract. Contractual changes are governed by the Terms of Service, the Data Processing Addendum and any applicable Order Form. Prior versions can be requested from legal@academyship.com.au.

#34Definitions

These definitions are used consistently across our Terms, this policy and our DPA.

• Customer / Institution — the education institution or organisation that subscribes to or is authorised to use Academyship and controls its workspace.
• Tenant — the isolated workspace and dedicated database provisioned for an Institution.
• User — an individual authorised by an Institution to access the platform, including administrators, staff, students and guardians.
• Customer Data — data an Institution and its Users submit to, or that is generated for the Institution within, the platform.
• Student Data — Customer Data that relates to students.
• Personal Information — information about an identified individual, or an individual who is reasonably identifiable, as defined in the Privacy Act.
• Sensitive Information — 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 — TFNs, USIs, state student identifiers, passport numbers, visa identifiers and similar identifiers subject to additional legal handling requirements. A student USI (Unique Student Identifier) and a superannuation fund USI (Unique Superannuation Identifier) are different identifiers (see section 13).
• Institution Charges — amounts an Institution charges its students, payers or others, such as tuition, instalments, canteen purchases, library fines or booking fees. Paying an Institution Charge does not make the payer a customer of Academyship's software.
• Public Verification — the optional feature, enabled by an Institution, that lets anyone holding a valid verification link or code see the limited credential details listed in section 24.
• Security Incident — an event that compromises, or may compromise, the security, confidentiality, integrity or availability of the platform or Customer Data.
• Personal Data Breach — a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Customer Personal Data.
• Subprocessor — a service provider Academyship appoints to process Customer Data on our behalf.
• Integration — a third-party service an Institution chooses to connect to its workspace.
• AI Features — optional AI-assisted features offered within the platform.

#35Governing law

This policy is governed by the laws of New South Wales, Australia, and the Commonwealth of Australia where applicable, unless a signed Order Form or government contract lawfully specifies otherwise.

#36Accessibility of this policy

We aim to make this policy accessible. If you need it in an alternative format, contact accessibility@academyship.com.au or call +61 481 810 181. See our Accessibility Statement.

#37Change history

#38Related documents

Terms of Service Acceptable Use Policy Data Processing Addendum & Subprocessor List Subprocessor Register Cookie Policy Responsible AI Statement Student Privacy Guide Child Safety Statement Support Accessibility Statement Trust & Security