Information Security Policy

1. Purpose and Scope

This policy establishes the information security requirements for Thinking Mode, an AI-powered conversational assessment platform for educational organisations. It applies to all staff, contractors, and systems involved in the development, operation, and support of the platform.

2. Roles and Responsibilities

• CTO — Information Security Policy owner; accountable for security posture and policy compliance
• Engineering team — Implementation and day-to-day enforcement of technical controls
• All staff — Compliance with this policy in their area of work
• This policy is reviewed annually and after any significant security incident

3. Data Classification

Data Classification

All data is assigned one of three classifications. Classification determines handling, access, and retention rules.

4. Access Control

• Role-based access control enforced across all platform functions: superadmin → coordinator → educator
• All access to production systems requires individual named accounts — no shared credentials
• Principle of least privilege applied; access scoped to organisational tenant by design
• Student access is stateless: no registration or password; students enter a display name (or the school’s LMS supplies one) and join via a task access code or a launch from the school’s LMS, receiving an HMAC-signed session cookie
• Production database and infrastructure access restricted to named engineering personnel
• Access reviewed when staff change roles or leave the organisation

5. Authentication Requirements

Authentication Requirements

Educator and Administrator Accounts

• Minimum 14-character passwords enforced at registration and password change
• Passwords hashed with bcrypt (cost factor 12+); plaintext passwords never stored or logged
• Passwords must include upper- and lower-case letters and a number, and are checked against the HaveIBeenPwned k-anonymity API whenever a password is set (registration, change, reset, admin-set) — compromised passwords rejected
• SSO via Google Workspace or Microsoft 365 (Entra ID) preferred; email/password available as fallback
• TOTP multi-factor authentication available for all accounts; enforced for superadmin and coordinator roles (hard block until configured); prompted at first login for educators (skippable); schools can also require it for their educators
• Sessions managed by Auth.js v5 using encrypted session tokens (JWE); 8-hour expiry; stored in HttpOnly, Secure, SameSite=Lax cookies
• Brute force protection: an account is locked for 15 minutes after 5 failed attempts; sign-in attempts are rate-limited; IPs that repeatedly trip authentication rate limits are blocked automatically

Student Access

• Students are not registered users and hold no account on the platform
• Students enter a display name (or the school’s LMS supplies one) and gain access via a task access code provided by the educator or a launch from the school’s LMS
• On entry, a stateless custom HMAC-SHA256 signed token (not a standard JWT) is issued in a per-task cookie: HttpOnly, Secure, SameSite=Lax, 8-hour expiry; it carries only session, task and organisation identifiers
• The session is scoped to a single task and organisation; students cannot access any other data
• No password is collected from students. Students provide a display name; an LTI launch also stores the LMS user id. One optional, off-by-default exception: where Thinking Mode, the school and the educator all enable it, a student may enter their own email address (or an educator may type one) to be sent a re-entry code. The address is used once to send that email and is not stored (redacted from the email log); the message body is deleted after 90 days and the remaining delivery record after 12 months.
• Optional voice features (off by default, enabled per task by the educator in Discussion and Defence modes; the school can turn off student voice input): student speech is streamed to AWS Transcribe (Sydney region) for transcription and not stored; AI replies can be read aloud by AWS Polly (Sydney region)

6. Data Protection

In Transit

All traffic is served over HTTPS/TLS 1.2 minimum. HTTP Strict Transport Security is enforced (max-age=63,072,000; includeSubDomains; preload). Internal connections to AWS RDS and Redis use TLS.

At Rest

PostgreSQL on AWS RDS and object storage on AWS S3 are encrypted at rest via AWS managed encryption. Passwords are hashed with bcrypt. Educator and administrator session tokens are encrypted (JWE). Student session tokens are signed, not encrypted — they carry only session, task and organisation identifiers.

Secrets Management

API keys, signing secrets, and credentials are held exclusively server-side: application secrets in AWS Systems Manager Parameter Store (SecureString), injected at ECS task start; database credentials in AWS Secrets Manager, rotated automatically every 30 days. No secrets are permitted in client bundles or version control. The NEXT_PUBLIC_ prefix is never used on any secret.

Data Residency

All customer and student data is stored in AWS ap-southeast-2 (Sydney, Australia). AI inference: Anthropic Claude models run on AWS Bedrock in Australia; OpenAI models, used for organisations on the default (global) AI region, are processed in the United States; organisations on the Australian AI region use Bedrock only. Both are disclosed in the Sub-processor Register.

Data Retention and Disposal

The Platform Access Conditions provide that data may be stored indefinitely unless the Customer requests deletion. This standard sets operational retention schedules that apply by default; customers may request earlier deletion at any time via privacy@thinkingmode.com or through the account deletion endpoint.

Active data

• Student session data: retained for 365 days (school plans) or 120 days (personal plans) after last activity, unless the organisation sets its own period. Sessions joined but never started are removed after an hour.
• Educator and administrator accounts: retained for the life of the account
• Task content and AI evaluations: retained for the life of the associated task

Archived data

• On soft-deletion of a student session: data moved to archive tables and held for 30 days, then permanently deleted by the daily purge reaper (this includes sessions that reach the end of their retention period)
• Safety event log content: auto-redacted after 12 months by the daily redaction reaper; metadata (type, severity, timestamp) retained
• Security and audit event logs: auto-purged after 2 years by daily security-events reaper; exportable by superadmin
• Email delivery log (recipient address, subject, message body, delivery status): auto-deleted after 12 months by the daily email-log reaper. The email suppression list of bounced and complained addresses is kept separately so those addresses are not mailed again.
• Re-entry code emails to students (optional feature): the message body — containing the student's entered identifier and the re-entry code — is auto-deleted after 90 days by the daily reaper; the remaining delivery record is deleted with the email delivery log after 12 months. The recipient email address is never stored (redacted from the email log at send time).
• Automated database backups: retained for 14 days and expire automatically; not subject to individual deletion requests

