Security

Last updated: 3 May 2026

Customer trust depends on us protecting the data uploaded to PeerPlacement. This page summarises the controls we have in place. We’re a young company — some controls below are in place today, others are part of a documented roadmap. Where that distinction matters to your evaluation, contact us at security@peerplacement.com and we will share current status under NDA.

1. Tenant isolation

• Each customer (“tenant”) gets a dedicated database, object-storage bucket, and encryption key.
• Application-layer requests carry a tenant context; queries are scoped to that tenant’s database connection.
• Cross-tenant access is impossible from tenant-user sessions; platform-admin access is restricted, audited, and MFA-gated.

2. Encryption

• At rest: AES-256 with per-tenant data-encryption keys, wrapped by a key management service.
• In transit: TLS 1.3 between client, edge, and origin. Internal service-to-service traffic encrypted.
• Field-level encryption for highly sensitive identifiers (e.g. passport numbers).

3. Access control

• Role-based access control (tenant_admin, staff, agent, student) with field-level permissions configurable per role.
• MFA support for all platform users; required for tenant administrators.
• Session expiry, IP logging, and anomaly alerts on suspicious sign-ins.
• Least-privilege internal access; production access is restricted to a small on-call group, MFA-required, and logged.

4. Authentication

• Supported flows: passwordless magic-link, one-time-password (OTP), and password (with MFA).
• Passwords (where used) are hashed with bcrypt at a high work factor.
• MFA secrets are encrypted at rest.

5. Audit logging

• Every state-changing action is recorded in an append-only audit log with actor, target, before/after values, IP, and user-agent.
• Customer-data deletions are logged; backups are aged out per the retention schedule.
• Audit logs are exposed to tenant administrators for review.

6. Data residency

• Default primary storage region: Australia.
• Customers may select an alternative region during onboarding.
• Cross-region transfers (e.g. for AI inference) use contractual safeguards described in our Data Processing Agreement.

7. AI and model usage

• AI features are configurable per tenant: choose between hosted models, third-party APIs (Anthropic, OpenAI), or self-hosted open-source models.
• For third-party providers, customer data sent for inference is governed by the provider’s data-handling terms; PeerPlacement does not retain inference inputs beyond what is needed to render results.
• Customers may opt out of any AI feature in tenant settings.

8. Backups and disaster recovery

• Automated, encrypted daily backups of tenant databases.
• Documented restore procedure tested on a regular cadence.
• Defined Recovery Point Objective (RPO) and Recovery Time Objective (RTO); current targets shared on request.

9. Secure development

• Code review required for all production changes.
• Dependency scanning and automated vulnerability checks in CI.
• Regular review of third-party libraries; patches applied on a defined schedule for severity bands.

10. Incident response

• Documented incident-response plan covering detection, containment, eradication, recovery, and post-incident review.
• Customer notification within 72 hours of confirming a personal-data breach affecting their tenant, where feasible.
• Public post-mortems for material incidents affecting customer-facing systems.

11. Compliance roadmap

• Designed against Australian Privacy Act / APP framework and PIPL requirements.
• SOC 2 Type II and ISO 27001 are on our compliance roadmap. Status available on request.

12. Reporting a vulnerability

Found a security issue? Email security@peerplacement.com with details. We commit to acknowledging reports within 2 business days and providing a remediation timeline. We do not pursue legal action against good-faith security researchers who follow coordinated disclosure.