Data protection

01Our position

An application carries some of the most sensitive documents a person owns: a passport, academic records, test results, and in some cases health and financial information. We treat that material as something we are holding on your behalf, not as data we happen to have.

Security is built into how the product is designed rather than added at the end. Access is denied by default and granted only where a rule says it should be, and every sensitive action leaves a record.

02The standards we work to

Our controls are built to follow recognised security and privacy frameworks, and we hold ourselves to them as we grow.

• SOC 2: the trust services criteria covering security, availability, processing integrity, confidentiality and privacy.
• ISO 27001: an information security management system, with risks assessed, owned and reviewed rather than handled case by case.
• NIST: the cybersecurity framework and its guidance on identifying, protecting, detecting, responding and recovering.
• HIPAA: the safeguards expected of health information, applied to any medical material an institution requires as part of an application.
• PIPEDA: Canadian privacy law principles, including consent, limited collection, accuracy, safeguards and the right to access your own information.

03Access control

• Every table that holds student, application, document, payment or staff data is protected by database level access rules, so a record cannot be read by anyone the rules do not name.
• Students reach their own records only. University staff reach only the applicants of their own institution.
• Staff accounts require a second factor at sign in, and sensitive actions require it again.
• The administration surface is a separate application on its own protected domain, with its own credentials and its own deployment.

04Documents

• Uploads go to private storage that is never publicly readable.
• A document is reached through a link that is issued only after an authorisation check and expires within minutes.
• Uploads are restricted by type and size, and are never executed.
• Every staff view or download of a document is logged with the identity of whoever opened it.

05Payments

Card details are handled by our payment provider and never reach our servers. Payment status is set by a signed message from the provider rather than by anything a browser sends, so a payment cannot be marked as paid by a client.

06Engineering practice

• Encryption in transit and at rest.
• Input validated at the server boundary against strict schemas, with parameterised database access throughout.
• Security headers, session protections and rate limits on the routes that matter.
• Dependencies pinned, audited and updated, with automated checks before anything reaches production.
• Authorisation tested for both the allowed and the denied case as part of building a feature, not afterwards.

07Monitoring and incidents

Administrative actions, sign in events and document access are recorded so that unusual activity can be found and traced. If an incident affects your information, we investigate it, contain it, and tell the people affected along with the regulators we are required to notify.

08Your data rights

You can ask for a copy of what we hold, correct anything wrong, or ask for your account and its data to be deleted, subject to records we are required to keep. Our privacy policy sets out what we collect and why.

09Reporting a security concern

If you believe you have found a vulnerability, or that an account or document has been reached by someone who should not have it, write to us straight away with enough detail to reproduce the problem. We investigate every report and we do not pursue anyone who reports one in good faith.