How we keep your data safe

A plain-English summary of how Ludoran protects students’ and staff data, what we don’t do yet, and how to tell us about a problem.

Where your data lives

Everything is stored in Australia: the database and sign-in service (Supabase) and the app and its files (Amazon Web Services) are in Sydney. Visitors reach the site through Cloudflare, which encrypts the connection at the data centre nearest to them and passes it on, encrypted, to Sydney; it doesn’t store your data. Backups stay in Sydney too. Two outside services see only the ordinary web request (your internet address and browser), never your data: Google Fonts for the typefaces, and YouTube’s privacy-enhanced player when a lecturer puts a video in a class.

Encryption

• In transit: HTTPS only (TLS 1.2 or newer) all the way from your browser to our server, and browsers are told never to use plain HTTP with us (HSTS).
• At rest: lecturers’ class data, accounts, sensitive records, uploaded files and backups are encrypted by the app itself (AES-256) before they’re stored, so a copied database or file is unreadable without the key. The key is held in AWS Key Management Service and never stored with the data. The disks underneath are encrypted as well.
• Passwords and PINs are stored only as salted, slow hashes, never as text.

Who can see what

• Access follows roles in your organisation: a lecturer sees their own classes; a head of department or dean sees the statistics their role covers, and no further.
• Each lecturer’s class data is kept separately from everyone else’s.
• Sharing between organisations (say, a student sending their badges to a business) only happens with the student’s consent, which they can see and withdraw at any time.
• Multi-factor sign-in (MFA) for staff and administrators, sessions that expire, and limits on repeated wrong passwords.
• Our own administrators’ access is limited to a small named group, and their changes are logged.

Audit trail

Sign-ins, failed sign-ins, administrators’ changes, consent changes and every change the assistant makes are recorded in an activity log. Each entry is sealed with a fingerprint (a hash) of the one before it, so if an entry were changed, removed or slipped in later, the check breaks and shows where. The log can be exported for your own records.

Your data, your choice

People can download their data and delete their account. Lecturers can export, correct or delete their class data at any time. We don’t sell data, show advertising or use third-party tracking.

AI features (Ludo)

What happens to data that goes in?

Loading the current setting…

Can it identify students?

Names on the class list, staff names, student numbers, email addresses, phone numbers and web addresses are replaced with placeholders (“Student A”) on our server before anything is sent, and put back only for display. The placeholder list is never sent or stored. The limit: free text can still identify someone in other ways, such as a student describing their job or town.

Will it be used to train AI?

No. Under Anthropic’s commercial terms, data sent through the API isn’t used to train its models, and is deleted after a short retention period. Check the current AWS and Anthropic terms; they can change.

Can Ludo make things up?

It can, like any AI. Ludoran limits it to your material, checks quotes and numbers in code, flags anything it can’t verify, and never acts on students without a person confirming.

• The AI helpers (Ask Ludo, Prep with Ludo, the meetings bot and the curriculum scan) can be switched off for a whole university, a faculty or school, or a class. Off at a higher level is off everywhere below it.
• The assistant can only do what the person using it could do themselves, asks before changing anything, and every change it makes is logged.
• Universities see the details from the live settings on their “AI and your data” page: provider and region, what’s on at each level, what is removed, what is kept, and usage.

Light mode: piloting without names

A lecturer can run a class in light mode before their university approves us keeping students’ names and student numbers. Ludoran doesn’t receive students’ names or student numbers: students join with a nickname, and their student number is scrambled on their own phone with a class key that is made in the lecturer’s browser and never sent to us. Identities can stay in your university’s Microsoft 365 (OneDrive); Ludoran only receives scrambled codes. The lecturer sees names by loading their class list in their own browser, where it stays.

• This is pseudonymous, not anonymous: the data is still about real students and should be treated with care.
• Anyone who has the class key (it is in the class QR code, so every student who scans it has it) could work a student number back out from its scrambled code, so we never show those codes to students. A breach of our servers alone doesn’t reveal student numbers.
• The key’s backup with us is locked with the lecturer’s passphrase, so a short passphrase would be the weak point: we ask for at least 12 characters.
• If the lecturer loses both the key file and the passphrase, nobody (including us) can match students to the class list again.

Messages you can trust

A phishing email only has to look like the university. A message in Ludoran can be checked. Lecturers and tutors sign what they send on their own trusted devices: a key made in their browser that can sign but can’t be copied out, not even by us. Each student’s phone checks the signature itself and shows “Verified: Dr X, from a trusted device”, or “Verified with Dr X’s fingerprint or face” for important messages confirmed with a passkey. Anything else says “Not from a trusted device”, with why. Only a class’s own teaching team can message its students, and every notification email has a reference code anyone can check in the app.

• A stolen password can send messages, but they show as not from a trusted device. Adding a device or passkey needs a fresh sign-in check.
• If our server were broken into, it still couldn’t sign as a lecturer, and a changed message shows on students’ phones. It could hold messages back, or publish a fake key: a phone that saw the real key before notices, a new phone can’t.
• The limits: malware in a lecturer’s browser could sign while it’s there; someone able to change the app’s code could defeat it; a reference code proves an email is ours but doesn’t stop a fake site. So every email says to open Ludoran yourself, and students and staff can practise spotting fakes with Phish or legit.

Backups and recovery

Lecturers’ class data is backed up automatically every day (kept for 14 days, encrypted) and can be restored from Settings. The file storage is also backed up daily by AWS, and the database is backed up daily by Supabase on its paid plan, which we move to before real student data goes in. If something goes wrong we follow a written incident response plan, including notifying affected people and the Australian privacy regulator (OAIC) where the Notifiable Data Breaches scheme requires it.

Monitoring and protection

The site sends strict browser security rules (a Content Security Policy that only runs our own code). Our cloud account records every administrative action (AWS CloudTrail), watches for threats (Amazon GuardDuty) and alerts us if the app stops or something unusual happens. Our code and its building blocks are scanned automatically for known vulnerabilities.

Certifications

We’re honest about where we are: Ludoran is not yet certified (for example to ISO 27001 or SOC 2). We build to ISO 27001 practices, and an independent penetration test is planned before university-wide rollouts. We’re happy to complete your security questionnaire (such as HECVAT).

Reporting a security problem

If you think you’ve found a vulnerability, please email [email protected] with the details and how to reproduce it. We’ll acknowledge it within three working days and keep you updated while we fix it. Please give us a reasonable time to fix it before telling anyone else, don’t access or change other people’s data, and don’t run tests that could disrupt the service (such as denial-of-service). We won’t take legal action against anyone who reports a problem in good faith and follows these guidelines. Our contact details are also in security.txt.