Annex II — Technical and Organisational Measures (TOM)

Last updated: 2026-04-26

This Annex describes the technical and organisational measures implemented by Clubtrack, Inc. ("Processor") to protect Personal Data in accordance with Article 32 GDPR and equivalent provisions of the UK GDPR and Swiss FADP. It is designed to satisfy the requirements of the SCCs (Annex II) and to provide Controllers with the detail needed for their own Article 32 assessments.

Measures are reviewed at least annually and updated to reflect the state of the art, the nature of processing and the risk to the rights and freedoms of Data Subjects.

1. Governance

• Designated Data Protection Officer (DPO) with direct reporting line to CEO.

• Security policies reviewed and approved annually by management.

• Risk management programme with register of data protection and security risks.

• Records of Processing Activities (ROPA) maintained for both Controller and Processor roles.

• Data Protection Impact Assessments (DPIA) for high-risk processing (Fan Score, RFM segmentation, and any future predictive modelling).

• Internal control framework aligned to ISO 27001 / SOC 2 Common Criteria, with external certification planned.

• Independence of security function from product delivery for conflict-of-interest cases.

2. Human resources security

• Background checks on all employees and contractors with access to Personal Data, to the extent permitted by local law.

• Confidentiality and non-disclosure clauses in every employment and contractor agreement, surviving termination.

• Mandatory onboarding training on data protection and security, with annual refresh and phishing simulations.

• Role-based training for engineering, customer success and support.

• Sanctions policy for violations, up to termination.

• Offboarding SLA of 24 hours for revocation of all access rights; equipment returned and wiped.

3. Access control

3.1 User access

• Strong password policies for all staff accounts, enforced by the identity provider.

• Multi-factor authentication (MFA) on the roadmap for administrator and engineer accounts and production system access; currently evaluated for implementation.

• Role-based access control (RBAC) with least-privilege principle.

• Access provisioning via ticket with management approval; documented in access register.

• Periodic access reviews conducted by asset owners.

• Shared or generic accounts prohibited in production.

3.2 Customer access

• Customer admins authenticate via email/password. MFA is planned for a future release.

• RBAC within Customer accounts (admin, user, agency roles).

• Authorisation layer enforces tenant isolation on every API call.

3.3 Privileged access

• Just-In-Time (JIT) access to production for engineers; all sessions logged.

• Break-glass procedures documented and audited.

• No direct SSH to production hosts; access only through bastion with session recording.

4. Authentication

• Passwords stored as cryptographic hashes. Migration to Argon2id with salt is planned.

• Password policy: minimum 12 characters, rotation on suspicion of compromise, blocklist of breached passwords.

• Rate limiting and lockout on authentication endpoints.

• Session tokens: JWT with 15 min access / 8h refresh; rotation; signed with properly managed secret; cookies configured with Secure flag. Roadmap: HttpOnly and SameSite=Strict flags to be added.

• Token revocation on logout, password change, role change.

5. Cryptography

5.1 In transit

• TLS 1.2+ (TLS 1.3 preferred) for all external and internal service-to-service communication.

• HSTS with includeSubDomains and 1-year max-age.

• Modern ciphers only; obsolete SSL/TLS versions disabled.

• Certificate management via AWS Certificate Manager / Let's Encrypt; automated renewal.

5.2 At rest

• AES-256 encryption of customer data stored in RDS (PostgreSQL), S3 and EBS.

• Application-level encryption (AES-GCM with application-managed keys) for integration credentials (OAuth tokens, API keys) before DB storage.

5.3 Secrets management

• No secrets in Git. Enforced via pre-commit hooks and secret scanning in CI.

• Secrets managed via environment variables and infrastructure-level secret stores.

• Short-lived credentials where possible (IAM roles, STS tokens).

• Secret rotation policy: on suspected compromise.

6. Network security

• AWS VPC with private subnets for databases and internal services; public subnets only for load balancers.

