Security

Keeping institution data separate

Your institution's information is kept separate from other providers' data. Database controls and application permissions work together to restrict access to the institution and records a user is authorised to see.

Automated security checks test these protections, including attempts to access another institution's information.

Access control

• Staff permissions. Assign access according to each person's responsibilities.
• Confidential records. Restrict sensitive learner records and notes to authorised staff.
• Learner accounts. Invitations link learners to the records your institution has created for them.
• Multi-factor authentication. Staff can add a verification code at sign-in. Your sign-in requirements are confirmed during setup.
• Single sign-on. Microsoft Entra ID and Google sign-in can be configured for your institution, with connection testing during onboarding.
• Course discussions. Access follows the learner's course access, with privacy controls for anonymous posts.

Encryption

• Secure connections. HTTPS encrypts information travelling between your browser and the hosted portals.
• Protected credentials. Integration credentials are encrypted in storage. Passwords are stored as one-way hashes, rather than readable passwords.

Activity history

Trace important changes through a readable activity history. Recorded entries show what happened and help authorised staff investigate changes to records.

The log includes protections against changes to existing entries and checks that can detect alterations. This is known as a tamper-evident log.

AI safeguards

• Controlled access. AI features use institution access controls and staff permissions.
• Information handling. AI may process questions, course material and selected records for the feature being used. Redaction reduces personal information in supported workflows; it does not make every input anonymous.
• Review and permissions. Changes to shared AI teaching guidance require approval. Other features provide suggestions or act within the user's permissions, depending on the feature.
• Provider choice. Model providers and their data-handling settings are part of your AI configuration. See our AI privacy information.
• Staff judgement. AI suggestions and risk indicators support decisions made by your staff.

Availability and recovery

• Hosting options. Choose managed hosting or discuss deployment in your own environment. Responsibilities and service arrangements are agreed during onboarding.
• Checked releases. We check service health and confirm that the intended release is running after deployment.
• Issue investigation. Application error reporting helps us investigate service problems.
• Backup and recovery. We carry out database restoration exercises. Backup coverage, retention and recovery targets are agreed for your deployment.
• Maintenance. Planned maintenance is notified in advance and scheduled outside New Zealand teaching hours where practicable.

Recovery scope for procurement teams

Current restoration exercises cover the database. They do not yet cover uploaded files or a complete switch to a replacement system. We confirm recovery arrangements in writing before you rely on a specific recovery time or data-loss limit.

Release checks and maintenance

We combine automated checks with testing of important workflows on the hosted platform. Changes to data access, sign-in and institution boundaries receive additional security checks.

Ongoing maintenance includes software updates and improvements to security and reliability. Our roadmap shows recent improvements and future priorities.

Certifications and assurance

Pallara does not currently hold ISO 27001 or SOC 2 certification. If your procurement process requires independent certification, contact us to discuss your requirements.

We can discuss the scope of our checks and available evidence with your procurement or IT team.

Responsible disclosure

If you are researching Pallara's security, please:

• test only against your own tenant or a demonstration tenant we have given you;
• do not access, modify or retain another institution's or learner's data — if you can reach it, stop and tell us, that is the finding;
• do not run denial-of-service or high-volume automated scanning against production;
• give us reasonable time to fix an issue before disclosing it publicly.

Report to [email protected]. We do not currently run a paid bounty programme, and we will credit researchers who ask to be credited.