Document: Security Policy Version: 1.0 (Draft) Effective Date: 06 May 2026 Last Reviewed: 06 May 2026 Governing Law: England and Wales

---

Security Policy

This Security Policy describes the technical and organisational measures (TOMs) implemented by ALL-IN-ONE DIGITAL SOLUTIONS LTD ("ClipToText", "we", "us", "our") to protect the ClipToText.ai platform ("Service") and the data processed within it.

This Policy is provided for transparency to Subscribers and forms part of our obligations as a Processor under the Data Processing Agreement (DPA). It supplements the obligations described in Schedule 2 of that agreement.

Questions or security reports: support@cliptotext.ai

---

1. Definitions

Term	Meaning
Personal Data	Any information relating to an identified or identifiable natural person, as defined in UK GDPR Article 4(1).
Processing Environment	The hardware, software, networking and supporting infrastructure used to deliver the Service.
Incident	Any event that has, or has the potential to, compromise the confidentiality, integrity or availability of the Service or Personal Data.
Critical Vulnerability	A vulnerability with a CVSS score of 9.0 or above, or any vulnerability enabling unauthorised access to Personal Data or cross-tenant data leakage.
Principle of Least Privilege	The practice of granting personnel and systems only the minimum access rights required to perform their function.
MFA	Multi-Factor Authentication — an authentication mechanism requiring at least two independent forms of verification.
RBAC	Role-Based Access Control — a system of access management based on defined roles and associated permissions.
TOM	Technical and Organisational Measure — any technical or process control designed to protect data security.

---

2. Governance and Accountability

2.1. Responsibility for security rests with the Founder / Chief Technology Officer of ALL-IN-ONE DIGITAL SOLUTIONS LTD.

2.2. Security reviews are conducted at least annually, or following any significant change to the Service architecture or a security incident.

2.3. Data protection by design and by default (Article 25 UK GDPR) is incorporated into all development and infrastructure decisions. New features undergo a security review before deployment.

2.4. Risk assessments are conducted where new processing activities or significant architectural changes are introduced. Data Protection Impact Assessments (DPIAs) are performed where processing is likely to result in high risk to Data Subjects.

[ICO GUIDELINE: Article 25 UK GDPR requires privacy by design and by default. Article 35 requires DPIAs for high-risk processing, including large-scale processing of personal data and use of new technologies — ICO DPIA guidance, 2021.]

---

3. Encryption

3.1 Encryption in Transit

3.1.1. All data transmitted between end-users and the Service is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled.

3.1.2. All API communications (REST API endpoints, AI sub-processor API calls, integration calls to WordPress, Shopify, Blogger, etc.) use HTTPS with valid TLS certificates.

3.1.3. Cloudflare manages TLS termination at the edge, providing automatic certificate management and HTTPS enforcement.

3.1.4. Inter-service communications within the infrastructure are encrypted where they traverse untrusted network segments.

3.2 Encryption at Rest

3.2.1. Personal Data stored in the production database (MariaDB) is protected by encryption at the storage layer using AES-256.

3.2.2. Files stored in AWS S3 (video files, transcription outputs, AI-generated images) are encrypted at rest using AES-256 (SSE-S3 or SSE-KMS).

3.2.3. Redis cache data is not persistently stored beyond its TTL for session and operational caches. Sensitive data is not stored in Redis in plain form.

3.2.4. API keys, OAuth tokens and integration credentials provided by Subscribers are stored encrypted at rest using application-level encryption.

3.3 Passwords and Secrets

3.3.1. User passwords are never stored in plain text. They are hashed using a one-way cryptographic algorithm with a unique per-user salt.

3.3.2. Application secrets, API keys and environment variables are stored in environment files (.env.local) that are not committed to version control and are accessible only to authorised infrastructure personnel.

3.3.3. JWT signing keys are stored securely and rotated on a defined schedule. JWT access tokens expire after 1 hour (production configuration). Key rotation is performed annually or immediately following any suspected key compromise.

---

4. Access Controls

4.1 Authentication

4.1.1. All Subscriber accounts use JWT-based authentication (JSON Web Tokens) with configurable expiry.

4.1.2. JWT tokens are blacklisted on logout via Redis, ensuring server-side token revocation.

4.1.3. Google OAuth 2.0 is supported as an alternative authentication method, delegating identity verification to Google.

4.1.4. All internal staff accounts and infrastructure access require MFA (Multi-Factor Authentication).

