Security Annex

Version: 1.0
Last updated: 30 April 2026
Classification: Public

This Security Annex sets out the technical and organisational security measures ("TOMs") implemented by ai.verest in accordance with Article 32 of the UK GDPR and as referenced in the Data Processing Agreement (DPA).

1. Organisational Security

1.1 Security Governance

• Security policies are reviewed and updated at least annually, or following any significant incident or material change to the platform.
• Responsibility for data protection and security is assigned to a designated individual within the organisation.
• All personnel with access to personal data are subject to confidentiality obligations and receive data protection and security awareness training before being granted access.

1.2 Access Control Policy

• Access to personal data and production systems is granted on a need-to-know, least-privilege basis.
• Access rights are reviewed when personnel change roles and revoked promptly upon termination.
• Privileged access (admin-level) to production databases and infrastructure is restricted to authorised personnel only and requires multi-factor authentication.

1.3 Vendor and Sub-processor Management

• All sub-processors are assessed for security compliance before engagement.
• Data processing agreements incorporating equivalent security obligations are in place with all sub-processors.
• Sub-processors are listed in DPA Schedule 1.

2. Technical Security

2.1 Encryption in Transit

• All communications between clients and the ai.verest platform are encrypted using TLS 1.2 or higher.
• API endpoints use HTTPS exclusively; HTTP is redirected to HTTPS.
• Internal communications between services use encrypted channels.

2.2 Encryption at Rest

• All personal data stored in the database is encrypted at rest using AES-256 encryption, implemented by Supabase (hosted on AWS eu-west-2, London, UK).
• Database backups are encrypted using the same standard.
• File storage (attachments, exports) is encrypted at rest.

2.3 Authentication and Access Controls

• User authentication is managed via Kinde Auth, an enterprise-grade authentication provider.
• Multi-factor authentication (MFA) is supported and encouraged for all accounts.
• Session tokens are securely stored and have defined expiry periods.
• Rate limiting is applied to authentication endpoints to prevent brute-force attacks.
• CSRF protection is implemented on all state-changing requests.

2.4 Infrastructure Security

• Application hosting and infrastructure is provided by Hostinger International Ltd, with services distributed across EU and globally as required.
• The platform uses Supabase for database and backend services, hosted in the UK (London — AWS eu-west-2) region.
• Infrastructure is managed using industry-standard security configurations.
• Unused ports and services are disabled.
• Security patches and updates are applied promptly, with critical patches applied within 72 hours of availability.

2.5 Application Security

• Input validation is applied at all system boundaries to prevent injection attacks (SQL injection, XSS, CSRF).
• Content Security Policy (CSP) headers are implemented.
• Dependencies and third-party libraries are regularly audited for known vulnerabilities.
• Code changes undergo review before deployment to production.

2.6 Network Security

• Production systems are segregated from development and staging environments.
• Firewall rules restrict inbound and outbound traffic to authorised services only.
• Database access is restricted to application servers and authorised personnel via secure tunnels; databases are not publicly exposed.

3. Data Handling Security

3.1 Data Minimisation

• We collect and process only the personal data necessary for the stated purposes.
• Internal staff access to personal data is logged and monitored.

3.2 Backup and Recovery

• Data is backed up regularly with automated processes.
• Backups are encrypted and stored in geographically redundant locations.
• Backup retention periods are consistent with the data retention policies set out in the Privacy Policy.

3.3 Secure Deletion

• Personal data is deleted securely upon account termination in accordance with the DPA Article 8 and the Privacy Policy.
• Deletion from live systems occurs instantly; from backups within 90 days.
• Secure deletion procedures prevent recovery of deleted data.

4. Incident Response

4.1 Detection and Monitoring

• Authentication failures, unusual access patterns, and system errors are logged and reviewed.
• The system utilizes a high-frequency rotation policy for operational logs to maximize user privacy and adhere to global data minimization standards (such as UK/EU GDPR). Logs are maintained in a secure, tamper-evident environment and are programmatically flushed within 24 hours or upon system lifecycle events. This ensures that only the minimum necessary data required for immediate security monitoring is processed.

4.2 Incident Classification

Security incidents are classified by severity:

4.3 Response Procedure

1. Detect: Automated or manual detection of a potential incident
2. Contain: Isolate affected systems to prevent further exposure
3. Assess: Determine scope, nature, and affected data
4. Notify: If personal data is involved:
   • Notify affected Controller(s) within 72 hours of becoming aware
   • Assess ICO notification obligation (if likelihood of harm to individuals)
5. Remediate: Fix the root cause and restore normal operations
6. Review: Post-incident review to prevent recurrence
7. Document: Record all incidents in the internal breach log, including decisions not to report

4.4 ICO Notification

Where a Security Incident is likely to result in a risk to the rights and freedoms of natural persons, we will notify the ICO within 72 hours of becoming aware, in accordance with Article 33 UK GDPR.

Where we act as data processor, the Controller is responsible for making the ICO notification. We will provide all required information to assist the Controller within 72 hours of the incident.

5. Physical Security

• ai.verest does not operate its own data centres. Physical security is the responsibility of sub-processors (Hostinger, Supabase/AWS).
• Hostinger and AWS London operate ISO 27001-certified facilities with physical access controls, CCTV, and environmental controls.
• Internal office/remote working security: personnel are required to use encrypted devices and strong passwords.

6. Business Continuity

• Critical services are architected for high availability with redundant infrastructure.
• Disaster recovery procedures are documented and tested periodically.
• Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets are maintained for critical data services.

7. AI Security

• AI Agent features use OpenAI's API. Prompts and outputs are transmitted over encrypted HTTPS connections.
• We do not store AI-generated outputs beyond the user's session unless explicitly saved by the user.
• We do not use customer data or contact data to train, fine-tune, or improve AI models.
• OpenAI processes data subject to our IDTA and their Data Processing Addendum.

8. Compliance and Certification

9. Contact

Security concerns: info@aiverest.io
Data protection / legal: info@aiverest.io

This Security Annex is reviewed and updated at least annually. Last reviewed: 30 April 2026.