Trust Center
Security Overview
These practices reflect how Veriti is designed, operated and continuously improved to protect school, staff and learner information.
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.
Encryption
Encryption in Transit
ImplementedAll 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
ImplementedDatabase and object storage providers encrypt data at rest using industry-standard encryption offered by the underlying cloud platforms.
Password Hashing
ImplementedPasswords are never stored in plaintext. Credentials are hashed using modern one-way hashing before persistence.
Secret Management
ImplementedAPI 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
| Category | Implementation | Status |
|---|---|---|
| Transport encryption (HTTPS/TLS) | All public endpoints served over HTTPS | Implemented |
| Encryption at rest | Provider-managed encryption for database and storage | Implemented |
| Password storage | One-way password hashing; plaintext never stored | Implemented |
| Authentication | Credential-based authentication with session validation | Implemented |
| Authorisation (RBAC) | Role-based access control for staff and school users | Implemented |
| Server-side validation | API requests validated and authorised on the server | Implemented |
| Input validation | Request payloads validated before processing | Implemented |
| Rate limiting | Applied on public contact and sensitive endpoints | Partial |
| Logging & monitoring | Application and platform monitoring with operational alerts | Partial |
| Security updates | Dependency and platform updates applied on a recurring basis | Implemented |
| Incident response | Documented escalation and customer communication process | Partial |
| Multi-factor authentication | Planned enhancement for staff accounts | Planned |
| Single sign-on (SSO) | Planned for enterprise school deployments | Planned |
| Comprehensive audit logs | Expanded security reporting on the roadmap | Planned |
Contact Security Team
Questions about security, privacy or procurement questionnaires.