Account closure

• Personal accounts can be self-deleted via /api/account/delete: all associated records (tasks, sessions, messages, evaluations, rubrics) are cascade-deleted; rubrics shared with other users are kept and reassigned
• School-attached accounts are removed by the school or Thinking Mode and held in a recoverable Bin for 30 days. Accounts that own tasks are then kept as a former-teacher record so the school keeps its students' work; other accounts are permanently deleted. Everything is purged when the organisation closes
• Deletion requests logged in security_events audit table with actor identity
• The School may request earlier deletion of Student Data by contacting privacy@thinkingmode.com

7. Application Security

• TypeScript strict mode enforced across the codebase; no any types or @ts-ignore permitted
• Parameterised SQL via Drizzle ORM — raw SQL string concatenation is prohibited
• Input validation at all API boundaries; stack traces never returned to clients
• ESLint-enforced import boundaries between frontend and backend layers
• All code changes require pull request review before merge to main branch
• Automated test suites cover authentication, authorisation, cross-tenant isolation, and input validation: Vitest unit and API tests run on every pull request; Playwright end-to-end tests run before every production release
• Dependabot enabled with automated security-update pull requests for dependency vulnerabilities
• Manual security testing and third-party scanning tools used on an ongoing basis
• Content Security Policy in place; HTML output sanitised with sanitize-html (allow-list) on all user-generated and AI-generated content rendering paths

8. Infrastructure and Network Security

• Platform hosted on AWS ECS (Sydney region) behind an Application Load Balancer
• AWS WAF with managed rule sets (OWASP common rules, known bad inputs, IP reputation list) and rate-based rules
• AWS Shield Standard active
• AWS GuardDuty enabled: continuous threat detection across CloudTrail, VPC Flow Logs, DNS, S3, RDS login events, Lambda, and EBS
• AWS Security Hub enabled: CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices, with CIS alarms on CloudTrail events
• AWS CloudTrail: multi-region audit log of AWS management activity and S3 write events, retained for at least 90 days
• Rate limiting applied at API level; IP blocking available via superadmin-managed blocklist
• RDS automated backups with point-in-time recovery enabled; 14-day retention

9. Third-Party and Vendor Management

Sub-processor Register

The following sub-processors are authorised to process data on Thinking Mode's behalf. Thinking Mode will notify affected parties of any intended addition or replacement of sub-processors before the change takes effect.

10. Incident Detection and Response

• Security events detected via: AWS GuardDuty findings, Sentry error/anomaly alerts, internal security_events audit table
• All sensitive operations (data export, account deletion, role changes, IP blocks) logged with actor identity and timestamp
• On detection of a potential security incident: CTO notified immediately; affected systems isolated if required; root cause investigated; affected parties notified per the Data Breach Response Plan
• Credential rotation procedures are documented for all critical secrets, including the student session HMAC signing key

11. Data Breach Obligations

Notification Obligations

Office of the Australian Information Commissioner (OAIC)

• Submit an Eligible Data Breach notification via the OAIC online portal within 30 days of confirming an eligible data breach
• Include: organisation name and contact, description of breach, types of information involved, steps taken in response
• OAIC portal: https://www.oaic.gov.au/privacy/notifiable-data-breaches

Customer Organisations (notify first — regardless of OAIC threshold)

• Thinking Mode's policy is proactive transparency: affected schools are notified as soon as involvement of their data is confirmed or reasonably suspected, without waiting for OAIC assessment to complete
• Initial contact within 3 business days of confirmed or suspected involvement
• Progress updates at minimum every 7 days during investigation
• Final summary on incident closure: root cause, remediation, recommended actions
• Notification channel: email to the organisation's nominated coordinator or administrator contact
• Document all notification communications in the incident record

Affected Individuals

• Notify affected individuals directly as soon as practicable — this may occur before OAIC notification if individuals can be identified and the risk of harm warrants it
• Notification must include: description of the breach, types of information involved, recommended steps individuals can take, contact details for queries
• For educators and administrators: email to registered address
• For students: notification via the customer organisation (school/institution), as students have no registered account or email address on the platform

12. Physical Security

Physical security of infrastructure is inherited from AWS data centre controls (ISO 27001, SOC 2, IRAP certified). No Thinking Mode staff have physical access to underlying hardware.

13. Acceptable Use

• Production systems accessed only for legitimate business purposes
• No storage of customer or student data on personal devices or unapproved services
• Credentials must not be shared; any suspected compromise reported to CTO immediately
• AI tools used for internal operations must not receive customer PII without documented approval

14. Security Framework Alignment

Thinking Mode follows the National Institute of Standards and Technology (NIST) Cybersecurity Framework and is working towards alignment with ISO/IEC 27001. This policy reflects those principles across governance, identification, protection, detection, response, and recovery.

15. Insurance

AI & Assessment Solutions Pty Ltd maintains the following insurance cover in accordance with Customer Agreement obligations:

• Public liability: not less than AUD $5 million per occurrence and in the aggregate
• Cyber insurance: not less than AUD $1 million per occurrence and in the aggregate
• Workers compensation: as required by applicable law

16. Governing Law

This policy and all associated practices are governed by the laws of South Australia, Australia. Regulatory obligations under the Australian Privacy Act 1988 (Cth) apply nationally.

17. Policy Compliance and Review

Non-compliance with this policy may result in disciplinary action. This policy is reviewed annually by the CTO and updated following any significant security incident or material change to the platform architecture.

18. Glossary