Security

This page states plainly what protects your data today, and what we have not yet built. We would rather list a real gap here than let a vague statement imply more than is true.

1. Reporting a vulnerability

Email security@pteadvantage.com. Please include enough detail to reproduce the issue and, if relevant, the account or URL involved. We do not currently run a paid bug-bounty program, but we will acknowledge your report, investigate promptly, and credit you (if you want that) once a fix ships. Please report privately and give us a reasonable window to fix an issue before any public disclosure. See /.well-known/security.txt for the machine-readable version of this contact.

Scope: pteadvantage.com and its institute subdomains (*.institutes.pteadvantage.com), and the underlying API. Please do not attempt destructive testing (data deletion, service disruption) against production. Describe the issue instead and we will verify it.

Safe harbor:good-faith security research conducted under this policy, without accessing or modifying other users' data beyond what is strictly necessary to demonstrate the issue, will not result in legal action from us.

2. Data protection in place today

• Row Level Security on every data table, enforced by Postgres itself, not just application code: a student's data is scoped to that student, and an institute's data is scoped to verified, active members of that institute.
• Multi-factor authentication is required for privileged (admin/tenant-admin) accounts.
• All financial and credit-affecting writes run through database functions that only our server infrastructure can call: never directly from a browser, and never from a client-side key.
• Encryption in transit (HTTPS/TLS, HSTS enforced) for every connection, and encryption at rest for the underlying database and file storage.
• No card numbers stored. We do not operate a card-payment gateway; see our Privacy Policy for how payment proof is handled.
• Independent verification, not self-certification: access-control changes are verified by replaying every database migration against a real Postgres instance and running adversarial probes as the actual database roles, not just reading the code and assuming it's correct.

3. Where we are honest about the gap

An institute's security team deserves the real picture, not a polished one:

• We do not yet offer SSO/SAML for institute administrator accounts.
• We have not yet commissioned an external, third-party penetration test. Our security work to date is internal.
• We do not yet operate a public real-time status page.

If any of these are a hard requirement for your institute, email security@pteadvantage.com and tell us: it directly shapes what we prioritize next.

4. Subprocessors

See the Privacy Policy's Subprocessors section for the full, named list of infrastructure and AI providers we use.