4.1.5. MFA for Subscriber accounts is not currently enforced but is recommended and planned for Pro-tier users in a future release. Subscribers may use Google OAuth 2.0 (which delegates authentication security to Google, including Google's own MFA capabilities) as an alternative to password-based login.

4.2 Role-Based Access Control (RBAC)

4.2.1. Access to internal systems (production database, infrastructure, admin panels) is governed by RBAC.

4.2.2. Personnel are assigned roles based on their function:

Role	Access Level
Developer	Application code repository; staging environment; no direct production database access without approval
Infrastructure / DevOps	Production infrastructure; limited to operational tasks; no direct Personal Data access
Support	Read-only access to account management tools; no access to raw Personal Data beyond what is necessary for support resolution
Admin	Full access to back-office management panel; granted only to founding team members; requires approval from CTO; reviewed monthly

4.2.3. The Principle of Least Privilege applies to all roles. Access is granted only for the duration it is needed.

4.2.4. Access rights are reviewed at least every 6 months and immediately on staff departure or role change.

4.3 Admin Back-Office Security

4.3.1. The administrative back-office (Controller/Admin area) is protected by Symfony's AdminSessionAuthenticator and is accessible only from defined IP ranges or via VPN.

4.3.2. The admin panel requires authentication via AdminSessionAuthenticator with a separate session mechanism from Subscriber JWT tokens. IP allowlisting is not currently implemented but is planned as a HIGH priority security enhancement before scaling beyond the founding team.

---

5. Multi-Tenant Data Isolation

5.1. The Service uses a multi-tenant architecture in which each Subscriber's data is logically isolated by a unique site_id identifier.

5.2. Data isolation is enforced at multiple layers:

Layer	Control
Database	All Doctrine ORM queries include a mandatory site_id filter. Cross-tenant queries without a site_id constraint are prohibited by code convention.
Application	TenantContext::getCurrentTenant() is enforced in all services accessing multi-tenant entities. The site_id is read from the JWT claim — never from the request body.
Cache	All Redis keys are prefixed with tenant:{siteId}: to prevent cross-tenant cache access.
Async processing	The site_id and user_id are embedded within Symfony Messenger message objects — never assumed from ambient context in async workers.

5.3. Attempts to access another Subscriber's data are logged and may trigger account suspension.

5.4. Automated alerting for anomalous cross-tenant query attempts is planned as a monitoring enhancement. Currently, cross-tenant access is technically prevented at the application layer (Doctrine filters + TenantContext) and all access attempts are logged in application logs retained for 90 days.

---

6. Infrastructure Security

6.1 Hosting and Data Centres

6.1.1. The Service backend is hosted on Hetzner Online GmbH infrastructure located in Helsinki, Finland (EU). As an EU-based data centre, no international data transfer mechanism is required for UK to EU transfers under the UK adequacy decision for the EEA.

6.1.2. Physical access to data centre facilities is restricted to authorised personnel by the hosting provider, subject to their own physical security controls.

6.2 Network Security

6.2.1. Cloudflare provides:

• CDN (Content Delivery Network) for performance and availability;
• DDoS protection (Layer 3, 4 and 7 mitigation);
• Web Application Firewall (WAF) with managed rulesets blocking common web attacks (OWASP Top 10, injection attacks, cross-site scripting).

6.2.2. Network firewalls restrict inbound traffic to only necessary ports (80/443 for web traffic; defined ports for internal services). All other inbound traffic is blocked by default.

6.2.3. Internal services (database, Redis, Messenger workers) are not exposed to the public internet.

6.3 Sub-Processor Security Standards

Our sub-processors maintain the following security certifications:

Sub-Processor	Security Standards
OpenAI	SOC 2 Type II; Data processed via API is not used to train models (API data usage policy applies)
Stripe	PCI DSS Level 1 (highest level for payment processors); SOC 2 Type II; ISO 27001
AWS (S3)	ISO 27001; ISO 27017; ISO 27018; SOC 1/2/3; PCI DSS Level 1; CSA STAR
Cloudflare	ISO 27001; SOC 2 Type II; PCI DSS Level 1
Brevo	ISO 27001; GDPR-compliant; EU data residency available

Trust pages: OpenAI — trust.openai.com; Stripe — stripe.com/docs/security; AWS — aws.amazon.com/compliance; Cloudflare — cloudflare.com/trust-hub; Brevo — trust.brevo.com. Certification status should be verified annually at contract renewal.

---

7. Incident Response

7.1 Incident Response Plan

ClipToText maintains a documented Incident Response Plan covering the phases below. This plan is reviewed annually or following any significant incident.

7.2 Response Phases

Phase 1 — Detection and Identification

• Automated monitoring alerts (server errors, anomalous traffic, failed authentication spikes, Redis/DB access anomalies) trigger review.
• Security incidents may also be reported by Subscribers via support@cliptotext.ai or discovered during routine security reviews.
• Application error monitoring via structured logs (Symfony Monolog). Grafana-based infrastructure monitoring is planned. Alert thresholds: error rate >1% triggers investigation; 500 errors >10/min triggers P1 escalation.

Phase 2 — Triage and Assessment

• The on-call engineer assesses severity, scope and potential impact within 2 hours of detection.
• Incidents are classified:
  • P1 (Critical): Active data breach, service outage, cross-tenant data leakage — escalate immediately.
  • P2 (High): Suspected breach, significant service degradation, failed authentication at scale.
  • P3 (Medium/Low): Vulnerability discovered (not yet exploited), isolated errors.

Phase 3 — Containment

• Immediate steps to stop ongoing harm: revoke compromised credentials, block malicious IPs via Cloudflare, isolate affected services.
• Preserve evidence for forensic analysis.

Phase 4 — Notification

• Within 72 hours of becoming aware of a Personal Data Breach: notify affected Controllers (Subscribers) and, where required, the ICO.
• Notification will include details as required by Article 33 UK GDPR (see DPA Section 6 for full notification requirements).
• Subscribers are notified via their registered account email address.

Phase 5 — Eradication and Recovery

• Root cause identified and remediated.
• Affected systems restored from clean backups where necessary.
• Security controls updated to prevent recurrence.

Phase 6 — Post-Incident Review

• Written post-incident report produced within 14 days of resolution.
• Report covers: timeline, root cause, impact, remediation steps taken, lessons learnt, changes to controls.
• Reports are retained for 3 years.

---

8. Data Backup and Recovery

8.1. The production database (MariaDB) is backed up daily (full backup). Backups are automated via cron job and stored on Hetzner infrastructure separate from the primary data volume.

8.2. Backups are encrypted at rest (AES-256) and stored in a geographically separate location from the primary data.

8.3. Backup retention period: 30 days for daily backups.

8.4. Backup recovery is tested quarterly to verify that backups are usable and recovery time meets operational requirements. Test results are documented.

8.5. Recovery time objective (RTO) and recovery point objective (RPO):

• RTO (Recovery Time Objective): 4 hours for all tiers. RPO (Recovery Point Objective): 24 hours (aligned to daily backup frequency).

---

9. Vulnerability Management

9.1. Dependency scanning: Application dependencies (Composer packages, system packages) are monitored for known vulnerabilities via composer audit run in the CI/CD pipeline on each deployment. Critical vulnerabilities block deployment until resolved.

9.2. Patch management schedule:

Severity	Remediation Target
Critical (CVSS 9.0–10.0)	Within 7 days of confirmed vulnerability
High (CVSS 7.0–8.9)	Within 30 days
Medium (CVSS 4.0–6.9)	Within 90 days
Low (CVSS 0.1–3.9)	Next scheduled maintenance window

9.3. Penetration testing: External penetration testing of the Service is recommended at least annually and following significant architectural changes. Test results are reviewed by the engineering team and critical/high findings remediated before the next test cycle.

9.4. An initial penetration test from a CREST-approved provider is planned prior to or within 90 days of public launch. Results are treated as confidential and shared only under NDA.

9.5. Static analysis: PHPStan (level 9) is used in the development workflow to identify code-level issues. CI/CD pipelines enforce quality gates before deployment.

---

10. Employee and Contractor Security

10.1. All personnel with access to production systems or Personal Data must:

• Complete data protection and security awareness training before access is granted;
• Sign confidentiality and data protection obligations as part of their employment or contractor agreement;
• Comply with this Security Policy and the DPA.

10.2. Access is provisioned based on job function and revoked on the day of departure or role change.

10.3. Company-issued devices used to access production systems must have:

• Full disk encryption enabled;
• Endpoint security software (antivirus/EDR);
• Automatic screen lock after a defined period of inactivity.

10.4. Personnel must not access production data from unmanaged personal devices unless authorised and connected via VPN.

---

11. Physical Security

11.1. ClipToText operates as a cloud-first service with no on-premises data storage. All production data is held within the hosting infrastructure described in Section 6.1.

11.2. Physical security of data centre facilities is governed by the hosting provider's security controls (see Section 6.3 for sub-processor certifications).

11.3. Offices and remote working environments are subject to physical access controls appropriate to the sensitivity of data accessed.

---

12. Reporting Security Concerns

If you discover a security vulnerability, data isolation issue, or suspected breach in the Service, please report it responsibly to:

support@cliptotext.ai (subject: "Security Report")

Please see the Acceptable Use Policy (Section 7.2) for our full responsible disclosure process.

We will acknowledge all security reports within 5 business days and investigate in good faith.

---

This document was prepared as a draft template and must be reviewed and validated by a qualified UK solicitor before publication or reliance. It does not constitute legal advice.