• Security groups and NACLs enforce least-access network policies.

• Web Application Firewall (AWS WAF) in front of the API and frontend.

• DDoS protection via AWS Shield.

• Bastion hosts for administrative access; no direct SSH from internet.

• TLS termination at load balancer; re-encrypted to backend.

• No ports exposed to 0.0.0.0 for databases, caches or internal services.

7. Application security

• Secure development lifecycle with threat modelling for new features.

• OWASP Top 10 and OWASP ASVS as reference.

• Input validation on all API endpoints.

• Parameterised SQL queries (sqlx named parameters); no string concatenation in SQL paths.

• Output encoding to prevent XSS.

• Content Security Policy (CSP), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin.

• HMAC signature verification with constant-time comparison for all webhooks.

• Rate limiting per IP via in-memory token bucket algorithm.

• Dependency scanning (SCA) in CI; vulnerabilities triaged by SLA based on severity.

• SAST and secret scanning in CI (gosec, staticcheck, semgrep, gitleaks).

• Container images built from minimal, hardened base; scanned for CVEs.

• No debug or test endpoints in production.

• Roadmap: CSRF token protection for state-changing requests.

8. Infrastructure and operations

• Infrastructure as Code (Terraform) with code review and automated policy checks.

• Immutable deployments; no SSH-based patching.

• Environment segregation (prod, staging, dev) with separate AWS accounts.

• Baseline hardening of all images (CIS benchmarks aligned).

• Patch management SLA: critical within 7 days, high within 30 days.

• Reverse proxy (AWS ALB + WAF or Nginx) in front of all HTTP services with TLS termination.

9. Logging and monitoring

• Application-level logging in JSON format (Logrus). Centralised log aggregation is planned.

• Operational and security log retention: 12 months maximum, after which logs are purged or irreversibly anonymised. This figure is consistent with the "Security, fraud prevention, abuse detection" retention period declared in Privacy Policy §A.2.

• Administrative audit log retention: 24 months maximum for logs recording administrative actions (login and logout events, including failed authentication attempts; account creation and deletion; Authorised User creation and deletion; create, update and delete operations on fan and account resources; acceptance of legal documents; privileged access; configuration changes; role assignments; sub-processor changes; data subject rights operations). These records are persisted in a dedicated append-only database table (sy_audit_log), are stored separately from operational logs, and are subject to automated purge or irreversible anonymisation at the end of the retention window (see §15). Authorised Users may retrieve their own audit history through the GET /accounts/me/audit-log endpoint. Retention is capped to comply with GDPR Article 5(1)(c) and (e) (data minimisation and storage limitation) while preserving a sufficient window for security investigations, accountability and legal defence.

• Integrity protection of logs (append-only buckets, checksums).

• 24/7 monitoring of critical services with alerting.

• SIEM rules for detection of brute force, privilege escalation, data exfiltration patterns.

• Best-effort PII avoidance in application logs.

10. Business continuity and backup

• Automated daily backups of production databases (PostgreSQL RDS), retained 30 days.

• Cross-region replication of backups is planned.

• Off-site backup via S3 versioning with lifecycle rules.

• RPO: 24 hours. RTO: 4 hours.

• Annual disaster recovery test documented.

• Multi-AZ deployment for production databases.

• Backup encryption (AES-256) and periodic restore verification.

• Backup of data warehouse included in the backup programme.

11. Incident management

• Documented incident response plan with defined roles, severity matrix and escalation paths.

• 24/7 on-call for production incidents.

• Personal Data Breach notification to Controllers within 48 hours of awareness, per DPA Clause 4.7.

• Root cause analysis and lessons learned for all significant incidents.

• Relationship with external IR provider for large-scale incidents.

• Cooperation with Supervisory Authorities and law enforcement as legally required.

12. Vendor and sub-processor management

• Security assessment of all sub-processors before onboarding.

• Contractual data protection obligations equivalent to this DPA.

• Annual review of critical sub-processors.

