Information Security Statement
The technical and organisational security measures Lycia Limited applies to protect personal and confidential data processed across its platform.
This document is a draft and has not been formally approved. It is provided for review purposes and may be updated. No legal claims, certifications or compliance status should be inferred from this document until formally approved by the Master Administrator following solicitor and data-protection review.
Lycia Limited
282a Leigh Road
Leigh-on-Sea, Essex
SS9 1BW, United Kingdom
Company Registration No: 04465356
VAT Registration No: GB 155 3559 95
ICO Registration No: ZA250263
1. Security Overview
Lycia Limited applies a layered security approach to protect personal data, confidential commercial information and authentication credentials. This statement describes the technical and organisational measures currently in place.
Each control below is marked with its actual implementation status. Lycia does not claim controls that are not implemented or not verified.
2. Access Control
| Control | Status | Details |
|---|---|---|
| Access control — role-based access | Implemented | Roles enforced via entity-level RLS; admin, Super Admin, Management, Compliance Officer, Operations, Read Only |
| Least privilege | Implemented | Each role grants minimum necessary permissions per entity |
| Multi-factor authentication | Not Verified | Platform-level; not confirmed for all user types |
| Password requirements | Not Verified | Platform-managed; specific policy not confirmed |
| Session control | Partially Implemented | Authenticated sessions with token-based auth; session timeout not configurable per role |
| Encryption in transit | Implemented | HTTPS/TLS enforced across all endpoints |
| Encryption at rest | Not Verified | Platform-managed; specific encryption status not confirmed |
| Private file storage | Implemented | Sensitive files stored via UploadPrivateFile with signed URLs |
| Signed URLs (short-lived) | Implemented | Time-limited signed URLs for private file access |
| Secrets management | Implemented | API keys and OAuth secrets stored only in platform secrets; never in frontend, entities or logs |
| Audit logging | Implemented | SecurityAuditLog, VerificationAuditLog, ReportAuditLog, QuestionnaireAuditLog entities |
| Webhook validation | Implemented | Shufti Pro webhook signature validation and idempotency checking |
| Input validation | Partially Implemented | Form-level validation; additional server-side validation in backend functions |
| CORS restrictions | Not Verified | Platform-managed; specific CORS policy not confirmed |
| Rate limiting | Partially Implemented | API-level rate limits exist; application-level rate limiting not fully implemented |
| Upload MIME and size validation | Partially Implemented | File type accepted via integration; additional MIME validation recommended |
| Account lockout | Not Verified | Platform-managed; lockout policy not confirmed |
Status values: Implemented = confirmed in code; Partially Implemented = in place but with gaps; Not Implemented = not in place; Not Verified = platform-managed and not independently confirmed.
3. Data Classification
Lycia classifies data into five levels. See the Data Classification section of the internal Data Protection Policy for full details.
| Classification | Examples | Access |
|---|---|---|
| PUBLIC | Published website content, public Companies House data | No restriction |
| INTERNAL | Internal procedures, ordinary operational records | Authenticated staff |
| CONFIDENTIAL | Client reports, contracts, customer records | Role-restricted staff |
| HIGHLY CONFIDENTIAL | Identity documents, biometric results, AML results, sanctions matches, source-of-funds evidence, security incidents | Compliance Officer and authorised staff only |
| RESTRICTED SECRET | API keys, OAuth secrets, access tokens, SMTP passwords, webhook secrets, encryption keys | Master Administrator and Super Admin only; stored in platform secrets |
4. Private Storage and Signed URLs
Sensitive files (identity documents, verification evidence, compliance documents) are stored using private file storage. Access is granted only through time-limited signed URLs generated by the backend, preventing direct public access to file URLs.
Raw identity-document URLs are not stored in publicly accessible entity fields or frontend code.
5. Secrets Management
API keys, OAuth client credentials, access tokens and other secrets are stored exclusively in the platform's secrets management system. They are:
- Never stored in entity fields or database records
- Never included in frontend code or client-side bundles
- Never written to logs or audit trails
- Accessed only by backend functions at runtime
- Trimmed and validated before use (e.g. HMRC credentials are validated for whitespace, placeholders and line breaks)
6. Client and Case Isolation
Lycia enforces data isolation through entity-level Row-Level Security (RLS). External users can only access records linked to their organisation. Verification cases are isolated by case_id and created_by_id. Portal users see only data associated with their email or linked organisation.
7. Token Hashing and Link Security
Secure verification links and gold site assessment links use SHA-256 token hashing. The raw token is never stored — only the hash is persisted. Links have defined expiry dates and can be revoked. First access and last access timestamps are recorded.
8. Audit Logging
Lycia maintains multiple audit log entities:
- SecurityAuditLog — general security actions (login, access changes, credential operations)
- VerificationAuditLog — verification case actions (field changes, provider calls, status changes)
- ReportAuditLog — report generation, download and verification actions
- QuestionnaireAuditLog — gold site assessment actions
- ClientActivityLog — client portal activity
Audit logs are create-only (RLS allows creation by the system but restricts reads to authorised roles), providing an immutable record of significant actions.
9. Incident Response
Lycia maintains a Personal Data Breach Policy and an internal Incident Response Centre for managing security incidents. Incident playbooks are defined for common scenarios including stolen API keys, compromised OAuth secrets, exposed signed URLs, and unauthorised portal access.
10. Backups and Disaster Recovery
Platform-level backups are managed by the infrastructure provider. Lycia does not claim specific backup frequencies or retention periods unless confirmed. Disaster recovery procedures are platform-managed.
NOT VERIFIED — Backup frequency, retention and disaster recovery RTO/RPO must be confirmed with the platform provider.
11. Vulnerability Management and Penetration Testing
Lycia does not claim penetration testing has occurred unless evidence is uploaded to the PenetrationTest register. Vulnerability management relies on platform-level scanning and secure development practices. No penetration testing has been independently conducted to date.
NOT VERIFIED — Penetration testing status: no evidence of independent testing. This should be scheduled before claiming security certification.
12. Supplier Security
Lycia reviews the security practices of key processors before engagement. The Subprocessor Register and DPA Register are maintained in the administration panel. Supplier security reviews are recorded in the PenetrationTest entity (test type: Supplier Security Review).
CONTRACTUAL REVIEW REQUIRED — Security practices of individual providers must be confirmed through executed agreements.