Trust Center

Security Overview

These practices reflect how Veriti is designed, operated and continuously improved to protect school, staff and learner information.

Last updated: 29 May 2026Version: 1.1.0
Client overview PDF

Security Philosophy

At Veriti, customer trust is fundamental to our product design. Security and privacy are considered throughout the software development lifecycle rather than being added after development. We apply the principle of least privilege, minimise data collection wherever possible, and continuously improve our security posture based on evolving threats and customer feedback.

For our broader product principles and customer commitments, see Our Principles.

Security considered throughout development

Security requirements are considered during design and implementation, not only at the end of a release cycle.

Defence in depth

Multiple layers of controls protect customer data, including network encryption, application authorisation, and infrastructure hardening.

Least privilege

Users and services receive only the permissions required to perform their role.

Secure defaults

New accounts and features favour restrictive access and safe configuration by default.

Secure Development

Security considerations are incorporated throughout product design, implementation, testing and deployment. New functionality is reviewed for security implications before release.

Responsible Disclosure

Security vulnerabilities can be reported confidentially to operations@codeweave.io with the subject line “Security vulnerability”. We ask researchers not to publicly disclose issues until we have had a reasonable opportunity to investigate and remediate.

Authentication

Users authenticate with credentials managed through the platform identity layer. Successful login establishes a validated session that must be presented for protected API requests.

  • Authentication process: Credentials are verified server-side before a session is issued.
  • Password protection: Passwords are hashed with modern one-way algorithms and never stored in plaintext.
  • Session validation: Protected routes validate session integrity before returning school data.

Authorisation

Veriti uses role-based access control (RBAC). Each user is assigned a role within their school tenancy. Roles determine which modules and actions are available. Permission checks are enforced on the server for every sensitive operation.

School tenancy

Users belong to a single school environment

Role

Administrator, staff, parent or other assigned role

Permissions

Module and action rights derived from the role

Resource access

Server-side checks before reading or writing data

Access is evaluated from tenancy through role-based permissions to each resource request.

Encryption

Encryption in Transit

Implemented

All client traffic to Veriti is served over HTTPS/TLS. Data moving between browsers, mobile clients and backend services is encrypted in transit.

Encryption at Rest

Implemented

Database and object storage providers encrypt data at rest using industry-standard encryption offered by the underlying cloud platforms.

Password Hashing

Implemented

Passwords are never stored in plaintext. Credentials are hashed using modern one-way hashing before persistence.

Secret Management

Implemented

API keys, database credentials and third-party secrets are stored as environment configuration in hosting platforms, not in application source code.

API Security

  • Server-side validation: Requests are validated on the server before data is read or written.
  • Permission enforcement: Authorisation is checked for protected resources, not only in the UI.
  • Input validation: Payloads are checked for required fields, formats and length limits.
  • Rate limiting: Applied on public contact endpoints and selected sensitive routes. Broader API rate limiting continues to expand.

Operational Security

  • Logging: Application and platform logs support troubleshooting and incident investigation.
  • Monitoring: Hosting and health monitoring help detect outages and degraded performance.
  • Security updates: Dependencies and platform components are updated on a recurring basis.
  • Incident response: Material incidents are triaged, mitigated and communicated to affected schools. Formal playbooks continue to mature.

Incident Communication

Where customer data may be materially affected by a security incident, Veriti follows documented incident response procedures and communicates with affected customers as appropriate.

Security Controls Matrix

Implemented
Partial
Planned
Security controls by category, implementation and status
CategoryImplementationStatus
Transport encryption (HTTPS/TLS)All public endpoints served over HTTPSImplemented
Encryption at restProvider-managed encryption for database and storageImplemented
Password storageOne-way password hashing; plaintext never storedImplemented
AuthenticationCredential-based authentication with session validationImplemented
Authorisation (RBAC)Role-based access control for staff and school usersImplemented
Server-side validationAPI requests validated and authorised on the serverImplemented
Input validationRequest payloads validated before processingImplemented
Rate limitingApplied on public contact and sensitive endpointsPartial
Logging & monitoringApplication and platform monitoring with operational alertsPartial
Security updatesDependency and platform updates applied on a recurring basisImplemented
Incident responseDocumented escalation and customer communication processPartial
Multi-factor authenticationPlanned enhancement for staff accountsPlanned
Single sign-on (SSO)Planned for enterprise school deploymentsPlanned
Comprehensive audit logsExpanded security reporting on the roadmapPlanned

Contact Security Team

Questions about security, privacy or procurement questionnaires.