• Public sub-processor list at clubtrack.io/subprocessors with 30-day notification of changes.

13. Physical security

Data centres are operated by Amazon Web Services in the EU (Ireland, Frankfurt). AWS maintains the following certifications relevant to physical security: ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, C5 (Germany), ENS (Spain).

Clubtrack offices: access control, visitor registration, clean desk policy, secure destruction of physical documents.

14. Data minimisation and quality

• Data minimisation by design — only required fields processed for each feature.

• Deduplication and data quality checks in the ingestion pipeline.

• Controller-facing tools to update, correct and erase specific records.

15. Data subject rights enablement

• APIs and UI for Controllers to:

  • Export all Personal Data of a Data Subject in machine-readable format.

  • Erase a Data Subject across all relevant tables (including engagement, source systems, audit logs where legally permissible).

  • Block or anonymise specific records.

• Shopify GDPR webhook endpoints implemented.

• Automated purge of soft-deleted records is planned.

• Proof-of-acceptance log. Authorised User acceptances of Clubtrack's legal documents are recorded in a dedicated append-only database table (sy_acceptance_log) at three contractual moments: (i) account registration, (ii) first paid subscription, and (iii) each subsequent subscription renewal or plan change. Each row stores the actor, tenant, event, timestamp, IP, user-agent, and request identifier, together with a JSON array covering the seven hashed legal documents in force at that moment — Terms of Service, Privacy Policy, DPA, DPA Annex II (TOM), DPA Annex III (SCC), Subprocessors list and Cookie Policy — with the document name, the Last updated version date and the SHA-256 of the raw markdown bytes. The Legal Notice and Aviso Legal are statutorily-published identity pages and are intentionally excluded from the accepted set. The canonical archive of prior document versions is the legal/ Git history, so the exact text accepted by a given row can be recovered by looking up the commit matching the recorded hash. A paired sy_audit_log row is written on every acceptance. Authorised Users can retrieve their own acceptance history through the GET /accounts/me/acceptance-log endpoint, subject to authorisation checks.

16. Specific measures for international transfers

• Data is hosted in AWS EU regions only (Ireland, Frankfurt).

• Sub-processor administrative access from non-EEA countries is covered by SCCs and subject to strict access controls (JIT, logged).

• Supplementary measures for transfers:

  • Encryption at rest and in transit with Controller-segregated keys where applicable.

  • Pseudonymisation planned where feasible (not yet implemented).

  • Access control lists limiting US-based staff access to production EU data.

  • Transparency reports on government access requests.

  • Policy of challenging unlawful or overbroad government requests.

17. Certifications and independent verification

• Roadmap: SOC 2 Type II and ISO 27001 are on a multi-year roadmap; no committed public date.

• Annual penetration test by an independent qualified firm; executive summary shareable with Controllers under NDA.

• Continuous vulnerability scanning with Qualys / Tenable / equivalent.

18. Change management

• Formal change control for all production changes.

• Code review (≥ 1 approval, ≥ 2 for critical changes).

• CI/CD with automated tests, SAST, SCA, secret scanning and infrastructure policy checks.

• Staged rollouts with monitoring and rollback capability.

• Approval gates for production deployments (required reviewers on deploy workflows).

19. Testing

• Unit, integration and end-to-end tests with enforced coverage gates (critical paths ≥ 80%).

• GDPR features covered by dedicated tests (erasure, export, retention, webhooks).

• Chaos and resilience testing periodically.

• Phishing and social engineering tests for staff.

20. Accountability and documentation

• ROPA maintained and updated.

• DPIA register with DPIAs for Fan Score, RFM segmentation and other profiling features.

• Transfer register with TIAs.

• Decision logs for material security and data protection decisions.

• Acceptance log (sy_acceptance_log, see §15) supporting accountability for contract formation and for the version of the legal documents in force at each acceptance moment.

• Continuous improvement programme tracking findings from audits, incidents and reviews.